259982 - No warning when sending clear username/password on unencrypted connection

Status: NEW

(MailNews Core :: Security, defect)

Description

[Chapman Flack]

User-Agent:       Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.5.1) Gecko/20031214
Build Identifier: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.5.1) Gecko/20031214

The browser ordinarily posts a warning dialog if an action would result in
sending a username/password on an unencrypted connection.

Both SMTP (outgoing mail) and POP3 (incoming mail) protocols include a variety
of authentication mechanisms to determine that you are who you claim to be
without ever exchanging your unencrypted password on the network (RFC2554 for
SMTP, RFC1939, 1734 for POP3).  Both protocols can also be conducted over
transport-layer security (RFC2487, 2595).  When the transport is secured by
TLS--and only then--simpler means of authentication, such as the SMTP AUTH
PLAIN or AUTH LOGIN, or POP3 USER/PASS, are safe to use.  Without TLS, however,
these authentication mechanisms expose the user's unencrypted password on the
network.  The RFCs provide that these trivial authentication means are
unacceptable for use over an unencrypted network connection (RFC2595 sect. 6)
and generally urge that clients and servers refuse to advertise or agree to
them except when a secure transport exists.

However, some ISPs have SMTP and POP3 servers configured to advertise and even
require the unsafe forms of authentication over unencrypted transport.  A
widely used example at the time of writing is Verizon Online, whose SMTP and
POP3 servers both recognize the commands to enable TLS but refuse to do so,
and then permit only the unsafe AUTH LOGIN, AUTH PLAIN, or USER/PASS commands
to grant access.  (LOGIN and PLAIN both transmit the user's password in Base64
form; this is equivalent to cleartext and not a substitute for encryption.)

When Mozilla is asked to send or check mail, it negotiates with the server to
find a mutually supported authentication means.  If the server is misconfigured
to require unsafe authentication, Mozilla happily transmits the user's login
and password, unencrypted, every time the user checks or sends mail, all
without ever showing the dialog box warning of login/password being transmitted
unencrypted.  The worst thing about that is Mozilla ordinarily does show that
dialog in other circumstances, so users are accustomed to thinking things are
secure if they don't see it.  If there is no separate login/password for
mail--as is the case for Verizon--the login and password being sent out
unencrypted are the ones that control the entire account.

Mozilla should produce a warning dialog before sending logins and passwords
unencrypted for mail access just as it does in any other situation. There may
not be much the user can do in response to the dialog (click OK anyway and risk
account compromise, contact the ISP and hope they fix it, find another e-mail
service).  But that's no different from surfing to a web site that offers only
an insecure login and doesn't have an SSL variant.  In either case, the user
has at least to get the warning to be able to decide what to do about it.
Before the ISP can correct a problem, it needs to be reported, and for users
to report it they need to be aware of it.  Whether they then click OK or
suppress future dialogs is up to them.


Reproducible: Always
Steps to Reproduce:
1. Configure Mozilla to use a mail service that, like Verizon, configures its
SMTP/POP3 servers to insist on authentication but to accept no mechanisms except
insecure ones.
2. Attempt to check or send mail.
Actual Results:  
Mozilla connects to server, negotiates down to insecure authentication protocol,
and sends user's name and password unencrypted with no dialog to warn that
unencrypted password information is about to be sent.

Expected Results:  
For consistency with browser's usual behavior, to correctly satisfy user
expectations of security reinforced by browser's usual behavior, and to ensure
user is properly informed of security risks, software should have posted usual
dialog "Security Warning. The information you have entered will be sent
unencrypted and could easily be read by a third party." with the usual OK or
cancel options and checkbox to warn or not warn in future.

Comment 1

[Chapman Flack]

Attachment: protocol transcripts

Protocol transcripts documenting the reported behavior

Comment 2

[Frank Wein [:mcsmurf]]

You can force TLS encryption in the Account settings. If it fails, Mozilla won't
proceed. Wouldn't this be enough?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

see also bug 115500

Comment 4

[Chapman Flack]

Re: comment 2:

a) Ah yes, so I can.  I had looked very carefully through all the Preferences
available on my main window, including those for Mail and Newsgroups, but I had
missed the separate Mail and Newsgroups Account Settings shown only in a mail
window.  My bad ... on the other hand,

