Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: atom-ant on August 12, 2010, 05:20:20 PM
-
Does the Amiga sam-flex 440ep OS 4.1 support SSL??
f
-
Yes AmiSSL and OpenSSL both are available for SAM Flex (http://amigakit.leamancomputing.com/catalog/advanced_search_result.php?keywords=sam+system) with AmigaOS 4.1
-
Hi
Does this mean I have to download the amiSSL and openSSL from OS4Depot?
-
We can pre-install it for you on any OS 4.1 Flex system we build.
-
Considering the topic of the thread and the question asked... are you really asking if there is any e-mail program for Amiga that supports encryption of e-mail using SSL, aka S/MIME (http://en.wikipedia.org/wiki/S-MIME)?
-
Well, I guess it's either that or a web browser that supports logging into webmail using https:
YAM supports SSL, and I think OWB does as well but a lot of modern webmail interfaces seem to fail in OWB and other Amiga browsers unless you switch them to "old version" or similar...
-
Well, I guess it's either that or a web browser that supports logging into webmail using https:
YAM supports SSL, and I think OWB does as well but a lot of modern webmail interfaces seem to fail in OWB and other Amiga browsers unless you switch them to "old version" or similar...
There's SSL all over the place.. imaps, imap and smtp-auth using StartTLS, S/MIME... and by saying "YAM supports SSL" you mean exactly what? Does it handle chained certificates? Does it handle x509v3 certificates with subject alternate names? How about OCSP? Manual CRL handling.. what? :)
-
... any e-mail program for Amiga that supports encryption of e-mail using SSL, aka S/MIME (http://en.wikipedia.org/wiki/S-MIME)?
SSL != S/MIME
SSL encrypts the connection between (email) client and server during actual transport, nothing else. S/MIME encrypts the message end-to-end between the sending and the receiving email clients.
Network-wise, SSL works in the transport layer while S/MIME works within the message as a special form of MIME encoding (could somewhat be counted to the application layer).
-
SSL != S/MIME
SSL encrypts the connection between (email) client and server during actual transport, nothing else. S/MIME encrypts the message end-to-end between the sending and the receiving email clients.
Network-wise, SSL works in the transport layer while S/MIME works within the message as a special form of MIME encoding (could somewhat be counted to the application layer).
Stop being so "theoretic", the OSI model is dead, the real world is pragmatic and SSL works in just about any layer you want it to, and is also used everywhere. Also it is nowadays known as TLS as you probably know. Anyways, this is beside the point, which was that original poster made a very vague question, and when people say "Product X supports SSL" it is damn hard to know what they're really claiming.
When using S/MIME, what do you think application developers do... reimplement certificate handling, or just use excisting BSD (or GNU) licensed SSL implementation to do certificate handling for them? Why does the openssl command have a "smime" subcommand you think?
-
@kolla
You know, I haven't got a clue, and to be honest I'm not that interested either - YAM's fallen behind a little too much to be useful for me so I rarely use it. I answered it in general because the OP was very vague in what they were asking. If they had asked about chained certificates, someone who knew such specific detail would answer for sure.
-
@kolla
It makes a huge difference in what security you actually get. SSL/TLS only secures the transport. On the server, between external servers(!) and on your local HDD the message is not encrypted in any way. Nor can any manipulation be detected. For email, SSL/TLS can only provide (end-to-end) security in a closed or at least well-known environment. (And btw SSL and TLS are different things even if a user can neglect the difference. A developer/IT supporter can't.)
S/MIME encrypts the message, then you can transport it safely any which way you want without worrying about eavesdropping or manipulation and only the intended sender can decrypt it.
Makes hell of a difference for me. If I want to ensure confidential end-to-end communication I use S/MIME. If I want to secure login/account or traffic details in an insecure environment (esp. public hotspots, insecure wireless in general, untrusted LANs) I use SSL or TLS.
And stop kidding me about OSI's dead. It sure is but without the layered architecture the internet wouldn't be possible. We'd be stuck with 10base5 and there'd be no DSL or Wi-Fi at all. And probably you don't want to tell me that a hub, a switch or a router are exactly the same, do you?
-
OK thanks for the info
-
OK thanks for the input
-
@Zac67
Why are you lecturing me?
For what it's worth, part of my job is signing certificates for a larger CA and deal with support for those certificates, I do have ideas about how things work, thank you very much, including the difference between SSL and TLS.
My point was that it's pretty much the same software that is used for these things, whether you use it for setting up encrypted tunnels over TCP (strictly SSL), setting up encryptet tunnels from within a protocol (TLS), encrypting and signing email (S/MIME), signing zone files (DNSSEC), authentication over wireless (802.1X/WPA(2) enterprise with EAP-TLS/TTLS/PEAP) or wire, and heaploads more.
As for router, switches and hubs, please have a look at what companies like Cisco, Juniper and others deliver today, that's right - boxes that do a heck lot of mixing between layer two and three in the same box.
For what it's worth, I don't see the point in pushing this further, your view is correct on a principal, theoretical level, but internet technology is developed by pragmatists who use whatever technology that fits at any level they see fit. If you think that's all wrong, then I suggest you participate in IETF and do some serious humming :)
-
Do I detect the scent of urine in this thread?!
-
Sorry, but imho it's VERY dangerous to state S/MIME and SSL are just the same - some poor sod will turn on SSL in his email proggie and think it's all perfectly safe from here to oblivion. Only to find out years later that it isn't worth a **** for his purpose.
(We've got some managers in the company arguing on that level, so I'm probably a bit sensitive here, sorry again.)