Need to figure out reasonable UI for how "security exceptions" are handled, since that changed a lot for firefox3. At the moment, there is no way normal users would find out how to access a server which has an invalid certificate, e.g. self signed certs also included. The current way of doing it on trunk is bug 399174 comment #3. On tb2.0, you only had to click accept in a dialog. At the moment two of the servers I have access to uses invalid certs, so I assume it's fairly common.

My server does also.

If the steps in bug 399174 comment #3 work, the job may be done. I believe that was/is the UI that was planned for this.

No, bug 399174 comment 9 reminds me that the add-exception UI is supposed to be integrated into account setup, so the UI's not done, but it is possible to add the exception using the technique outlined in bug 399174 comment #3. Some people report experiencing a hang when they try those steps. Is there any aspect of THIS bug that is not a duplicate of bug 399174?

Yes, this is quite a bit similar to bug 399174. Created a new bug to make sure it didn't get side-tracked based on whether it hangs or not, and also to not focus on that specific error only but on in general letting users set up exceptions in a sane way.

I don't see how to use bug 33914 comment #3, because the cert is not in my certificate file. And there is no way to import it.

James: note, this bug is strictly about the behavior in tb3.

(In reply to comment #6) > James: note, this bug is strictly about the behavior in tb3. > Doesn't this one cover the similar Issue for SeaMonkey-Trunk too, since it was filed for "core"? And I am going with comment #4 too, that there was a need for this Bug to be sure to cover the UI-Issue for accepting and security exeption in MailNews. The description from Bug 399174 comment #3 works for me (use self-signed certificates too), but it was a little too "hardcore" for "normal" Users. So I think there should be an UI-Dialog in MailNews with the possibility to accept an exeption, like in Browser for SSL (https:) at port 443.

Yes, seamonkey2 too.

Being ``a little too "hardcore" for "normal" Users'' is exactly the intent. The idea is: make it harder to do, and people will want to avoid doing it (which they should always have wanted, but didn't because it was just too easy). That will bring pressure to bear on mail server admins to shape up their act and start using certs that offer more than "proof by assertion" of identity, which will (in turn) reduce the need for users to create exceptions. Now, in comment 5, James Rome wrote that he can't (or hasn't yet figure out how to) create an exception for this cert. James, if you're using seamonkey trunk, please give me the info about your server (host name, port, and is it starttls or is it POP3S?) and I'll see if I can figure it out with SM trunk for you. Obviously I don't need an account on that server to investigate this since the SSL comes into play before the account login.

I'm using Thunderbird 2.0 Pre Its POPS at mail.sciend.com I am pretty expert at certs, and there is no save cert option.

James, In SeaMonkey trunk, I configured a POP3 SSL account at mail.sciend.com port 995. The first time I tried to "Get Messages For Account", It got this dialog: > Alert > mail.sciend.com:995 uses an invalid security certificate. > > The certificate is not trusted because it is self signed. > The certificate is only valid for localhost. > > (Error code: sec_error_ca_cert_invalid) > [ OK ] Then I opened the security manager's servers tab and clicked "Add Exception" In the add exception dialog, I entered the URL https://mail.sciend.com:995/ (yes, https) and clicked "Get Certificate". It's got the cert immediately. Then I viewed it, and added it as a permanent exception. After doing that, the next time I tried to "Get Message for Account", it completed the SSL handshake without incident. Now, those steps probably would not work if the server used StartTLS on the usual POP3 port instead of using POP3-over-SSL (on port 995). And they might not work on TB. But please give them a try and let us know how it works for you.

Seamonkey 1.x and evidently TB2 offered dialog boxes as a way to bypass this exception in mail connections. Either bringing the same dialog code into the current mail/news module or adding a mechanism to automatically this problem would be nice. The tinkering with certificates described above is not what typical users of browser/email software want to be doing. A common reason why this exception occurs is that the mail domain name isn't the same as the host name. For all I know, the host handles a thousand domain names besides mine. Leaning on the management of that host doesn't sound any more practical than urging those developing TB and Seamonkey Mail to add the same dialog box that SM 1.x has, or a list of site aliases that automatically enable TB and Seamonkey Mail to handle name mismatch exceptions. This is particularly true when other email programs must have their own work-arounds for these exceptions, and when a solution has already been developed for previous versions of TB and SM.

(In reply to comment #14) > The tinkering with certificates described above is not what > typical users of browser/email software want to be doing. Exactly. We don't want them to. The click-through dialogs have been removed deliberately. We want server admins to get a real certificate, if they want to use encryption, which doesn't make sense without identity verification. And power users who really insist on using SSL without that will find out how to.

No. This is not reasonable for local ISPs that do hosting. Lots of real certificates cost lots of money. As a user, I want the ability to accept the certificate. I knopw enough to tell if it is a good idea or a bad idea, so please fix this and restore the click-thru dialog. As someone else mentioned, one ISP may host hundreds of domain names, and it makes no sense to have a "real" certificate for each one if the domain owner (me!) does not want to spend the extra money.

If your mail server is hosted at some remote ISP with a self signed cert, you don't get any benefit from using encryption. Go to an internet cafe, and the people operating that cafe can Man-In-The-Middle your connection, and you (at least most users) would click-through without noticing whether it's the usual cert or a fake MITM cert. Attacker can read your password and content. If you don't care about this risk, just use a plain connection (no SSL).

Of course I get a benefit. My password, and the content of my e-mails are protected. I do not use internet cafes. If my connection can be subject to a man-in-the middle attack, I can be attacked with or without a certificate. So there IS a benefit to encryption. I do security for a living, and your arguments are not valid for smart users. Dumb users will get hacked anyhow. And, the ISP may have a real certificate that does not match my domain name, but I want to accept it because I know they are hosting my domain.

(In reply to comment #18) > protected. I do not use internet cafes. If my connection can be subject to a > man-in-the middle attack, I can be attacked with or without a certificate. So > there IS a benefit to encryption. Yes the benefit that if it isn't a man in the middle attack, your traffic is safe. But no, you wouldn't be exposed to man-in-the middle attacks as it is on trunk, since the attacker wouldn't have the correct certificate and you'd have to jump through hoops to make the connection work at all (and make you very suspicious). This bug is not about adding back the click-through dialogs, but to find a way to make it *reasonable easy* to accept self-signed certs (etc.).

And someone is forgetting all of the discussion that we had about fixing this very same issue in Firefox. The way it was resolved for Firefox would be perfect for Thunderbird as well. i.e. make it hard to have execptions, but still *possible* without going through 30 clicks to get to a buried preference window. A link to click that prefills the domain (and port) in the Add Exception dialog would be all it needs.

(In reply to comment #17) > If your mail server is hosted at some remote ISP with a self signed cert, you > don't get any benefit from using encryption. With the way the current exception mechanism works, sure you do. You connect from a trusted location (where you trust how you're connected) when you add your exception the first time. There is no way to guarantee that's who you're connected to if it's self-signed, of course, but by adding an exception I *can* guarantee that every future connection is going to the same place, because once the exception is added, you're still tied to the specific certificate you created your exception for. Now that the exception is in place, it will never prompt me again as long as I still get that same certificate when I connect. If that cert ever changes, then I get prompted again. So your argument is a bit of a red herring.

James Rome wrote: > Lots of real certificates cost lots of money. Only if you get them from a CA that charges money. There is now at least one real CA, audited and trusted in Mozilla products, that offers certs for free.

I've never used a self-signed certificate, only the ones included with Mozilla/Seamonkey builds. Up until SM 2.0pre, the mail has worked. I am sure that I tested mail in SM 1.5 until some library upgrades were used, and I am finding the problem now because I just did an OS upgrade and can test again. It's a very bad idea to remove a method of handling a name mismatch exception that worked perfectly in SM 1.x without replacing it with a better work-around. Why was the dialog box solution discarded? It worked! Many servers host multiple domain names and incur name-mismatch conditions, and it appears that all other email programs in common use handle this condition without arguing or refusing the connection. You can bet that Outlook Express doesn't.

Nelson, the issue should not be whether Mozilla trusts the cert. For free, I doubt that the CA does anything more than verify an e-mail address. That is not worth any more than a self-signed cert IMHO. And I have no control over what my ISP chooses to do.

(In reply to comment #22) > James Rome wrote: > > Lots of real certificates cost lots of money. > Only if you get them from a CA that charges money. > There is now at least one real CA, audited and trusted in Mozilla products, > that offers certs for free. The cert might be free, but IP addresses are not. Dreamhost, for example, hosts a few hundred thousand domain names (no, I'm not making that up, go read their blog, it's been talked about). I can guarantee you they don't have a few hundred thousand externally addressable IP addresses at their disposal. Because SSL negotiation happens before the hostname is know, a separate IP address (or port) is required for each certificate you use. Getting an allocation of IP addresses from ARIN costs money. Dreamhost currently has 3 mail server IPs. mail.yourdomainhere.tld for each one of those few hundred thousand domains points at one of those three IPs. The CA-signed certificates are all for *.mail.dreamhost.com (which in itself is a guaranteed name mismatch even if you use the real hostname because the real hostnames have 5 atoms instead of 4, and that cert only matches 4 of them).

Dave Miller wrote: > Because SSL negotiation happens before the hostname is know, a separate IP > address (or port) is required for each certificate you use. Absolutely FALSE. Host name negotiation during the SSL handshake has been supported in FF since FF 2.0.0.0. There is no longer any reason to have only one host name per IP address.

Further, it is possible to have MANY host names on a single cert. The number of host names possible is limited only by the total size, and the willingness of the CA to put many names into a cert. The size limit is 16 MB, IIRC.

(In reply to comment #26) > > Because SSL negotiation happens before the hostname is know, a separate IP > > address (or port) is required for each certificate you use. > Absolutely FALSE. Host name negotiation during the SSL handshake has been > supported in FF since FF 2.0.0.0. > > There is no longer any reason to have only one host name per IP address. But Apache doesn't support it yet (except in a development version that nobody ships yet), and neither does IIS. And most mail servers don't, either. On top of that, I bet Outlook Express doesn't support it either, nor probably a good dozen other email clients. ISPs can't expect to use that kind of technology if a majority of their customers have client software that doesn't support it, and they can't get a supported server that supports it. (In reply to comment #27) > Further, it is possible to have MANY host names on a single cert. > The number of host names possible is limited only by the total size, and > the willingness of the CA to put many names into a cert. The size limit > is 16 MB, IIRC. And (using Dreamhost as the example here again), domain names come and go rapidly. They'd be having to get their certificates re-issued on a daily basis. And who wants to download a 16MB certificate just to connect to a server to check their mail when they're on dialup?

But all of the above notwithstanding, why are we even having this conversation again? We beat this issue to death when the UI was getting updated in Firefox. We're not asking for something you guys haven't already given here. We're asking for Thunderbird to get UI that's on parity with what's already in Firefox 3. Currently it doesn't. Thunderbird 3 outright prevents you from connecting to a mail server with an invalid cert. Firefox 3 does not prevent this (there's a tiny Add Exception link with lots of warnings). And with mail servers, you're MORE likely to run into invalid certs than you are in a web browser, so this issue is even more important in Thunderbird. If Thunderbird 3 had the same UI for this that Firefox 3 already has, everyone would be happy.

Secure POP and SMTP mail is impossible in Seamonkey too when there's a name mismatch. That's why I set the severity level on my dupe report of this to severe, a major component (email) is broken. This bug ought to have its severity level raised too, because for those who encounter the problem, it's a blocker rather than an inconvenience. Why take something that already worked and break it, make it no longer work? Who calls that progress?

(In reply to comment #27) > Further, it is possible to have MANY host names on a single cert. > The number of host names possible is limited only by the total size, and > the willingness of the CA to put many names into a cert. The size limit > is 16 MB, IIRC. I think it's unlikely to expect that the ISP issues a new certificate every time one customer gets added or removed. I think the solution is: (In reply to comment #25) > The cert might be free, but IP addresses are not. Dreamhost, for example, > hosts a few hundred thousand domain names (no, I'm not making that up, go read > their blog, it's been talked about). I can guarantee you they don't have a few > hundred thousand externally addressable IP addresses at their disposal. > Because SSL negotiation happens before the hostname is know, a separate IP > address (or port) is required for each certificate you use. Getting an > allocation of IP addresses from ARIN costs money. > > Dreamhost currently has 3 mail server IPs. mail.yourdomainhere.tld for each > one of those few hundred thousand domains points at one of those three IPs. > The CA-signed certificates are all for *.mail.dreamhost.com Why don't you simply set the config to use the real hostname, instead of your virtual domain? In other words, as your mail server hostname, use mail.dreamhost.com (or the more generic name).

(In reply to comment #30) > Secure POP and SMTP mail is impossible in Seamonkey too when there's a name > mismatch. It's not impossible. You can configure an exception. > Why take something that already worked and break it, make it no longer work? > Who calls that progress? Please don't bash in bugzilla.

(In reply to comment #29) > We're not asking for something you guys haven't already given here. We're > asking for Thunderbird to get UI that's on parity with what's already in > Firefox 3. Currently it doesn't. Thunderbird 3 outright prevents you from > connecting to a mail server with an invalid cert. Firefox 3 does not prevent > this (there's a tiny Add Exception link with lots of warnings). And with mail > servers, you're MORE likely to run into invalid certs than you are in a web > browser, so this issue is even more important in Thunderbird. If Thunderbird 3 > had the same UI for this that Firefox 3 already has, everyone would be happy. And I am not rejecting your request. It's just that nobody has worked on it yet. We changed the security policy in the backend and made it be more restrictive. This was a backend change that automatically affects all apps. At the same time we added support for persistent exceptions, that was a core change, too, which allows application to be more user friendly as it has been possible in the past. Now someone has to work on the User Interface code for the mail applications. The developer who worked on the user interface for Firefox was not interested to work on Thunderbird, it's that simple. Someone must step up and get it done, or donate developer resources to get it done.

In reply to comment 31, Kai's suggestion is exactly what I do. My mail service provider does hosting for many domains, including the domain I use, bolyard.com. The provider's IMAP/POP server is mail.hostedemail.com which has numerous DNS aliases, one for each domain they serve. Their instructions tell their customers to use mail.yourdomain.com, but their SSL certificates are for mail.hostedmail.com. So I just configure my POP3S, IMAPS, and SMTPS accounts for mail.hostedemail.com instead of mail.bolyard.com. I haven't seen a host name mismatch error in years. When I access any of those servers, I must authenticate using my full email address as the login ID. That suffices to tell the server which of the numerous domains to use for my connection.

I can't get my ISP to do anything. But can't you steal the Firefox code to make exceptions for a certificate? And I would like a manual way to do this, but see none. I used to be able to import a server certificate, but that seems to be gone too.

(In reply to comment #35) > I can't get my ISP to do anything. Ask your ISP what the hostname of their server is, the hostname in DNS and the hostname listed in the cert shall be identical, and that's what you should configure in your prefs. > But can't you steal the Firefox code to make exceptions for a certificate? Well, we DO have generic user interface code to add an exception. edit/prefs/advanced/encryption/certificates/servers/add exception Make sure you have (unsuccessfully) connected to your mail server in the same session (got error message), before you attempt to use the above dialog to add the exception. No,the Firefox specific user interface, which exists in addition to the above, can not be simply copied. That navigation is constructed around error messages shown in web pages, something thunderbird doesn't do. > And I would like a manual way to do this, but see none. I used to be able to > import a server certificate, but that seems to be gone too. Did you find the "certificate manager" dialog and its server tab at all? Both the old style "import cert from file" and the new style "add exception" are available.

Well, my ISP uses a cert to "localhost". There is no edit/prefs/advanced/encryption/certificates/servers/add exception on the Mac. And no add exception in the Certificate Manager. There is also no way to capture the ISP's localhost certificate, so I cannot import it. I have my own CA and use certs all the time, but see not way to get around this. This is why this is so important to fix.

In reply to comment 37, it sounds like the Mac front-end is seriously broken/deficient. That's a bug that should definitely be fixed ASAP. James, Please file a separate bug about that, reporting that the MAC version should expose all the features available on Windows and Linux, citing these as examples of what's missing. As for your mail service provider, maybe you should vote with your wallet. Or, if that mail service provider is DoD operated, I'm sure pressure can be brought to bear to get it corrected.

Um, that's not the Mac front-end being broken, that's the instructions he's attempting to follow being mildly bent. Mac would be "Thunderbird menu, Preferences, Advanced tab, Encryption tab, View Certificates button, Servers tab, Add Exception button."

This is what I see in Preferences1. No place for certificate exceptions.

And viewing the certificate does not give you an option to save the certificate.

James, what you have attached looks like UI from Firefox 2. This bug is about Firefox 3.

It is Thunderbird 2.0.0.15pre which I am trying to get fixed before it is released. Is 3.0 better? Where do I get it? But I need to have Enigmail as a plugin.... Firefox has no mail/news UI, so this is NOT about Firefox!

Well, I found 3.0a3 and installed it. I still can't add an exception because I do not know the URL to put into this box. And Thunderbird HUNG here and I had to kill it!

And force quit would not kill it, nor would trying it as root from the command line.

James: as far as I know it only works if you use a real SSL connection. If you use a cleartext base connection with STARTTLS overtop of it, then you won't be able to use this. For the URL, put in "https://your.mailprovider.tld:995" and replace the 995 on the end with the port number you use to connect to your mail provider with SSL (for pop3 that's usually 995, for imap it's usually 993). Yes, it's https, despite whatever protocol you're really using. :) (In reply to comment #33 by Kaie Engert) > And I am not rejecting your request. > It's just that nobody has worked on it yet. Why didn't you just say so in the first place? :) The last several comments before that to which I was replying sure as heck sounded like "We don't want to do that." The above would have been plenty of statement to get me to stop yelling so loud about it. :)

Ah, that worked. Many thanks. Very few users would know that they should use that URL. An example might help in the GUI. But it is more logical to have the user be able to save the certificate from the pop-up box, which now prints out a lot of gibberish.

And on the crash. It was very ugly. I had to power off. What I think happened is that after the boxes in the picture got displayed, I clicked the main TB window to move things so as to get a better picture. At that point, the dialog boxes in the screen shot refused to accept input again and things hung.

(In reply to comment #46) > James: as far as I know it only works if you use a real SSL connection. If you > use a cleartext base connection with STARTTLS overtop of it, then you won't be > able to use this. No, it will still work, under one precondition: You have attempted a connection in your current session already (and got the error message). Then it will work, because the bad certificate is already in a cache, and when you use the UI to ask for that hostname and port, it will directly use the cert from the cache. >> For the URL, put in "https://your.mailprovider.tld:995" and >> replace the 995 on the end with the port number you use to connect to >> your mail >> provider with SSL (for pop3 that's usually 995, for imap it's usually 993). >> Yes, it's https, despite whatever protocol you're really using. :) > Ah, that worked. Many thanks. Very few users would know that they should use > that URL. An example might help in the GUI. Right. Using such a strange URL for a mail protocol is absolutely counter intuitive. When I had proposed the original UI for the add-exception dialog (which is shared UI amonst all applications), I made a proposal which would have worked better for the generic case: A separate hostname field (not URL), and separate port number field (or even a radio box to select your protocol). But my proposal was not accepted. Instead I was asked to implement a single URL field (which really only makes sense for Web). Yes, it's true, you can construct an URL for any protocol. But end users have no idea about that.

Kai: I agree that the URL people are currently using is bogus, but I think it makes sense to have slightly different UI for different products. We don't need to complicate the UI for Firefox users in order to make it work also for Thunderbird generically. IMO, it should Just Work if you put the name of your server in the box. It should pick the right protocol, guess the standard port number(s) and try and get hold of a cert. Gerv

I agree with Gerv. You have entered the mail server and the protocol, so Thunderbird has all it needs to do this. Only mail server (as opposed to Web Server) certificates need be handled. So yes, it just works. And I was sad to see that after getting my server to work in 3.0, the exception did not propagate back to 2.0. Don't they share the same certificates file in my profile?

What's the current state of thinking about how to address the name mismatch problem?

Judging by the number of duplicate bugs, this looks like one that hits a number of people - me included since my server's certificate (acceptable in TB2) expired and was rebuilt - self-signed as usual, but now with no way to accept it in TB. Is there some reason that the UI in the dialogue box that was there in TB2 got removed in Shredder? Here's the error I get ... mail.path.net:465 uses an invalid security certificate. The certificate is not trusted because it is self signed. (Error code: sec_error_untrusted_issuer) I think its worth remembering the different reasons that SSL is used. In some cases - e.g. banks - its important because of establishing identity, and stopping a variety of fraud techniques. For email (and for some web sites) it is mostly used to ensure that passwords go over the net encrypted. Far from enhancing security, the current inability to use SSL just means switching back to un-encrypted email, but of course many people won't have that option. Does this bug require the complexity above, or is the relatively small subset - that of handling unusable SMTP/POP servers - fixable in a more simple way?

I think we're going to have to have two different methods of handling this situation. Here's how I'm looking at the problem. (1) During account creation. Self signed certificates are much more common with mail systems than they are with commercial web sites, we need to be flexible towards this. Creating an account is a one time activity for lifetime of using an account. I don't think we want the old dialog with lots of confusing text, but we'll need to allow people to continue. (2) During regular use. If a certificate changes from whatever is stored it is much more likely that something really bad is happening (compared to (1)). We cannot be flexible during this time, in fact we need to proactively attempt to teach the person about the different reasons why this could be happening. Questions like "Are you using a different network than normal?" need to be shown to the person, we need to (practically) scare the user into changing something else before attempting to jump through the hoops necessary to get by. Documentation should provide admins who have made a change like this with the correct instructions for people to use and get by. It's statistically less likely that during the life of using Thunderbird a MITM attack will occur during account creation versus any other time. While that's not a satisfying guarantee it seems too painful to be too strict on (1). That said, davida had an excellent idea the other day for this dialog that I'm going to try in a mockup. Encouraging and educating people to become more secure than they are, without being limiting. Will post soon.

Case 2 is not at all uncommon, certificates expire, and news one are created to replace them. I'm not saying we don't need to scare the user, but they need a way around the certificate having changed.

I agree with comment 57, emphatically. Account configuration is the right context to establish cert trust. Error dialogs are absolutely NOT the right context to establish cert trust. Yes certs expire. There needs to be a way, in the account editing, to replenish the trusted cert for the account. But don't feel you need to make is really really easy for people to get from the error dialog to the account editing dialog. If you do that, you might as well put back the one-click-bypasses-all-security-errors mentality that provides no security whatsoever. When an error occurs, tell the users that, if the server has changed, then they need to reconfigure the account. They should know how to do that, because they've done it before. Doing so, going through the motions of getting into account manangemen, should get them to think about the gravity of what they're doing.

What's being done to enable an account with a domain name different from the host and the host's certificate to be accessible? I just tried prefixing mail. and mail.worldlinc. to my server's name and didn't connect. This needs to be fixed before software is rolled out to the public without the dialog box workaround in SM 1.x, etc.

We'll need to setup brand new UI to inform people of the issues with the certificates, and setup overrides. There are a bunch of sub-parts to this: 1) new account configuration -- this one is under way in a branch and discussed in bug 422814. 2) upgrade scenarios from existing profiles. I don't recall what bug is discussing this, but we'll likely use similar UI words, in an upgrade-only context.

This bug seems to be getting a bit old now, with no real progress (something that seems common with security issues - whether there is no real correct answer in the balance between usability and security). In the meantime - until the "perfect" solution is found, can we have a simple exception so that the system is usable for people encountering exceptions. For example ... today I'm trying to send email from a client's. They are on an ISP that blocks SMTP other than through their own mailservers (a misguided attempt to block spam) so my only option is SMTP-over-SSL, but the mail server for my domain uses self-issued certificates - (a compromise between security and expense of purchasing certificates for every domain) So as a result I get the error: sec_error_untrusted_issuer and NO WAY to send email from this location. I think this bug needs escalating - its a major feature (Ability to send email) that is broken without a way to handle exceptions. - Mitra

IMHO this should block the release of Thunderbird 3 for sure. Saving the user from himself is useless if you cannot do your work properly. This scares people too, and unnecessarily. I attach a screen shot of a recent experience from Comcast. This is a MAJOR ISP, and even though I had the regional manager contact Comcast about this, it is a total black hole. So the average user is totally scared and unsure what to do. My girlfriend in fact called me about this in a panic. In fact, I am sure that Comcast was tweaking their server somehow because it disappeared after a while. And suppose the cert was indeed bogus. If Comcast was indeed hacked, my mail would already be exposed. So there is no downside to letting me get my mail without this intrusion .

(In reply to comment #64) > Created an attachment (id=342866) [details] > The scary situation with Comcast > > IMHO this should block the release of Thunderbird 3 for sure. If you look at the bug status at the top of the page, you will already see this bug has been granted blocking-thunderbird3. Additionally comment 61 gives the current status - which is that we're currently fixing other things which will also help fix this bug.

(In reply to comment #64) James, I use comcast with POP and SMTP over SSL and NEVER have any problem with their certs. I suspect you're not using the recommended configuration, which is to use the setting named "SSL" on host mail.comcast.net port 995. I'll bet you're using the misnamed setting "TLS" on a host with a different name or a different port number. I'll further guess that you're using the misnamed TLS setting because you've been told you need to use TLS and not SSL 3.0. Unfortunately, those settings were named by someone who didn't understand the terms, and the names do not even remotely suggest their true meanings. Use the "SSL" setting. If you ARE using the SSL setting and port 995, then email me the IP address that you get for mail.comcast.net.

Nelson, I am using the SSL setting. And usually I have no problems. But both myself and my girlfriend have seen these certs presented. I suspect they were mucking with the servers. And I sent mail to security@comcast.net, and had the local engineer file a service request with headquarters, all with absolutely no response. nsljarmac:~ jar$ nslookup mail.comcast.net Server: 68.87.68.162 Address: 68.87.68.162#53 Non-authoritative answer: mail.comcast.net canonical name = mail.g.comcast.net. Name: mail.g.comcast.net Address: 76.96.62.119 But these messages are scary, and if you get a cert like the one I got (and I have seen it twice now), it is very scary.

(In reply to comment #66) > I'll further guess that you're using the > misnamed TLS setting because you've been told you need to use TLS and not > SSL 3.0. Unfortunately, those settings were named by someone who didn't > understand the terms, and the names do not even remotely suggest their true > meanings. Use the "SSL" setting. I guess Nelson had Bug 350314 on mind.

James, In reply to comment 67, I think you're being too quick to want to override this bad cert error. The cert you showed in the screen shot is NOT the correct cert for mail.comcast.net, and is not the cert I get when I visit that server. I think you're occasionally getting a connection to a rogue server. This is SSL/PKI doing what it's supposed to do: detecting bogus servers. You want your email to work, but overriding a bad cert error is probably the wrong way. This is a case where having the cert override would probably defeat your own security, rendering you vulnerable. In reply to comment 68, I did indeed have bug 350314 in mind.

I agree this is a bad cert. But how can I tell if Comcast was fiddling, or whether it was a hack? The connection did in fact retrieve all my mail. So is Comcast vulnerable to the DNS poisoning attack? It is worrisome.

this puts up the cert exception dialog for imap (tested) and pop3 (haven't tested pop3 yet). It gives a rather scary warning, though it's a bit web-centric, and doesn't specify the host names involved...but it doesn't require any string changes, or require trying to duplicate any of the logic in the ssl cert code to try to figure out what's wrong with the cert and explain it to the user. I'm trying to get the ssl cert code to generate the error text for us, but that requires a doc shell - I may be able to do that with an aggregate interface requestor, but I'm not sure if that's going to work.

+function BadCertHandler() + { +} There seems to be a missing opening "{" + QueryInterface: function(iid) { + if (!iid.equals(Components.interfaces.nsIBadCertListener2) && + !iid.equals(Components.interfaces.nsIInterfaceRequestor) && + !iid.equals(Components.interfaces.nsISecureBrowserUI) && + !iid.equals(Components.interfaces.nsISupports)) + throw Components.results.NS_ERROR_NO_INTERFACE; + return this; Would this be equivalent? if (iid.equals(Components.interfaces.nsIBadCertListener2) || iid.equals(Components.interfaces.nsIInterfaceRequestor) || iid.equals(Components.interfaces.nsISecureBrowserUI) || iid.equals(Components.interfaces.nsISupports)) return this; throw Components.results.NS_ERROR_NO_INTERFACE; + var gOverrideService = Components.classes["@mozilla.org/security/certoverride;1"] Why the "g"? + if (status.isUntrusted) + { + + flags |= gOverrideService.ERROR_UNTRUSTED; + } braces? + let certCommonName = cert.commonName; + dump("certCommonName = " + certCommonName + "\n"); ? dump("certCommonName = " + cert.commonName + "\n");

asking Neil for sr for the backend parts, Standard8 for review of the whole thing. The basic approach is that we add a bad cert listener to the msg window, and the backend imap/pop3 code will set this bad cert listener on the transport, which will cause mailWindow.js's bad cert listener to put up the cert exception dialog. I haven't dealt with SMTP yet - that's going to be tricky to test since my ISP blocks those ports...

(In reply to comment #73) > Created an attachment (id=348682) [details] > patch for review I'm currently having a bit of trouble testing this out. I've got a pop mailbox set up to one of my other machines with an untrusted cert. If I start up and get mail, then I get the cert dialog, but whatever I put in it, it won't get the certificate. Most likely to do with: WARNING: port blocked: file ../../../dist/include/necko/nsNetUtil.h, line 657 on the console. However if I go into Preferences, access the certificates dialog from there and add exception, it allows me to do it fine. I'm guessing this is something to do with the protocol handling, I'm going to dig around a bit and see what is happening where.

You shouldn't have to put anything in - the dialog should just work with what's pre-filled. What I've seen sometimes is that it fails the first time, and succeeds the second time, but I don't know why...I'll look to see if I see that port blocked warning.

Comment on attachment 348682 [details] [diff] [review] patch for review I've found my problem. Note that I have check for mail turned off on startup (which I think is the default) and was selecting the Get Mail button with the account inbox selected. The problem is that we're blocking in the notifyCertProblem function of the listener - the interface says we shouldn't do this (http://mxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/public/nsIBadCertListener2.idl#46) and if I change the call so that the window is opened after a timeout, then I get the certificate presented to me. So I guess that because we're blocking, the code can't get the bad certificate from its cache or the connection, hence the problem I'm seeing.

oh, I was doing it in a timeout earlier and ripped that out (see previous patch). I'll put that back.

Comment on attachment 348682 [details] [diff] [review] patch for review marking obsolete; I'll submit a new patch later today

This uses setTimeout (thx for figuring that out, Mark!), and fixes SMTP to use a bad cert listener as well. Requesting sr from Neil for the backend parts - I don't think SeaMonkey will be affected by these changes, but they should enable SM to do something similar if it wants.

Comment on attachment 348835 [details] [diff] [review] proposed fix >+ attribute nsIBadCertListener2 badCertListener; IMHO this should be an nsIInterfaceRequestor; none of the mail backend code should care as to what this listener does, and it leaves the way open for nsIBadCertListener3 etc. ;-)

yes, that sounds like a very good idea - though I reserve the right to change my mind if it turns out to be an enormous pain :-)

make nsIMsgWindow have an interface requestor for for a notificationCallback, so the backend doesn't need to know about nsIBadCertListener2.

Comment on attachment 348912 [details] [diff] [review] implement Neil's suggestion >+ >+/** >+ * This class implements nsIBadCertListener. Its job is to prevent "bad cert" >+ * security dialogs from being shown to the user. Currently it puts up the >+ * cert override dialog, though we'd like to give the user more detailed >+ * information in the future. >+ */ >+function BadCertHandler() { >+} >+ >+BadCertHandler.prototype = { >+ // Suppress any certificate errors >+notifyCertProblem: function(socketInfo, status, targetSite) { >+ if (!status) >+ return true; >+ >+ setTimeout(InformUserOfCertError, 0, socketInfo, targetSite); >+ return true; >+}, nit: the comment is correctly 2-space indented, but the rest of the items in the prototype need moving across 2 spaces as well. >-[scriptable, uuid(35A79B64-F3DA-40e8-8A6F-4FCCF8FD7DB0)] >+[scriptable, uuid(7e8fbaaa-d2f1-4751-af8e-8213fdb60a02)] > interface nsIMsgWindow : nsISupports { > attribute nsIMsgStatusFeedback statusFeedback; > attribute nsIMsgWindowCommands windowCommands; > attribute nsIMsgHeaderSink msgHeaderSink; > attribute nsITransactionManager transactionManager; > attribute nsIMsgFolder openFolder; > attribute nsIDocShell rootDocShell; >+ attribute nsIInterfaceRequestor notificationCallback; >+ We need to documnent what this is and what it can be used for. > nsCOMPtr<nsIMsgFolder> mOpenFolder; > nsCOMPtr<nsIMsgWindowCommands> mMsgWindowCommands; >- >+ nsCOMPtr<nsIInterfaceRequestor> mNotificationCallback; >+ nit: blank line isn't blank. I've only tested the pop setup for this, but I can't see a reason for the other two not working. I think we should file a popup bug on ensuring that the User Experience for this dialog is good enough post beta 1 - currently I think its not totally clear why we're popping up the dialog and asking for the security exception, but this is good enough to get something easier for users for beta 1, so we might just want to relnote what we're doing, and look at it again for beta 2.

Comment on attachment 348912 [details] [diff] [review] implement Neil's suggestion >+ Nit: whitespace (×6) >+ * This class implements nsIBadCertListener. Its job is to prevent "bad cert" Nit: nsIBadCertListener2 >+ if (!status) >+}, Nit: trailing whitespace >+ msgWindow->GetNotificationCallback(getter_AddRefs(interfaceRequestor)); >+ m_mockChannel->SetNotificationCallbacks(interfaceRequestor); I noticed that everywhere else (both inside mailnews and outside) we call it Callbacks (plural), would you mind making the new one plural too please?

Bug 465795 filed as a followup. I changed it to notificationCallbacks everywhere, and fixed the other nits...

adding relnote keyword

Don't we need a SeaMonkey-specific part of this as well?

Yes, I said as much in #79. Most of this work was in the backend, but there was a small UI piece which SM probably wants to emulate. Can you file a new SM bug for that?

(In reply to comment #88) > Can you file a new SM bug for that? Done, bug 465978.

Hi, I'm porting new cert error page to SeaMonkey (bug 463504) and faced problem with this bug patch. When mail window open in SeaMonkey and I'm opening secure site in browser, I'm getting both security exceptions dialog and cert error page. I'm not familiar with mailnews code, but i think it should check protocol part of URL to call security exceptions dialog only for mail servers.

(In reply to comment #90) > Hi, I'm porting new cert error page to SeaMonkey (bug 463504) and faced problem > with this bug patch. When mail window open in SeaMonkey and I'm opening secure > site in browser, I'm getting both security exceptions dialog and cert error > page. I'm not familiar with mailnews code, but i think it should check protocol > part of URL to call security exceptions dialog only for mail servers. I'd be surprised if that is the problem, as the BadCertHandler/callbacks are only installed on the url mechanisms that are specific to the mailnews code (e.g. imap, pop, smtp). To have them "leak" across to the http protocol implies there is something wrong somewhere else.

Mark is right - we're only installing the bad cert listener on imap/pop3/smtp channels, and using a mechanism, nsIMsgWindow, that is not used in browser windows. Maybe SeaMonkey doesn't disable net error pages the way TB does?

I've a problem with "Check for new messages at startup" on my IMAP accounts. I use TLS and authentication with client certs. The Server log shows a OpenSSL error for every folder: "SSL_accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate" When TB is running "get messages" works fine. When I backout revision e0cc75f26657 the problem is also gone! http://hg.mozilla.org/comm-central/rev/e0cc75f26657 Tested with TB from comm-central build checkout begin: 2008-11-21 18:22:50 UTC Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081121 Shredder/3.0b1pre

Alfred, are you seeing errors in the client or just on the server? Are you checking all folders for new mail? Do you ever see the cert exception dialog? All I've really changed is to get the ssl code to tell us about errors instead of putting up a dialog, so I'm very surprised that it's behaving differently.

(In reply to comment #94) > Alfred, are you seeing errors in the client No. > or just on the server? Yes. > Are you > checking all folders for new mail? Yes, I use: user_pref("mail.check_all_imap_folders_for_new", true); user_pref("mail.imap.use_status_for_biff", false); > Do you ever see the cert exception dialog? No, never. And nothing in the TB log: | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:SendData: 2 STARTTLS | | 3052[394e0f8]: ReadNextLine [stream=3960168 nb=28 needmore=0] | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation | | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:SendData: 3 capability | | 3052[394e0f8]: ReadNextLine [stream=3960168 nb=0 needmore=1] | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff6 | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:TellThreadToDie: close socket connection | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:CreateNewLineFromSocket: (null) | 3052[394e0f8]: 394ccb8:imap.imapserver:NA:ProcessCurrentURL: aborting queued urls | 3052[394e0f8]: ImapThreadMainLoop leaving [this=394ccb8] I did some different steps: o I deactivated "Check ...at startup" o Run TB o Click into a Folder -> SSL error message in server log o Click on message header to show the message in the preview -> TB asks me for the "master password for the FIPS 140 Cryptographic, Key and." Isn’t it a bit late to access the client cert?

FIPS! You have your token in FIPS 140 mode. I'll bet no-one tested with that mode. That mode requires you to be logged in to the token to do *any* crypto, including crypto on other people's server certs. Are you presented with a "master password" dialog before the TB startup check occurs? If not, THAT's the problem. As for the server log reporting "sslv3 alert bad certificate", it has nothing to do with client certs. Here's what that means. The server sent its server cert to the client. The client (which was in FIPS mode, and probably wasn't yet logged in) was unable to do any cryptography on the cert to verify it, and so concluded that the cert was not verified. So, it does what any good SSL client does in that situation. It sent a special SSL record called an "alert" to the server, saying "I think your cert was bad" (this is the bad cert alert). The server received the bad cert alert from the client, and logged it, thinking "that's odd, this client doesn't like my cert!" I might ask Alfred, are you using FIPS mode because of some employer or other "business" requirement (incuding that the Lieutenant said you must)? If not, the simplest solution for you is undoubtedly to disable FIPS mode.

(In reply to comment #96) > Are you presented with a "master password" dialog before the TB > startup check occurs? No. > If not, THAT's the problem. Yes, you may be right. > I might ask Alfred, are you using FIPS mode because of some employer or >other "business" requirement (incuding that the Lieutenant said you must)? No, it's just a local test account. Neither encryption nor authentication is required at all. > If not, the simplest solution for you is undoubtedly to disable FIPS mode. Ok, I've deactivated FIPS. The (server) error message changes to: "SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate" And the PW-dialog asks now: "Please enter the master password for the Software Security Device." But the effect is the same. Another note (deactivated "Check ...at startup"): On folders with activated offline use, TB shows me the offline Version from the selected E-Mail without any error message. I get the PW-question first when I select an E-Mail in a non-offline folder.

You've configured your server to request and require that the client identify itself with a certificate. But your client doesn't have a suitable certificate with which to identify itself. Your choices are: a) change your server to no longer require that the client identify itself with a certificate. (That's an extremely unusual configuration) or b) get a certificate for your client that meets the server's criteria, that is, was issued by one of the issuer's trusted by the server.

(In reply to comment #98) > You've configured your server to request and require that the client identify > itself with a certificate. Yes, since several months (years). > But your client doesn't have a suitable > certificate with which to identify itself. I don't think so. As I told in comment #93: | When TB is running "get messages" works fine. | | When I backout revision e0cc75f26657 the problem is also gone! | http://hg.mozilla.org/comm-central/rev/e0cc75f26657 Wouldn't that mean TB has the cert?

[Rather late], but having just been faced with this issue in setting up some email accounts, it crosses my mind that there is an alternative to providing a mechanism for the user to accept failed certs, and that is to allow an option for each email account to permit alternate certificate matching. Specifically, in the Security settings box (SeaMonkey) have two options become available when a secure connection is selected: "Accept alternate domain cert. [Domain name]" and "Accept self signed certificate". This allows the account to be setup so that there are no warning messages that need to be dealt with, and deals gracefully with a certificate being updated. The user will only see scary popups is something unexpected happens.

Most users aren't going to go near the Security Settings, and are only going to see this problem once when setting up an account. I think the current level is about right - notify the user there is a problem, but allow them to override it. I notice that both email accounts I use, on different servers, have security problems. One because they haven't purchased a certificate - just self-signing, another because its a hosting server with lots of domains and just use one certificate. In neither case is the certificate's validity an issue, and its MUCH more secure to be using the certificate (invalid as it is) than using unsecured pop, which is how it will be used if its made any more difficult to override the security warning.

As one of those who earier complained about the certificate mismatch problem, I would like to thank those who fixed the problem. Access to my pop mail is now problem-free and I'm confident that if I had other pop accounts, they would work without problems too.

I switched from TB2 to the latest Shredder nightly 15th Aug and see this bug. My server uses a common certificate, so there is a domain name mismatch. I get a warning dialog similar to FF, but there is no button in the dialog to bypass it or retrieve-view-accept the certificate. I see this bug status as RESOLVED FIXED, so am a bit confused as to what the expected behavior and resolution is.

Ravi, what network protocol are you using? There should be a confirm exception button in the dialog.

I am using "STARTTLS (If available)", port 143, but this happens with SSL (993) also. I investigated this again and the following is what seems to be happening - When I first open shredder, it tries to login to the server. At this point, it opens up TWO dialog boxes, either simultaneously or sometimes at slightly different timepoints. One of them is the familiar confirm exception box - my guess is this dialog operates as expected (I never actually confirmed the exception for the fear of not being able to reproduce the below behavior again). However the other is a dialog box with title "Secure connection failed" with a yellow warning sign inside and advising that the site cert is not valid. It has two buttons "View Certificate" and "Cancel". If I press cancel it goes into an infinite loop and I am presented with the same dialog repeatedly as it continuously tries to login to server. There is no way to either accept the cert and continue or cancel it for good for the session (the other dialog that popped up was canceled or otherwise not acted upon). On TB2 only one dialog used to popup and I can either accept the cert and continue or cancel it and never have it bother me again for the duration of the session. Also checked with all Addons disabled. Thanks

Do we need to backport this to the 1.8 branch since upgrading NSS to the same version used by Firefox 3.0?

Dan, AFAIK, the whole security exception change was entirely in PSM, not in NSS. So, NSS changes do not cause or necessitate those PSM changes.