[ale] how secure is ssl email login

Michael Trausch mbt at naunetcorp.com
Fri Apr 26 15:54:50 EDT 2013


On Apr 26, 2013, at 2:27 PM, "Ron Frazier (ALE)" <atllinuxenthinfo at techstarship.com> wrote:

> For the pop server on port 995, the authentication options are:
> 
> - plain (this is selected)
> - cram-md5

This is where an understanding of the underlying protocols, and security in general, would be helpful.

Services which communicate via SSL do so through a virtualized network connection, tunneled through the SSL libraries at either end.  The SSL libraries can communicate directly with the operating system socket implementation, or they can operate using memory buffers; either way, all plaintext communication enters the tunnel on one side, and is extracted on the other as plaintext.

STARTTLS, which is a common extension to plaintext services such as POP3, SMTP and IMAP running on their standard ports, is a mechanism that allows servers to negotiate a secure connection, but not open a connection in a secure mode by default.  Often services that are running on such ports today disallow anything but security negotiation on that port, and only allow authentication after the connection has been made secure.  This usually involves the client sending a signal to the server telling it that it wishes to begin secure communications, by issuing a STARTTLS command, and then the server replies in the affirmative and both ends switch to communicating through their respective SSL library interfaces for the duration of the connection.

"Plain" authentication is very frequently the only option that SSL-enabled systems provide.  In fact, servers that only understand the plain authentication mechanism will typically disable authentication entirely over insecure channels as more-or-less described above, effectively eliminating insecure plaintext authentication over the public Internet.  Other options may be supported by the server, but that varies on a server-by-server basis.  The only mechanism that is required on both sides is "plain" authentication, per the standards.

So, yes, you're sending plaintext authentication credentials to the server you are talking to, but because SSL provides both confidentiality and connection integrity, that means that it is not plaintext when on the wire.  And for these purposes, that's the key distinction.

Personally, I am a fan of Kerberos, because the password is never revealed during authentication over the network.  The original password is sent in an encrypted form over the network exactly once, and that is during the password change process.  After that, the server keeps a copy of the encrypted password, and the protocol makes it possible to verify the shared-secret (password/passphrase) credentials without actually passing them across the network.  Now that is a secure authentication process---even if session communications are compromised, the user's credentials are not.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130426/fbe64d94/attachment-0001.html>


More information about the Ale mailing list