399174 - Invalid security certificate results in ssl_error_bad_cert_domain error, eventually hangs

Status: RESOLVED DUPLICATE of bug 429843

(Thunderbird :: Account Manager, defect)

Description

[Mike Stockman]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 3.0a1pre (2007100903)

Our Exchange 2003 server has a valid certificate for the fully-qualified domain name (as in mail.example.com) which is not valid for the internal network name for the mail server (as in mailserver). This used to result in a warning from Thunderbird when I was on the internal network, which I could accept to continue and use the server.

About a week ago, this broke. Instead of the "Certificate doesn't match, continue anyway?" message (paraphrased), I get this:

An error occurred during a connection to mailserver:993 because it uses an invalid security certificate.
The certificate is not valid for domain name mailserver.
(ssl_error_bad_cert_domain)

[The awkward line breaks are shown here exactly as they appear in the alert, by the way... some formatting cleanup would be good, too, if this remains an end-user-visible alert.)

Clicking OK results in being unable to use the mail server. Repeated attempts to use the mail server result in the same message, but after three or four repetitions Thunderbird hangs with the spinning pizza wheel of doom until I force the application to quit.

Reproducible: Always




This problem has existed since around the 10/04 trunk build, but it was not in the 10/02 trunk build. Therefore it was introduced somewhere in that range (I didn't check the 10/03 build, so I'm not sure about that version. Let me know if this doesn't narrow it down enough.)

Comment 1

[Jo Hermans]

It's temporary, caused by bug 327181. You can't override the security warning from the dialog box anymore, it has to be done with Tools->Options->Advanced->Encryption->View Certificates in Firefox, but there's still a problem in Thunderbird.

see bug 387480, bug 398718 and bug 399043

Comment 2

[Mike Stockman]

OK, I'm using Thunderbird version 3.0a1pre (2007102403), which supposedly has bug 399043 fixed, and I'm still seeing this bug and still cannot connect to the IMAP server.

This is clearly not fixed, or, if people think it's fixed, it's unusable. There is nothing in Thunderbird under View Certificates in TBird that appears to address this problem. Is it hidden somewhere else?

It was very convenient to click a simple button to tell TBird to go ahead and accept the mismatched certificate. Why is that gone?

Reopening bug.

Comment 3

[Phil Ringnalda (:philor)]

The steps that should now work are:

1. Attempt to connect to mailserver:993, get the bad_cert_domain error (you need to do that, to get the cert in the invalid cert cache)
2. Thunderbird - Preferences - Advanced - Certificates - [View Certificates]
3. Servers tab, [Add Exception]
4. Location: https://mailserver:993 [Get Certificate]
5. [Confirm Security Exception]

Comment 4

[Mike Stockman]

OK, that worked, so thank you. Although if you omit the port from the https link, it sets up the exception to use port 443 by default, and continues to fail on port 993.

So I suppose the bug is fixed, but the "fix" is painful and far less usable than before. Nobody is going to be able to figure that procedure out, and will either file new bugs, or decide that TBird is broken and avoid using it.

A more usable solution might have been to keep the original error dialog when a mismatch occurs, but add the necessary checkbox/fields/whatever to let the user make the override permanent. Why is this more-obscure fix a better solution than what was there before?

Comment 5

[Magnus Melin [:mkmelin]]

Confirming, I got this on one of the mail servers I have access to. Certificate is for mail....domain and the server is imap....domain. Clearly not many users will be able to figure out they should do like comment 3 (which worked btw).

Kai, is this the what the "real" solution - bug 399043 comment 1 - is about?

Comment 6

[Kai Engert [:KaiE:]]

(In reply to comment #5)
> Kai, is this the what the "real" solution - bug 399043 comment 1 - is about?


The "real" solution would work even if you omit step 1 from comment 3.

Comment 7

[Kai Engert [:KaiE:]]

In reply to comment 0:

The error message is by design.
If you want a cleanup in the line wrapping, please file a separate bug and cc johnath at mozilla dot com.

I don't understand why thunderbird eventually gets stuck and a hard quit is required. That shouldn't happen.


In reply to comment 1:

No, it's not a temporary behavior. The error message is supposed to be a full stop, and we no longer intend to offer a simple click through.


In reply to comment 2:

It's gone, because it was not "convenient", but "insecure", and it encouraged users to simply "don't care" about security, which is a bad thing. Feel free to read more about the background in the other bugs mentioned in comment 1.

Comment 8

[Mike Stockman]

The problem is that, when the error occurs, there is nothing in the UI to tell the user how to get around the error, and that should be unacceptable to any UI designer. I would suggest you need to make this process much more usable.

Security vs. convenience, right? To illustrate, a mail server would be perfectly secure if I locked it in a room without a network connection. It would also be completely useless.

I believe you've gone too far with this one, and need something like what Firefox did to solve the same problem. In Firefox, as I'm sure you know, they display a dialog that can walk the user, with sufficient dire warnings, through the override process. 

If you don't provide something similar to Thunderbird, people will stop using Thunderbird for mail. (That would ensure that no security breaches would occur with Thunderbird, of course. But I don't think that's the goal.)

Comment 9

[Daniel Veditz [:dveditz]]

The plan when we discussed eliminating the MITM-me dialogs was that the cert override was supposed to be hooked up to Account Setup. When you set up the server we should check the cert, and if it's invalid warn the user but offer to let them save it.

The steps in comment 3 are just a workaround until someone writes the UI.

During normal mail use if we get an unremembered invalid cert you're almost certainly being hacked and the connection should be rejected. It's not like a browser where you surf to different random web sites, your mail server should be a fairly consistent entity and a random new cert is exactly the behavior a MITM hack would exhibit. If the server does legitimately change you can go back to Account Setup.

Shouldn't "hang" though, is it really? I'd expect it to behave like any other case where we can't connect to the mail server -- eventually time out and report the error.

Comment 10

[Magnus Melin [:mkmelin]]

I can't confirm the hang-part, for the server I have access to. Only that there is no user-friendly workaround in place.

If it will get hooked up to the account setup (only), what about existing accounts? 

I can understand the SSL policy decision, but nevertheless it will definitely cause a lot of problems for a lot of users. With firefox3 betas I've already encountered about a dozen sites I can't get to without all the extra fuzz- something I doubt users in general will do through. 

Comment 12

[Eyal Rozenberg]

(In reply to comment #3)
> The steps that should now work are:
> 
> 1. Attempt to connect to mailserver:993, get the bad_cert_domain error (you
> need to do that, to get the cert in the invalid cert cache)

When I do that (with Seamonkey trunk), I get: 
"Port Restricted for Security Reasons 

Access to the port number given has been disabled for security reasons.

The requested address specified a port (e.g. "mozilla.org:80" for port 80 on mozilla.org) normally used for purposes other than Web browsing. The browser has canceled the request for your protection and security."

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Eyal
In about:config, create a string preference named
   network.security.ports.banned.override 
and assign it the string value 993

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

This seems pretty painful; marking blocking-thunderbird3+.

Comment 15

[Kai Engert [:KaiE:]]

Eyal, the pref that Nelson proposed should not be necessary.

It should be sufficient to do the following:
- try to fetch mail
- get the error box that tells you about the bad cert
- now go to cert manager and add an exception
- this time it will work without a "access to port disabled", because Thunderbird will have the bad cert remembered already.

I had introduced above workaround, because I ran into the same problem.

So, users who have tried to connect, and then set up an exception in the same session should succeed.

I did not know (think of) the workaround that Nelson made.

(Maybe Thunderbird should simply allow access to all ports, not banning them for XMLHttpRequest, although that's not a solution for seamonkey)

Comment 16

[Eliot Lear]

Came up against this one, myself.  Whatever the solution is, would it be possible to be consistent with Firefox on UI and behavior?  Thanks for all your hard work.

Eliot

ps: hi nelson!

Comment 17

[Philip Day]

Going from tbird 2 where I have been clicking through invalid certs to 3.0b1pre where I have to follow the steps in #3 to view my mail I have to question the reasoning on this. I care about security and I very much want my mail connection encrypted. I don't need ssl authentication - Self signed and miss matched certs are fine with me for pretty much everything except my bank. It should be easy to create exceptions.

Comment 18

[Michael Baffoni]

I also would like to see a more useful dialog box come up.  I don't agree that the only way to secure the product is to make it nearly impossible to work around certificate mismatches.  This happens legitimately in many situations; email clients that work in external and local/VPNed environments, multi-domain email servers, proxy servers that serve more than one server (let alone domains), etc. I agree, both from a UI and usability standpoint we should make TB3 behavior at least match Firefox3.  If that isn't acceptable to whowever (and however) makes these decisions, at a minimum a link that brings up the correct preferences dialog should be allowed.  Anything less is simply security through obscurity, a worse sin than dialog box click fatigue.

Comment 19

[David :Bienvenu]

you should now be given a chance to directly add an exception for the cert. Have you tried our pre beta 1 builds, http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b1-candidates/build1/ ? This bug seems like a dup of bug  429843