b) IIRC it was the account setup wizard that prompted me for my authentication
data, and it did not advise me that such options existed, or where to look to
find them.  If I had read sequentially through the Mail and News section of
Help, I would have come across Changing the Settings for an Account, but it
isn't shown in the Contents, and I did check the Index for several terms I
thought relevant (authentication, unencrypted, security, SSL) and saw nothing
that looked appropriate;

c) what are the defaults?  the default behavior in the browser is to pop up my
"this is to be sent unencrypted" dialogs whenever that's about to happen unless
I say don't do that any more.  I think that's the right default.  But the
default for these account settings is, for POP, don't use ssl, don't use secure
auth, even if available, and for SMTP, 'never' use ssl (not even 'when
available'), and to give no warning or notice that insecure auth is being used.

So by default, Mozilla sedulously warns me every time I'm about to risk my
password for the insecure web site of Bubba's Barbecue Bulletin, but in the
time it took me to catch up with Bubba's, Mozilla silently went out and checked
my mail five times, sending the password that 0wnz my ISP account to the four
winds each time.

I think the user should be aware of that by default.  If the user wants to check
the I'm Feeling Lucky box, then fine.

Comment 5

[Chapman Flack]

See also bug 234329.

Comment 6

[Christian Eyrich]

People will kill us if we bring up an alert each time we're going to send a
clear text password. So like for passwords over HTTP we'd need to offer the
"Don't warn anymore" box, would this be ok for you?

Comment 7

[Chapman Flack]

"Don't warn anymore box," comment 6: of course.  That's how the existing warning
dialog works and I meant to suggest using the same one or one very much like it,
because it's really the same issue.

...though maybe the wording would have to be a little different just so the user
doesn't think it's a trivial unimportant warning and click "don't warn again"
without thinking about it.  Something like "your mail service is not capable of
secure authentication, and using it will expose your password unencrypted every
time you {send|check} messages. You may uncheck the box below if you are willing
to accept that risk and do not wish to be warned again."

Ideally, there could be a "What are my options?" button or something, that would
lead to a help screen with more information, including "If you never want to
accept that risk, you may set Use Secure Authentication in Mail and Newsgroups
Account Settings, so Mozilla will never expose your account passwords. However,
Mozilla will not be able to use this mail server in that case.  You may also
ask your mail service to consider support for the secure authentication standards."

Or something like that.

Comment 8

[Christian Eyrich]

(In reply to comment #7)

> "Don't warn anymore box," comment 6: of course.

Ok, I just wanted to be sure.
So the question is if the warning should come up only once at all or at least
one time for each server/account. I.e. should the status of the "don't warn
anymore box" be saved in a per server variable or only global?
I guess you want it for each server.

I've a working patch for POP and modifying it for SMTP wouldn't be to hard.

The warning not only needs to be drastic but also shouldn't be to long I think.
Else the user won't even start to read.

> Something like "your mail service is not capable of secure authentication,
> and using it will expose your password unencrypted every time you
> {send|check} messages. You may uncheck the box below if you are willing to
> accept that risk and do not wish to be warned again."

Currently I have "Your credentials are about to be send in clear text. If your
mail provider supports it, you should either activate secure authentication or
secure connection to send it encrypted."
But that's far from perfect.

Also the checkbox is labeled "Alert me whenever I am about to send credentials
unencrypted."

> Ideally, there could be a "What are my options?" button or something

I've to use the standard ConfirmCheck function and there's no "Help" or "What
are my options" button available. We can explain the issue in the help system
and link to it in the text like "for more informations consult help".

Comment 9

[Chapman Flack]

> one time for each server/account. I.e. should the status of the "don't warn
> anymore box" be saved in a per server variable or only global?
> I guess you want it for each server.

To be honest, I hadn't precisely thought that far ahead, but I do agree it would
be more useful per server.

> "for more information[] consult help"

Maybe the only thing more I'd suggest here would be to name a specific help
topic or anchor, just because (as in comment 4) things can be in Help and still
not so easily found.

Of course it's suboptimal to have a message embedded in the code that could get
out of date if the help is ever reorganized, but I think the pointer is
valuable; maybe there's even some automated mechanism I don't know about to keep
it from going stale.

> I've a working patch for POP and modifying it for SMTP wouldn't be to hard.

Cool!  I knew there was a reason I use Mozilla....  :)

Comment 10

[Chapman Flack]

See also bug 263000.

Comment 11

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.