Ffox: is "use secure authentication" redundant?
Deneb Meketa
1.5, I see these options:
Security Settings
Use secure connection:
() Never
() TLS, if available
() TLS
() SSL
[] Use secure authentication
I'm curious what "use secure authentication" actually does. I'd like to
see security be really easy for users, and I think they will find it
confusing (I certainly do) that "use secure authentication" is separate
from "use secure connection". How do the two differ?
I have a few theories:
1. Maybe "use secure authentication" is only meaningful when "use secure
connection" is set to "never", and in this case the effect of "use
secure authentication" is to encrypt the username/password exchange, but
use an unencrypted connection to transfer mail. Certainly when I choose
SSL, packet traces don't show a cleartext username or password, even
when "use secure authentication" is unchecked, so I get the feeling that
choosing SSL makes "use secure authentication" unnecessary. If this is
the case, then I think the UI should be modified as follows:
Security Settings
Use secure connection:
() Never
() Only for authentication
() TLS, if available
() TLS
() SSL
2. Maybe "use secure authentication" doesn't refer to encryption; maybe
instead it refers to a more robust authentication protocol. Maybe
something more than just username and password are exchanged in this
kind of setup. If this is the case, I'd be a big fan of explaining this
in some way - maybe more verbose text in the checkbox label?
Basically, I think users should easily be able to answer the question:
do I have a secure configuration that I'm comfortable with? If my
server supports SSL, but doesn't support secure authentication (which is
nicely indicated by a dialog box), is that OK, or do I need to look for
a better ISP?
Many thanks for any clarification.
Frank Wein
> Looking at the "Server Settings" panel for an email account in Firefox
> 1.5, I see these options:
You mean Thunderbird 1.5 here?
Frank
Heikki Toivonen
> Looking at the "Server Settings" panel for an email account in Firefox
> 1.5, I see these options:
I believe you meant Thunderbird.
> Security Settings
> Use secure connection:
> () Never
> () TLS, if available
> () TLS
> () SSL
> [] Use secure authentication
The secure connection settings are for SSL/TLS. Secure authentication
means login and password protection done with different technology.
I do think these are confusing. It is be possible to autodetect the most
secure settings in most cases. Often only email address would be needed
for accurate autodetection. There are some pathological cases where
autodetection will give wrong results.
--
Heikki Toivonen
Nelson B
> Looking at the "Server Settings" panel for an email account in Firefox
> 1.5, I see these options:
>
> Security Settings
> Use secure connection:
> () Never
> () TLS, if available
> () TLS
> () SSL
> [] Use secure authentication
>
> I'm curious what "use secure authentication" actually does. I'd like to
> see security be really easy for users, and I think they will find it
> confusing (I certainly do) that "use secure authentication" is separate
> from "use secure connection". How do the two differ?
>
> I have a few theories:
[snip]
> 2. Maybe "use secure authentication" doesn't refer to encryption; maybe
> instead it refers to a more robust authentication protocol. Maybe
> something more than just username and password are exchanged in this
> kind of setup. If this is the case, I'd be a big fan of explaining this
> in some way - maybe more verbose text in the checkbox label?
>
> Basically, I think users should easily be able to answer the question:
> do I have a secure configuration that I'm comfortable with? If my
> server supports SSL, but doesn't support secure authentication (which is
> nicely indicated by a dialog box), is that OK, or do I need to look for
> a better ISP?
AMEN! I so agree with you! Users should find the prefs simple enough to
understand that they can make the right choice the first time.
I think the problem is that these different settings represent combinations
of features that aren't exactly household words. Someone has attempted to
boil each choice down to a minimum of words, and in this case, they went
too far, IMO.
Below I will give a more complete explanation of each choice. Maybe you
can find a one-line phrase for each one that is clearer than what's above.
That might be a good contribution.
> Many thanks for any clarification.
Here's what these settings really mean:
> Use secure connection:
means use some form of SSL to encrypt the connection
> [] Use secure authentication
means use a cryptographic protocol just for the password. No SSL,
no encryption (as such). Commonly called CRAM-MD5, IINM, which (IIRC)
means "CRyptographic Access Method". This one uses MD5 (hash algo,
not encryption). This is NOT mutually exclusive with the use of SSL,
but IMO is mostly applicable when SSL is not used.
Given the existence of bug 311939, the use of CRAM-MD5 is always a good
idea with any server that supports it, IMO, even when TLS is selected.
Here are the choices for use of SSL (a.k.a. TLS). I'm going to discuss the
choices out of order.
> () Never
self-explanatory, one hopes. One would hope to use CRAM=MD5 here.
> () SSL
This always uses SSL/TLS. It uses a separate "port" number on the server
from the "normal" POP3, IMAP, SMTP or NNTP port. With this special port,
SSL/TLS is started first (very first thing), and all subsequence traffic
on that port uses SSL/TLS, including the login part (name/password) and
the subsequent message transfers.
> () TLS
IMO, This should have been named "StartTLS". StartTLS is a feature of
POP3, IMAP, SMTP, LDAP, and (IINM) NNTP. It uses the normal port number
and the connection starts out "in the clear" just as it would if SSL/TLS
was never to be involved. But early on in the connection, the client
asks the server "Do you support SSL/TLS?" and if the server answers in
the affirmative, the client then tells the server "Let's start using
SSL/TLS right now". And they do. Thereafter, the behavior on the
connection is just like the "always use SSL/TLS" case above. The login
and message traffic happen over SSL/TLS after that for the remainder of
the connection. Again, this feature is called StartTLS.
With this particular choice (named "TLS"), if the server responds saying
that it does NOT support StartTLS, then the connection ends without the
login info being sent to the server.
> () TLS, if available
This is just like the "TLS" (really StartTLS) case above, EXCEPT that
the "if available" part means that if the server says "I do not support
StartTLS" when the client asks, then the client just falls back to
not using SSL at all, and behaves just like the "Never" case above.
So, for this choice, the use of SSL/TLS is OPTIONAL, and is chosen by
the server. The user is not notified whether encryption was used, or not.
Personally, I would not use this feature, at least not without also using
CRAM-MD5.
As you can see, the choice of the names "SSL" and "TLS" to describe the
difference between those options is really poor. SSL and TLS are
effectively synonyms. The difference is whether SSL/TLS is done from
the very beginning of the connection, or is negotiated and started after
the connection has begun.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=311939
--
Nelson B
Deneb Meketa
I would personally love to see those details posted somewhere. If no
one suggests otherwise, I may add something to "Tips & Tricks" and to
the email section of the Mozilla security center.
But that's a tangent. I'd like to make a radical proposal for revising
the UI and adding an automatic mode. This is totally blue-sky, so let
me know if I'm talking crazy talk.
I propose to have the UI look like this:
Connection Security
Most users should choose "Automatic", which allows Thunderbird
to choose the most secure mode that your server supports.
(o) Automatic (currently this is SSL) [[Re-negotiate now]]
( ) SSL (fully secured)
( ) StartTLS (fully secured, alternate mode)
( ) CRAM-MD5 (encrypted password, unsecured mail exchange)
( ) No security
The default would be automatic mode. The first time automatic mode is
used to connect to a given server, a dialog box appears, informing the
user of the mode in use, with a brief explanation of how secure that
mode is. Thereafter, upon visiting the prefs, users see the mode that
was most recently used (e.g. SSL in the example above). Any time the
last-used mode doesn't work, no attempt is made to use other modes; the
connection fails with the usual error message. If a user chooses a
non-automatic mode, the last-used mode is forgotten, and if the user
then switches back to automatic mode, the behavior is the same as upon
first connection (the user is notified of the mode used). The
"re-negotiate" button might or might not be useful; it immediately shows
a dialog that indicates progress, and then outcome, and when the dialog
is dismissed the outcome is reflected in the "currently" text. When
there is no last-used mode, "re-negotiate" might be retitled "negotiate".
It seems to me that automatic mode is feasible, but I don't have all the
evidence to back that up, so correct me if I'm wrong. Each of the
methods would be tried, from most to least secure, which is also the
order in which I've sorted the options in the UI proposal above. As a
detail, if the user has entered a non-default port number, perhaps
automatic mode should, for each method, try first the user-specified
port number, and then the default port for that method.
Note that I have deleted the "TLS, if available" mode. I agree with
Nelson that this is probably not useful. I think most users would want
to know if their security mode changed, and you really wouldn't expect
this to change once it was established. The only use case I can think
of is that someone chooses "TLS, if available", knowing that TLS is not
supported but hoping that it will be in the future, and then gets the
benefit of an automatic upgrade as soon as it's available. But that
seems like an edge case, and presumably users who know enough to worry
about this would have other ways of finding out that StartTLS had become
supported. A side benefit of removing "TLS, if available" is that bug
311939 would become obsolete.
Finally, note that this proposal only offers CRAM-MD5 when neither SSL
nor StartTLS is in use. This eliminates the confusing separate checkbox
that started this whole thread.
How's all this sound?
Thanks again
d.
Nelson B
> Many thanks to Nelson for the excellent clarification.
BTW, I should have mentioned that the preference named:
[] Use secure authentication
should be more accurately labelled:
[] Use secure authentication IF AVAILABLE
> I would personally love to see those details posted somewhere. If no
> one suggests otherwise, I may add something to "Tips & Tricks" and to
> the email section of the Mozilla security center.
You mean somewhere besides https://bugzilla.mozilla.org/show_bug.cgi?id=258540 ?
> But that's a tangent. I'd like to make a radical proposal for revising
> the UI and adding an automatic mode. This is totally blue-sky, so let
> me know if I'm talking crazy talk.
>
> I propose to have the UI look like this:
>
> Connection Security
>
> Most users should choose "Automatic", which allows Thunderbird
> to choose the most secure mode that your server supports.
>
> (o) Automatic (currently this is SSL) [[Re-negotiate now]]
> ( ) SSL (fully secured)
> ( ) StartTLS (fully secured, alternate mode)
> ( ) CRAM-MD5 (encrypted password, unsecured mail exchange)
> ( ) No security
>
> The default would be automatic mode.
See https://bugzilla.mozilla.org/show_bug.cgi?id=185631
Add comments and votes there.
If you're going to have an automatic mode, then I think you need check-boxes
(not radio buttons) to allow the user to specify which methods are
permissible to be tried.
Or perhaps it suffices to have a check box that says:
[] NEVER use plain text unencrypted passwords.
My beef with this whole mess is that it seems to assume that it can always
fall back on plain text passwords, even if I specifically want to avoid that.
It used to be worse. It used to try plain text passwords even if the
server plainly told it not to do so. But that was eventually fixed.
https://bugzilla.mozilla.org/show_bug.cgi?id=205944
So, now it obeys the remote server's wishes, but not the local user's. :(
See also bug https://bugzilla.mozilla.org/show_bug.cgi?id=325379 which was
JUST fixed (fix has not yet appeared in any official builds, but is in some
nightly test builds).
Automatic mode must start by trying the most secure flavor, and work its
way down. It must NOT start by sending the password in the clear.
And it should not send the password in the clear without explicit user
permission.
> Note that I have deleted the "TLS, if available" mode. I agree with
> Nelson that this is probably not useful. I think most users would want
> to know if their security mode changed, and you really wouldn't expect
> this to change once it was established.
A few years ago, there was a very vociferous group loudly promoting
something they called "opportunistic encryption", which was basically
a plan to encrypt whenever you can (without asking the user) but falling
back to no encryption (also without telling the user) whenever you cannot
do encryption. I think the "TLS if available" feature was added to
satisfy them. But with that scheme, the user simply has no control over
whether encryption is used, and no way of knowing if it was used. It is
trivial for an attacker to force the client to not use encryption, when
that feature is selected, which means it's worthless for providing real
protection.
If we pull that back out, I wonder if the "opportunistic encryption"
crowd will raise their voices again, and if this time maybe Mozilla will
have the back-bone to just say no, instead of caving in.
> Finally, note that this proposal only offers CRAM-MD5 when neither SSL
> nor StartTLS is in use. This eliminates the confusing separate checkbox
> that started this whole thread.
I see no reason to make CRAM-MD5 mutually exclusive with SSL/TLS.
> How's all this sound?
Sounds great, but won't go anywhere until someone is willing to work on
the code to implement it. Right now there's only one person doing ALL
the mail/news back end work for all mozilla products. Seems everyone
loves to work on UI, but no-one wants to work on the hard stuff, the
back end. So, people can "wish" and "vote" for all the great ideas they
want, but until someone IMPLEMENTS them, they're just beggars' horses.
--
Nelson B