[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] how secure is ssl email login
On 4/26/2013 3:54 PM, Michael Trausch wrote:
> On Apr 26, 2013, at 2:27 PM, "Ron Frazier (ALE)"
> <atllinuxenthinfo at techstarship.com
> <mailto: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
> 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. :-)
Hi Mike T, and all,
Thanks for the replies on this. This last bit is the key piece of
information I needed. So, the SSL link is brought up first, then my
credentials are sent to the server. The fact that my credentials are
not in plaintext on the wire (or wifi) is exactly the result I was
hoping to hear. You would think it would be that way, but I'd be rich
if I had a dollar for every time a software maker has done something
stupid or tried to do it right and got it wrong. It's good to know that
my email is secure from snoopers (except over my shoulder) whether I'm
running a vpn or not. From an end user point of view, even a technical
user, this stuff can be baffling. And we all know that the default
settings on software are almost always set for convenience and
simplicity. (IE lack of tech support phone calls.) If you want
security and privacy, you have to change them. So, I wanted to make
sure my settings were OK.
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new email messages very quickly.)
770-205-9422 (O) Leave a message.
linuxdude AT techstarship.com
-------------- next part --------------
An HTML attachment was scrubbed...