User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031210 Firebird/0.7+ (aebrahim) Build Identifier: Mozilla Thunderbird 0.4RC1 (20031201) Many hosted domains include SSL-secured IMAP email that uses a generic certificate belonging to the ISP. For example, I own a domain 'spaceshipnofuture.org' that is provided by 'dreamhost.com.' When I connect to 'mail.spaceshipnofuture.org,' the server presents a certificate with the hostname 'mail.dreamhost.com.' Because of this, Thunderbird will (correctly) display the Domain Name Mismatch dialog on initial connections to this mail server. Every time I start Thunderbird, I must click through this dialog, which is easily lost when many other windows are open. I would like the option to disable this dialog, perhaps with a checkbox on the dialog that reads something like "Display this error next time." I realize that this is potentially dangerous, but I think some users would be willing to take the risk. The risk could also be mitigated by only disabling the dialog for specific domain name combinations; for example, Thunderbird would remember that I disabled the dialog when encountering a cert for 'mail.dreamhost.com' when connecting to 'mail.spaceshipnofuture.org' -- if, upon a subsequent connection, a cert for 'foo.com' was presented by the server, then Thunderbird would display the Domain Name Mismatch dialog again. Reproducible: Always Steps to Reproduce: 1. Add an IMAP account and turn on SSL connections for the account. The account must be for a server that presents a certificate that does not match its hostname. 2. Check mail for this account Actual Results: Domain Name Mismatch dialog is displayed. Expected Results: The Domain Name Mismatch *should* be displayed by default; however, it would be helpful to be able to disable this dialog.

this is especially annoying when you have thunderbird set up to check mail every minute -- it presents the dialog each time.

Another reason: I use ssh tunnels a lot for both IMAP and SMTP. In general, I have to use a hostname that I can put in my /etc/hosts file, and which doesn't conflict with the real hostname for the remote server, so that I can continue to use that for non-tunnel use. e.g. I often use hostnames like: 127.0.0.1 ssh-realhostname the loopback address is used, since of course the tunnel endpoint is here, on my system. When I use these tunnels for IMAP/SSL or SMTP/TLS, I always get prompted with this warning, since of course ssh-realhostname != realhostname, even if we assume that realhostname == certificatehostname. I'm happy to see the warning, but I don't need to see it every single time.

It would be good if you could select a checkbox that said something like "Don't show this again," but it would only store information about those specific hosts in a list which would be editable in the advanced preferences.

I am experiencing a very similiar situation. When I connect to my IMAP server the address is: "username.myserver.com" , however the security certificate is for "*.myserver.com" because each user is connecting to a different subdomain. This raises an error in Thunderbird 0.9.2 and can be rather irritating. I am not sure what the expected behavior is for wildcard characters in a certificate domain name. Should I file this as a seperate bug or is Thunderbird handling it correctly? If Thunderbird is handling it correctly, could you please add an option to "Ignore this warning in the future". Thanks.

This bug annoys me a lot too... What about prompting the user with those standard choices? Sounds wise. * Accept this certificate permanently * Accept this certificate for this session only * Do not accep and do not connect My 2 cents.

I think this is no enhancement, this is damn annoying and you can't do anything about it. It's an usability bug. => Setting Normal + mail3 + proposing 0.9 I am also not sure if it's the right component

please don't put bugs into milestones for me.

I have this problem in addition to the fact that the certificate for my mail host actually won't become valid for a year. This is an error on the part of the mail host, but its a free service run by volunteers. So they will get around to fixing it when they can. In the mean time I don't use SSL, because thunderbird complains every time it goes to get mail from the server. It would be very nice to ensure that any scenario where Thunderbird complains about a certificate can be overridden by the user.

Could we at least get this changed from an enhancement to a bug. The fact that I have to click a box everytime I start thunderbird is an error on thunderbird's part. Being able to save the cert. where ever certificates are saved would be nice. I found where one could import certificats, but I have no idea where the certificate is. It must be temporarily stored locally during a thunderbird session, because thunderbird only displays the annoying window at start up and only for the first account of the same mail server.

My email server uses two aliases ukc.ac.uk and kent.ac.uk the SSK certificate is issued by the ukc domain and my email is delevered from the kent domian. Therefore there is a mismatch and it everytime thunderbird looks for new email I have to confirm the certificate. Is there some way of confirming once per session and letting it confirm in the background?

I have the very same problem (I am hosted by dreamhost, too). It's a real pain in the butt. Cedric's suggestion in comment #5 of having the same options as for self-signed certs (accept permanently, blah blah) sounds just fine to me. I can confirm this thing in TB 1.0 final, for Chrissakes!

(In reply to comment #11) > I have the very same problem (I am hosted by dreamhost, too). It's a real pain > in the butt. I have a client hosted by Dreamhost, and there is an ugly hack you can use that will work for Dreamhost and probably other situations as a workaround until this bug gets fixed. What you do is add an entry to your HOSTS (or /etc/hosts) file that maps the domain name used in the certificate to the IP address of the IMAP server you are connecting to. Then adjust your Thunderbird settings to connect to <certificate-domain> instead of <IMAP-server-domain>. So for example, my client normally connects to mail.example.com, but the certificate from the ISP is for mail.dreamhost.com. So a HOSTS entry is added like: 1.2.3.4 mail.dreamhost.com where 1.2.3.4 is the IP address of mail.example.com. Then Thunderbird is updated to connect to mail.example.com. Granted this is a bit fragile, as it'll break if the ISP changes the IP of the IMAP server, and it makes the machine referenced in the certificate inaccessible.

not a 1.1 stopper.

Scott: I see there's been no work on this bug for 4+ months, and all of a sudden, with TB 1.1 coming up, you decide it's not blocking aviary. OK, so we won't have a usability fix for this in the months to come? This thing has been bothering a sheer amount of people since TB first came out. I assume certificate management is handled by some generic layer that can be found in most Mozilla products. This layer allows the kind of Always/JustThisTime/Never management that was referred to in comment #5. AAMOF, such a behavior is provided for self-signed certificates in TB. Could you please explain WHY oh why it is so difficult to extend this kind of behavior to domain mismatch? Every single time I've opened TB in the past year and over, I've had to press Enter to the mismatch prompt. It's annoying and reflects a very real and commonplace situation: ISP mutualized hosting! Why is this thing still enh/new ?!

I'm nobody here, I'm "just" a user of Thunderbird, but I have to say that it infuriates me to see that comment from Scott MacGregor. This is a bug. It needs to be fixed. I don't want to sound like a jerk, but as a user, I am blissfully ignorant of whatever secret concerns may drive you to decide that certain bugs are stoppers and others are not. My concern is simple: I want the software to work. Seeing that this bug is not going to be fixed severely damages the reputation of mozilla in my mind. It certainly doesn't help that no reason is provided either. This is the kind of thing that makes me think I'm going to drop Thunderbird and tell anyone who asks not to use it --- not because it's not a decent piece of software, but because I continue to receive the impression that Mozilla developers are not sensitive to the desires of actual users of their programs.

this is a core security lib issue - if you search bugzilla, you'll find a lot of reports of similar problems. The security team feels it would be a security hole to add an accept permanently button to this core security lib dialog, for various reasons, including man in the middle attacks, if I understand correctly. I'm sure that's not going to make anybody happy, but it's totally out of mailnews control.

(In reply to comment #16) > The security team feels it would be a security hole > to add an accept permanently button to this core security lib dialog, for > various reasons, including man in the middle attacks ? I'm saying *this* particular certificate for *this* particular server. If someone tries to MITM, that's a change. Why is this a security problem? And really, this bug makes using TB a PITA sometimes. For _this_ I switched email clients?

I'm not a security expert, and believe me, this is a pain for me since one of the servers I use has this problem. see bug 255025 among others. Cc'ing some security experts...

If you add an option that disables name checking, there absolutely will be a CERT alert, major vulnerability report about it. You will have essentially killed SSL's ability to protect you from all active attack. the mozilla browser/email client has a feature where when you first override a cert name mismatch, it remembers the name of the host you were trying to access and associates that info with the cert. Thereafter, (during the lifetime of that process) if you visit that host again, it will remember that you previously chose to allow that cert to be used for that hostname, and will not warn again. When that feature was first implemented, it didn't associate a hostname with the cert, and instead marked the cert as valid for all hosts. There were TWO separate CERT alerts filed about that bug. It was a situation where the user had chosen to override security, and STILL CERT declared the product vulnerable over it (and IMO they were right). So, the moral of this story is that you must be very careful in what you choose to allow for overrides. Don't make overrides any broader than they absolutely must be. It's not difficult for server admins to get certs that list multiple hostnames in a single cert. That is a much preferred solution to this problem.

Oh, bug bounties were paid for all the bugs mentioned above as CERT alerts. Probably not good to implement bugs that lead to paying bug bounties.

Hmm, on bug 255025 comment 1 someone suggested that it's the site's fault. I'm confused now: is it in fact Thunderbird's fault for not handling this (i.e. these sites are using some kind of certificate strategy which is actually sometimes a good idea) or does the problem only occur when the e-mail provider is doing something they should *never* do? That would be an important thing to make clear from the start (which isn't to say, however, that even if it's always the e-mail provider's fault, Thunderbird shouldn't allow an override when the user wants one. But if this is a sometimes valid thing for e-mail providers to do then this problem should definitely be fixed quick). Pardon my lack of security and network knowledge, I just really don't like this problem.

(In reply to comment #19) > the mozilla browser/email client has a feature where when you first override > a cert name mismatch, it remembers the name of the host you were trying to > access and associates that info with the cert. That's all _I'm_ asking for, actually. If you want to warn me _once_ (for the life of the process) that there's a mismatch between the cert and my server name, that's just fine. But to ask me _every_single_time_ I try to check my email is just ridiculous.

The hostname association feature I described is only good for the lifetime of the process. Each time you restart seamonkey, you get warned about any hostname mismatches the first time you enounter the site. Having said that, I should also mention that the SSL protocol is designed to avoid sending and validating certs on every connection. Having once connected and validated the cert, the client and server should establish a "session key" which is then re-used in subsequent connections between that same client and server for up to 24 hours, or the lifetime of the process, whichever is less. When a session key exists, the client and server should be able to negotiate a handshake without any certs being involved. If you are indeed being asked to revalidate certs on EVERY connection attempt then something is wrong in the implementation or configuration of either the client or the server. It sounds like one or both of their SSL session caches isn't working. mozilla's SSL client cache code works fine in the browser.

In reply to comment 21, Any SSL server that sends out a certificate that does not contain the DNSname(s) by which that server is known is misconfigured, IMO. One of SSL's key values, one that sets it apart from many other crypto protocols, is its ability to detect MITM attacks and protect the user from them. This ability depends on the client being able to determine, algorithmically, that the cert it receives from the server is the cert for the server that the client's user intended to contact. Today, the convention (in RFC 2818) is that the client must find the DNSname by which it tried to reach the server in the certificate's list of DNSnames. If the client receives a valid cert that happens to belong to someone other than the server it intended to reach, and the client does not detect this and report it, then it is trivial for a bad guy to interpose between the client and server and masquerade as the server. The hostname mismatch dialog is the ONLY thing that gives the user a chance to decide to avoid being succesfully MITM attacked. A user who routinely ignores all host name mismatch errors is a user who is completely vulnerable to MITM attacks. SSL is largely regarded as being immune to this attack precisely because the vast majority of SSL clients properly check the servers' certs to ensure they contain the desired host name. Any server admin who runs a server with a cert that does not contain all the names by which that server is commonly known and used it forcing a situation on his client users in which they will experience host name mismatches. IMO, that's a bad thing for a server admin to do to his users. Now, we can debate whether or not a client should allow its users to override these errors. There's no standard that says clients must or ever should do that. And we believe that most users always click past any errors that their clients allow them to click past, so the ability to click past the host name mismatch errors is effectively a vulnerability in itself. If the clients did NOT offer a way to click past this, you can be sure that a lot of lazy sysadmins woudl fix their certs, and users would not complain about having to click through so much. In some sense the ability to click through is itself the cause of these complaints. So, yes, if you're using a service from some server (especially if you're paying for it) and you're finding that you always have to deal with cert name mismatch dialogs, then your service provider should fix his server's cert. That's his responsbility, IMO. He should not be contiually putting you in a position to have to deal with alerts that serve a legitimate purpose of detecting MITM attacks. By being forced to repeatedly click past that warning, you become trained to ignore that error, and someday you may be victim to MITM because of that.

Nelson: First, thx for all the comments, they help getting a better understanding of the issue. I realize changing this is outside mailnews scope, but since this is the bug where most of the discussion takes place, I'll add a comment here. IMHO, putting up the same Name Mismatch dialog every single time TB starts (or every 24hrs, as per the session key expiry you mention) only serves to make users more apathic to such dialogs, so they end up disregarding them at large. Indeed, as long as the original Mismatch dialog prominently displays the /intended/ DNSname and the /cert's/ DNSname(s), why is that so dangerous to allow the user to permanently allow such "human match"? Later on, if the cert's DNSnames list changes, still w/o containing the intended DNSname, a new Mismatch dialog would appear. Such an override would only declare the actual cert to be OK for the intended domain, in the state it was at override time. I can't seem to find a reason why this constitutes a security issue (unless, of course, the user carelessly allowed permanent override, i.e. w/o regard to the cert's details, but then it's not the product's fault, it's the user's fault). Aside from this, you mention it's easy for server admins to produce a multiple-DNSname cert. I seem to recollect sysadm friends who did not appear to find a workable road towards this (this was for HTTPS covering of virtualhosts I believe). Would you by chance have a link at hand?

Brendan writes in comment #15: > ...it infuriates me to see that comment from Scott MacGregor. > This is a bug. It needs to be fixed. > > Seeing that this bug is not going to be fixed... Scott's comment was "not a 1.1 stopper." That doesn't mean the bug won't be fixed, only that other work has priority with respect to the 1.1 release. If you think the bug should have a higher priority, protest (I'm not sure if that accomplishes anything), vote for this bug, write a patch, or hire a developer to write a patch. Nelson Bolyard writes in comment #19: > the mozilla browser/email client has a feature where when you first > override a cert name mismatch, it remembers the name of the host you > were trying to access and associates that info with the cert. > Thereafter, (during the lifetime of that process) if you visit that > host again, it will remember that you previously chose to allow that > cert to be used for that hostname, and will not warn again. And that seems to be precisely the functionality desired to address this bug. (Though the duration shouldn't be only for the life of the process. It should be permanent. Having non-technical users see a warning they don't understand after every restart doesn't improve security.) > When that feature was first implemented, it didn't associate a > hostname with the cert, and instead marked the cert as valid for all > hosts. There were TWO separate CERT alerts filed about that bug. Interesting, and something for the developers to keep in mind so the same mistake isn't repeated, but what's your point? > It was a situation where the user had chosen to override security, > and STILL CERT declared the product vulnerable over it (and IMO they > were right). Of course they were right. It was a buggy implementation. So? > It's not difficult for server admins to get certs that list multiple > hostnames in a single cert. That is a much preferred solution to > this problem. Review the earlier comments on this bug. The condition was originally encountered by users of ISPs who map customer specific domains, such as mail.example.com for the example.com customer, to a shared mail server. It would be impractical to create a certificate that lists thousands of domains and keep it up to date as customers were added/removed from the mail server. Why not just have customers directly access mail.isp.net? Presumably the ISP uses the customer-specific subdomain to provide a level of indirection. They can reallocate how customers are assigned to mail servers transparently by updating DNS records. The other scenario mentioned in Comment #2 was port forwarding. Adam writes in comment #21: > ...is it in fact Thunderbird's fault for not handling this (i.e. > these sites are using some kind of certificate strategy which is > actually sometimes a good idea) or does the problem only occur when > the e-mail provider is doing something they should *never* do? I think it is somewhere in the middle. Thunderbird is correctly following the standards, but ISPs face some practical limitations in adhering to the standards. It's not unusual for a client (web, mail, whatever) to accommodate real-world usage. David Bienvenu in comment #18: > see bug 255025 among others. Seems like bug 255025 is a dupe of this bug. (And maybe this bug should be likewise moved to Core, if that's where the problem is.) Nelson Bolyard writes in comment #24: > ...we believe that most users always click past any errors that > their clients allow them to click past, so the ability to click past > the host name mismatch errors is effectively a vulnerability in > itself. Valid point. It's also why I'd rather train clients (customers) to pause and ask when such dialogs appear, rather than get them in the habit of blindly dismissing such dialogs. (While I was writing this Christophe Porteneuve posted a comment that makes the same point.) > If the clients did NOT offer a way to click past this, you can be > sure that a lot of lazy sysadmins woudl fix their certs... Also probably true, providing those who operate the mail server can't simply respond by saying, "we don't support Thunderbird." > [your service provider] should not be contiually putting you in a > position to have to deal with alerts that serve a legitimate purpose > of detecting MITM attacks. I think permanently dismissing such warnings holds minimal security risk, if implemented correctly, which is to warn the user again if any of the elements (the IP, cert host, and real host) change.

To spell out what others have intimated, fixing this bug would actually increase security by drastically increasing the ratio of significant warning dialogs. Consider a MITM attack in which evil.com intercepts communications between mail server X and its users. User Joe uses Thunderbird with its current functionality, while user Jane uses a mail client that lets her permanently trust a particular certificate/domain combination. When evil.com presents its certificate to Joe, and Thunderbird warns Joe of the discrepancy in evil.com's certificate, Joe clicks the OK button in the warning dialog immediately, without ever looking at the text of the warning, just as he always does (after the first few times) when he starts the application and it warns him about the domain discrepancy in mail server X's certificate. When evil.com presents its certificate to Jane, on the other hand, and her mail client warns her of the discrepancy in its certificate, Jane pays attention, because she hasn't seen that dialog for months (ever since she first told her mail client to permanently trust mail server X's certificate for her domain). So evil.com steals Joe's authentication tokens and accesses his email, but it doesn't steal Jane's, who contacts her mail administrators after receiving the unexpected warning dialog and learns she is under attack. This example isn't merely theoretical. My mail provider (pair.com) hosts thousands of domains, and its certificate is one of those whose domain (*.pair.com) doesn't match my mail server's domain name (mail.melez.com). I start Thunderbird several times a day to access my mail on that server, and every time I do so, I dismiss the domain mismatch warning dialog the moment it appears. Like Joe in the example, this behavior leaves me susceptible to MITM attacks. It's also a rational, calculated risk, since the warning dialog is virtually always seeding doubt about what is actually the correct server. For this warning dialog to meaningfully warn users of a potential attack, it should appear rarely and only when an attack appears likely. In the mail world, where mail servers increasingly serve multiple domains and users generally access the same small subset of servers, that will be best accomplished on the client side by allowing users to permanently accept a certificate/domain combination.

Well said, Myk. It's clear that if Thunderbird is going to be completely secure, it's going to have to not present an option to accept the certificate at all, but simply an error message with a note to tell your site administrator to fix their server. This would of course cause many people to be unable to use Thunderbird. If any of these connections are to be allowed, making the dialog go away permanently (for certain domains only) is better than having it recur. How about the following idea if we want to get really secure? Have a configuration option which says something like "allow certain invalid certificates", which is off by default. When an invalid certificate arrives, display an error, similar to the one currently displayed, but which tells users that they must enable that option if they want to insecurely work around their e-mail provider. Then they go select the option, try to get their e-mail again, and then they're asked if they want to allow certificates that have that particular form. This way, only users with bad e-mail providers are at significant risk (lower risk than now, anyway).

Oh, and by the way, under that configuration option I mentioned you could have a list of certificates that are allowed through, which the user can manage.

This whole discussion is ridiculous. This bug is a textbook example of many different invalid uses of PKI. It bug should be resolved INVALID. If you want to use PKI, which includes SSL/TLS, you need to follow its standards. Using PKI with invalid certificates offers the same level of security as not using PKI at all. There are known solutions to the problem : 1) the cert issuers/users could fix their certs to become valid . Then, the mozilla pop-ups will disappear. 2) the users could switch to the non-SSL port. There will be no pop-up about mismatched cert in this case either. But the solution should NOT be : 3) the security in mozilla clients should be compromised . This is what this "enhancement" request is about . With enhancements like these, who needs bugs ?

Julien, with all due respect you are wrong. Securing a connection using SSL/TLS can serve two purposes: * Verifying the identity of the other party * Encrypting the connection You are suggesting that because users do not want to verify the identity of the other party, they have no right to encrypt their connection and should use non-secure connections only. As others have pointed out, letting the user choose how much of the identity verification should be done does increase end-to-end security (and in no case is the security of the client(!) compromised).

Klaus, SSL/TLS rely on X.509 certificates. When you get an X.509 certificate, you must verify that it matches your party. Show me a standard document that says you have a choice not to do that.

(In reply to comment #32) > SSL/TLS rely on X.509 certificates. When you get an X.509 certificate, you must > verify that it matches your party. Show me a standard document that says you > have a choice not to do that. Sure, but (again, with all due respect) that seems to be beside the point that Klaus just made. You said earlier that "Using PKI with invalid certificates offers the same level of security as not using PKI at all," and Klaus pointed out that an encrypted connection is nevertheless plainly better than an unencrypted connection. Bear in mind also that ideal certificate management is probably impossible and certainly prohibitively expensive in a virtual hosting situation, which is what we're talking about here. Go back and read the original problem description. If I attempt to connect to "myhost.com," and the server presents a certificate for "actualhost.com," but I know that "myhost.com" is simply a virtual host on "actualhost.com," why can't I tell my email client to go ahead and treat this particular combination as valid? Especially if I make this choice with full knowledge of the risks involved?

Jacob, I disagree that an encrypted but unauthenticated connection is plainly better than an unencrypted, unauthenticated connection. If somebody has the ability to snoop through your traffic (the threat you are protecting against by encrypting), they have access to router data somewhere, and almost certainly also have the ability to run an MITM attack on you just by reconfiguring router settings. Thus, the cost of the MITM attack is only marginally higher than snooping plaintext traffic, and it is questionable why you would want to protect against one attack but not the other attack of very similar cost. The problem of SSL virtual hosting needs to be solved properly, through standard ways that don't involve compromising security, such as including multiple names in a cert, wildcard certs, or simply using a different cert for each domain, either through a dedicated IP per domain, or a dedicated port if extra IPs are not available. The later shouldn't be any more expensive for the ISP - and the limit is reasonable, 65536 ports, ie. 65536 domains, per IP address, which should be plenty. Most clients, and certainly mozilla mail, allow you to configure the port for mail servers. In the future, a single IP:port will also be usable for multiple certs for virtual hosting. See bug 116168 and 116169 . The ISPs have no excuse but their own laziness not to respect the standards. This argument cannot be used to justify compromising security in mozilla. If you want to do that for yourself, fine : since you understand the risks, you can pull the mozilla source, remove hostname check yourself, and recompile it. Most people don't understand the risks, and this shouldn't go into the main tree under any circumstance, not even as an option.

Julien > If somebody has the ability to snoop through your traffic (the threat you are protecting against by encrypting), they have access to router data somewhere, and almost certainly also have the ability to run an MITM attack on you just by reconfiguring router settings. in a non-switched environment anyone on the same local network can sniff network traffic but usually cannot reconfigure routing. Encryption does improve security. Going by your argument, the user should not be given the option to override the hostname mismatch even by session. We are all in agreement that a working PKI and matching certificates are ideal and desirable, but we do not live in an ideal world and we need to choose between several alternatives, none of which are ideal. Yes the people discussing this here know how to work around the problem (the easier solution than changing the source is to define the matching hostname locally in etc/hosts), this is not about finding solutions for a bunch of developers who understand the issue and can fix it for themselves but solving the problem for Mozilla users at large who don't know and either decide to use another mail client because of this "feature" or blindly accept the security warning, and any other security warning they will get, every time because they are so numerous. PS. The SSL 3 specification explicitly allows for secured connections without authentication, maybe the right option for users who only want to encrypt traffic is to provide an option to not authenticate the server (although personally I think that authenticating the server with a known and user-confirmed hostname mismatch is the better choice).

Klaus, The mozilla user-at-large who doesn't understand about security should never override this error, so if this is who it's for, then that's all the more reason not to add an error. The security warnings are meant to be taken seriously, not ignored. The mozilla users need to understand the servers they are connecting to are at fault, not the browser. Switching to a less secure client doesn't solve their security issue. The pop-ups are doing the users a service. Removing them is a disservice to the user in the context of security. I'd say that for the mozilla users at large who don't understand security, most of the security pop-up dialogs shouldn't have an override at all, neither one-time "OK" button nor permanent. The goal of security is not to make the mozilla browser the most popular browser on earth. It is not to accomodate servers that don't follow standards. It is to make the application secure. When it comes to implementing security standards, there isn't the same margin for interpretation as there is with, say, the HTML standard. The risks of being lenient are much higher with security. security standards exist for a reason, and they need to be respected, by both the client and server sides. Mozilla should stick to enforcing these standards. If users want to stop using mozilla because it's secure, it's their own loss. If server administrators break security rules which result in mozilla not working with them, they should bear the consequences of reducing their user base. They are the ones each and every one of you need to complain to, to get to fix their servers. You should not file "bugs" on mozilla requesting that the security standards be broken. It will not happen.

Julien, any comments on my observation that the SSL 3 specification does allow encryption without server authentication?

Klaus, Please be specific . I assume you are referring to section F.1.1 of RFC2246, Authentication and key exchange : " TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked." Total anonymity is possible with TLS, but the decision is dependent on the protocol that runs a top. Sections 1 and D.3. support these statements : " - The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers." Notice how it says "generally required for at least one of the peers". In the cases we have discussed thus far, the client doesn't have a certificate, so the peer is the server, and thus authentication is "generally required", not optional . The "total anonymity" case is seldom specified. Also, later, section 1 says : "One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS." None of the protocols that mozilla is concerned with, HTTPS, IMAPS, SMTPS, and POPS, specify that total anonymity is allowed . Further : "D.3. Certificates and authentication Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA."

Julien I was referring to the SSL 3 specification, not the TLS specification, although they are similar: http://wp.netscape.com/eng/ssl3/draft302.txt (my highlights IN UPPERCASE) 5.5 Handshake protocol overview The cryptographic parameters of the session state are produced by the SSL Handshake Protocol, which operates on top of the SSL Record Layer. When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, OPTIONALLY AUTHENTICATE EACH OTHER, and use public-key encryption techniques to generate shared secrets. ... Following the hello messages, THE SERVER WILL SEND ITS CERTIFICATE, IF IT IS TO BE AUTHENTICATED. Also in the section you quoted Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA." there is no reference that the hostname must match the name specified in the certificate, this is about trusted CAs (fortunately we have no disagreement about CA trust hierarchies :-))

Klaus, I referred to the TLS spec because it is more current. Re : SSL3 section 5.5 In all the cases that have been discussed here, the server does send a certificate. According to what you quoted, since the server sent a certificate, then it must be authenticated [by the client]. Re : hostname check The process of verifying a certificate requires that you have some identity attribute and a certificate that is supposed to match the identity . The definition of a certificate is that it is the binding between that attribute (and other attributes) and the public key in the cert. In the SMTPS/HTTPS/POPS/IMAPS protocols, the identity attribute is the hostname. This is specified as part of the application protocols layered above SSL3/TLS, not in SSL3/TLS itself . Eg. , see RFC 2818, HTTP over TLS : 3. Endpoint Identification 3.1. Server Identity In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.

> the client MUST check it against the server's identity as presented in the server's Certificate message Again no disagreement there, it MUST check that the names match and handle the case when they do not. The specification does not say what the appropriate behaviour is in that case, and the whole discussion here is about what is appropriate, ranging from * Never ever allow the user to connect * Allow the user to connect but only after seeing a warning and accepting the specific mismatch every time the client is started (current behaviour) * Allow the user to connect but only after seeing a warning and accepting the specific mismatch

But are we in agreement that it's more secure to allow the user to make the dialog go away for specific hosts than for them to click it each time? From both of your arguments, it seems to follow that both those options are too insecure, and users should never be allowed to connect to a site with an invalid certificate. Is that true? Anyway, that's another problem completely from the recurring dialog, and maybe even a problem for another bug report. I'd personally say blocking all invalid certificates is too strict, especially since a program may assume that it is itself correct, but that everything else might be incorrect (including its users and whether other programs/servers follow standards. Though it's true that disallowing connections to things that don't follow standards may still be the proper way to handle it).

Klaus, actually, RFC2818 does specify the behavior if the check fails. From RFC2818, section 1 again : If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.

> Klaus, actually, RFC2818 does specify the behavior if the check fails. And all three options * Never ever allow the user to connect * Allow the user to connect but only after seeing a warning and accepting the specific mismatch every time the client is started (current behaviour) * Allow the user to connect but only after seeing a warning and accepting the specific mismatch for a defined period of time, including permantently meet the requirement "If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error." The specification does not say "notify every time a connection is established" or "notify every time the client software is restarted".

Would addressing this bug be any more palatable to the security purists if the problem was redefined as follows: On the "Server Settings" page of "Account Settings" add an optional "Server Certificate Name" field (probably on the Advanced dialog) where a user can explicitly specify the name that Thunderbird should match the returned certificate against. Not as ideal as simply checking off "remember this" on the certificate mismatch dialog, but it equivalently solves the problem, and requires that the underlying Mozilla security subsystem perform an exact match between the certificate and a user specified field. No guessing and no confusing dialogs presented to the user. This also can be something a consultant or IT person sets up for a non-technical user and can be specified in setup instructions supplied by an ISPs.

(In reply to comment #36) > The mozilla user-at-large who doesn't understand about security should never > override this error, so if this is who it's for, then that's all the more reason > not to add an error. The security warnings are meant to be taken seriously, not > ignored. The mozilla users need to understand the servers they are connecting to > are at fault, not the browser. Switching to a less secure client doesn't solve > their security issue. The pop-ups are doing the users a service. Removing them > is a disservice to the user in the context of security. This is pure fantasy. Users want to read their email. Draconically enforcing authentication protocols to guard against hypothetical security risks will accomplish nothing except alienating the vast majority of users. Moreover, even if you maintain that naive users should not even do the per-session override, that doesn't explain why non-naive users should be prevented from doing a permanent override. From my understanding of the spec quotes people have posted on this thread, including this option would not violate the spec. The override should specify exactly which host, IP, etc. are being "trusted", and if any of these parameters change, a new warning box can justifiably appear.

Julien writes: > Jacob, I disagree that an encrypted but unauthenticated connection is plainly > better than an unencrypted, unauthenticated connection. > > If somebody has the ability to snoop through your traffic (the threat you are > protecting against by encrypting), they have access to router data somewhere, > and almost certainly also have the ability to run an MITM attack on you just > by reconfiguring router settings. This is demonstrably not correct in unswitched Ethernet as well as open wireless networks as commonly configured in cafes and conferences. While it is certainly possible that someone could mount a MITM attack in an open wireless environment, this is significantly more work than just listening to packets for passwords using (eg) Ethereal, and, as a result, almost certainly much less common. Do you disagree? [...] > The mozilla user-at-large who doesn't understand about security should never > override this error, so if this is who it's for, then that's all the more > reason not to add an error. The security warnings are meant to be taken > seriously, not ignored. [...] The pop-ups are doing the users a service. > Removing them is a disservice to the user in the context of security. Please re-consider the above paragraph in light of Myk's comment #25. It seems to me that he makes a compelling argument that the pop-ups actually increase risk here, because they encourage the user to ignore them. Worth keeping in mind is that we're trying to deal with how users actually _will_ act in the real world, not how they _should_ act. Do you see some flaw in the reasoning in comment #25? I think Brendan and other posters also make a good point that there are really multiple options here: status quo, or make it possible for everyone to override this dialog permanently, or make it difficult but not impossible for clued users/ISPs to override (eg via a pref).

*** Bug 255025 has been marked as a duplicate of this bug. ***

As I wrote in comments above, disabling all cert name mismatch checking discards the major security benefit of SSL for the sake of a few rare sites that have bad certs. Such a change is guaranteed to create a CERT alert and would severly damage the reputation of mozilla. If any change is to be proposed, it should remember a user's override for the named sites that the user overrode, not disable the check for all sites. I have not yet read any comment that disagrees that that would suffice. I am changing the summary of this bug to reflect that.

I am not sure that there is exact equivalence between these two bug reports. But they are close. What I would like to see is the option to permenantly accept THAT PARTICULAR CERTIFICATE (not certificates from that site) when the warning is given.

In reply to comment 50, right. When you choose to override a cert name mismatch, You're not saying you want mozilla to accept any and all certs for that site. Neither are ou saying that you want that particular cert to work for ALL sites everywhere. You're saying you want that particular cert to continue to work with that particular site.

Some ISPs are setup with one certificate for all virtual domains. For whatever reason, mostly administrative overhead I expect, they do not include every hosted domain in the valid domains in the certificate. I see lots of valid comments from developers regarding non-adherence by these ISPs to various security standards but very little discussion regarding viable solutions to users suffering the consequences in TB. Given the ISP is unlikely to change their configuration, what can be done by the Mozilla developers to lessen the inconvenience for TB users? Given this has gone nowhere in over 18 months, if the answer is nothing, at least update the Component to Security and Status to INVALID or WONTFIX for this bug report and close it with the official position.

*** Bug 292815 has been marked as a duplicate of this bug. ***

Please let me disable this annoying error, nobody is trying to steal my email and Im so sick of Thunderbird nagging me about some certificate that I have no control over.

I just started using SSL for my IMAP account to test out another bug recently and I see this problem too. It is awfully annoying. I'd like to see us be able to remember the CERTOKDomainName list for a particular certificate across sessions. As Nelson points out, that list is persisted across the current session. One big problem with saving the cert domain list associated with the cert is that we don't save SSL certificates (nor should we I believe), so there's no cert in the cert database which we could store the CERTOKDomainName list for.

Scott, in the lifetime of a single TB process, are you seeing this warning more than once per server?

(In reply to comment #56) > Scott, in the lifetime of a single TB process, > are you seeing this warning more than once per server? Hey Nelson, no, that's working just fine, multiple connections to the same server produce just the single dialog. The 'annoyance' is that every time the user starts up Thunderbird, he has to dismiss the cert mismatch dialog when we first log onto the server every time. That's why I was talking about how I would like the ability to see the cert domain ok list stored in the cert db for a particular cert. Of course since we don't store SSL certs, there isn't even a cert to store it with. :( I was thinking a bit more on this and I suspect it's not realistic for us to expect/hope for a lot of these web hosting companies to list all of their domains in the certificate their mail server uses for SSL. Would someone really list a couple hundred thousand domain names (or more?) in a certificate. Wouldn't that end up generating a certificate that would have a huge size? I don't know if I'd even want to see the client NSS code strtok'ing all of the possible domains from my hosting company just to find my particular domain anyway. :) Hmmm.

How about if you created a new table somewhere that listed "equivalent domains"? i.e. what's really going on here is that you're saying that the hosted domain is equivalent to the host's domain for auth/cert purposes. e.g. in my case, my domain is interthingy.net hosted at dreamhost.com. For authentication purposes, interthingy.net is equivalent to dreamhost.com and it can permanently be treated as such if the user (me) says so. I guess the tricky part is doing this in a secure way (i.e. wouldn't want someone hacking the equivalent domains table to trick an eveel domain into being authenticated -- actually, I'm not really sure that's possible, but I think it is -- I'm too tired to think of an example right now...). I was able to add dreamhost's cert to the authorities table in cert mgr (not sure if that was the right thing to do though) -- is there any way to amend the cert in the authorities table to include the additional domain name? One more thought: IIRC, firefox has implemented this feature. Maybe you could look at what they did? ~ray

Scott, Creating a single cert with all the options is certainly *not* the only option available to hosting companies. The simplest option for hosting companies is to create individual certs for each domain, and just use a separate IP / port combination for each server. Or if they can't afford that many IP addresses, they can just use say, 1 IP and cert for every 10 virtual hosts. These companies have plenty of options to fix there issues. The standard documents are out there. If you are worried about them, point it out to them. Maybe you can add a link to the standard docs in the error dialog, so these companies can't hide and pretend they don't know they are breaking the standard. In any case, we certainly can't expect the ISPs to fix anything if we are going to ignore this error. This is one that should *not* be ignored, unless you want to remove security altogether as a feature in mozilla . Also, my understanding (which may not be correct, please contradict if you have other info) is that the main protocol that requires multiple IPs for certs currently is HTTP - and even that is getting fixed with the TLS server name indication extension (which also fixes it for all other protocols that may be broken). Many mail protocols use STARTTLS, which means there is an in-the-clear negotiation which precedes the server's sending of the cert . This negotiation may allow the server to know which virtual host the client intends to talk to, and thus would allow the server to pick the right cert, with a single virtual hostname in it. Any way you look at it, this is fundamentally a problem of incorrectly setup servers, not clients. This is a problem that *cannot* be fixed solely by changes on the client side. If anything, it needs to be an evangelism bug, not a browser bug !!! Ray, A cert cannot be "amended" because it is signed by a CA cert. The only way to change the properties in a cert, such as a hostname, is for a new cert to be issued to replace it. This is what the hosting companies need to do - obtain a new cert every time they add a new virtual host, which they aren't currently doing. Regardless of the evolution of internet protocols and TLS extensions, and whether the hosting companies choose to use one cert per host or to use a single cert with multiple hosts in it, these companies will *always* have to obtain a new cert for each virtual host. I believe they aren't doing that currently because they are either incompetent or greedy, in that order. If Firefox actually implemented the removal of the hostname check, then I'm very glad I'm still using Seamonkey.

(In reply to comment #57) > it's not realistic for us to > expect/hope for a lot of these web hosting companies to list all of their > domains in the certificate their mail server uses for SSL. Would someone > really list a couple hundred thousand domain names (or more?) in a > certificate. No. My ISP does it this way. They have one DNS name for their IMAP, POP, and outgoing SMTP server(s). They may serve email addresses in thousands of domains, but their server has just one name (as seen by their customers). Their customers/users login to the server with their full email address as the user name. Their SSL cert has just one DNS name, and it works for ALL their users in all those users' many domains, because the server is not trying to pretend that it has a DNS name in all those domains. The users just have to accept the fact that, although their email domain may be flintstone.com, they have to connect to a server named superduperemail.com and login with their full email address for IMAP or outgoing SMTP service.

Would you people please listen to what we are saying? Its gotten a bit ridiculous that someone keeps saying, "This is not a problem with the client, the problem is with the servers." Yes, the certificate problem is with the servers -- but this is not a discussion about how to resolve the certificate problem... this is a discussion about how to get rid of the warning about the certificate problem. We don't want the warning. Its making an existing problem WORSE.

In a lot of ways I completely understand Arin's frustration. This traq has been going for quite some time now. I mean we're coming up on two years of finger pointing! Amazing...truely amazing! Now for Arin, since you are getting so frustrated with this, might I suggest using the "hosts" hack to clear your dialog box for the time being. Agreed, I don't necessarily like doing it either, but it does remove the frustration from the equation. Julien, I completely understand and appreciate your need and desire to maintain focused on security, however this "It's the ISP's problem", "This is not a bug, the ISP's are doing it wrong" defense has got to stop! We've all read it numurous times and the rhetoric is making our brains bleed. Yes, technically, this may be considered an issue with how ISP's maintain certificates, but why stop there? Why not point the finger at the Cert Authoriies? You mentioned "greedy ISP's", but the last I checked, the profit margins for hosting providers are not what they were ten years ago. It's a cut throat business, and they're a dime a dozen with heavy competition, low margins and high overhead. All the while certain Cert. Authorities are charging upwards of five to seven hundred dollars for a 128bit "file!" Now if you want to go on a campaign and span the globe forcing all ISP's to register one cert. per FQDN then be my guest...however I would hazard to guess that you probably don't have time for that in your schedule. Now lets flip that coin and put yourself in the ISP's position. ISP xyz.com hosts, conservatively, 50,000 domains. Now at the current pricing structure utilizing a "generic" Cert. Provider you're required to pay on the order of $100 for a 128bit cert per FQDN. Now do a little math and I've got a yearly bill of about 5 million. Now considering your 50K customers @ $9.95/mo generate about 6 million. But wait, don't forget to pay your employess, say $250K, or your Rent/Lease $100K, and all those computers $300K, and some bandwith to serve up all those certificates I just paid for, $150K. Now let's give Uncle Sam his cut...I think the egg just ate the chicken! My point being, sure it's easy to point the fingers at the ISP's/Hosting providers but is it not the system that is broken? Why don't the Cert authorities develop a product more tailored for these business? Another discussion I know, but if you want a cause to rally for change, there's your focus. Sure ISP's could mitigate these problems solely on how their servers are configured. As was previously mentioned, If I have domain abc.org but check mail through my provider at mail.xyz.com and login w/ bobdobbs@abc.org then the ISP is within the bounds of the Cert and all is well. However many ISP's allow customers to utilize their own mail domain, in my case mail.abc.org which does indeed break the model, but is needed for advanced services and other products that they need to differentiate their services. I don't think anyone here is asking anyone to give up and throw the security out the window. All we are asking is that instead of mandating your security views on the populous, allow us to mandate security as we see fit. Allow us that choice. By keeping things how they are now with popping up a mismatch everytime I check mail, you are desensitizing me to it's validity. I become preprogrammed to hit "check mail," "click OK"..."check mail," "click OK" without so much as a glance. On the other hand, i can alter my "hosts" file, but then I loose any management I may want over the mismatch. If people don't like the thought of "Accept Once," "Accept for the Session," "Accept Always" options for Cert. Management mismtaches, then add the functionality and leave it off by default, but don't deny us the choice to have it. We all take calculated risks every day. Just allow those of us that are so inclined to add this one to our list.

For those new to this conversation, note comment 27 and comment 47, which explain why the requested behavior would actually increase security. Also note comment 44, which points out that the requested behavior conforms to RFC 2818.

Julien: I understand what you're saying regarding the ISP's role in this but please consider, as many others have said, that it's not that simple. We can't control what our ISPs do and there are valid economic reasons why they can't do what you say and why many of us can't provide our own solution. If you thumb your nose at the problem you're only hurting your own users; you're not going to change the ISP's behavior no matter how right you may be. As for "amending" certs: I understand that certs can't be modified; I was thinking more along the lines of using something like an attachment to the original cert. I don't know what your DB looks like though, nor if it can support this, or support it securely, or be changed easily to support it. If I had more time I'd look into it myself and submit a patch. Regarding Firefox: I tested it today and confirmed that it wasn't FF that did this. I suspect now that it may have been Evolution but I can't test it right now (my employer blocks outgoing POP and IMAP :( Whichever program it was though, it didn't remove the hostname check, it only provided an option to permanently remember a SPECIFIC combination of mismatching hostnames so it can suppress the warning in the future. I think that's all anyone is asking for here. ~ray

Just a small remark about authentication: If I manually check the self signed certificate of my ISP (by matching the fingerprints) and on success import the certificate into my mail client/browser, I get an authenticated and encrypted connection with no possibility (except broken TLS) for a MITM attack. That's exactly the situation I'm in. So at least in the certificate manager I should be able to override the hostname check for *specific* domains.

I also suffer from this bug and in my case it is even worse! I access my mail through an ssh tunnel using the pop3s protocol. *Every* time I press "Get Mail" I have to OK the "Domain Name mismatch" dialogue. Surely if I'm allowed as a user to still access my mail after saying it is OK to accept the domain name mismatch I should also be able to say it's always OK for this particular mismatch? I'm forced into this situation because: 1) My employers only use SSL connections i.e. pop3s, and pop3 is not supported 2) They block external access to the pop3s server on all ports other than ssh. Therefore I need to open an ssh connection to the server, and route the pop3s 995 port through to my localhost with an ssh tunnel. So I get a domain name mismatch between the server and localhost. 3) I cannot use the /etc/hosts work-around as that will mess with my ssh tunnel connection and god knows what else! Do I have any hope or will I be forced to stop using mozilla based mail clients? I think this is a case of security gone mad. I seem to be trapped between two differing security mentalities!

(In reply to comment #24) > In reply to comment 21, > Any SSL server that sends out a certificate that does not contain the > DNSname(s) by which that server is known is misconfigured, IMO. > > One of SSL's key values, one that sets it apart from many other crypto > protocols, is its ability to detect MITM attacks and protect the user from > them. This ability depends on the client being able to determine, > algorithmically, that the cert it receives from the server is the cert > for the server that the client's user intended to contact. Today, the > convention (in RFC 2818) is that the client must find the DNSname by which > it tried to reach the server in the certificate's list of DNSnames. > I work at dreamhost.com, though I am not really their representative in this issue, just expressing personal concerns, observations, and frustrations. We use self-signed certificates on our shared mail clusters, all of the servers inside of a cluster, possibly globally, have the same modulus, and the same CN= field of mail.dreamhost.com. Basically, it is just something to get the connection scrambled from the casual eavesdropper. I, personally, would love the option to "ignore warnings regarding this certificate unless something changes.", much like an SSH client works. If I were "evil.com" forging a certificate I would make darn sure that the CN= field in a fake self-signed certificate matched what was on the server. I'm not up on all of the specifics of how these PKI certs work, but obviously knowing the public key and its modulus does not put you at risk of forgery. Couldn't Mozilla check based upon the modulus changing to put up its warning? In our current situation the certificate file would be huge and ever changing if we were to put DNSAltName fields in it and reload it for every domain we host. Most people in our hosting environment want to connect to "mail.example.com", not mail-cluster-a.hostingcompany.com. The override could even be specific to self-signed certificates which are already untrusted unless imported. On another note, if I have two seperate email accounts, Mozilla will not allow me to connect if I have two domain names, such as mail.example.com and mail.example.net, that are served the same self-signed certificate. I don't know if thats an RFC issue or what, but it seems like overkill to block the connection versus allowing the user to override it.

Could we raise severity and priority of this bug? It doesn't seem to be an "Enhancement" any more.

One could argue that this is a security issue and susceptible to a pavlovian vulnerability: http://robert.accettura.com/archives/2005/10/15/pavlovian-vulnerability/ At least I'm a well trained dog, clicking on those unnecessary warnings without thinking anymore.

This bug has been open for 683 days, go open source! The requested behavior is simple - if the certificate name does not match the name of the server one is connecting to, allow the user to choose to "accept this certificate permanently". This behavior *already exists* in Firefox. Can anyone give me a good reason why firefox's behavior is acceptable, yet the same behavior would be unacceptable in Thunderbird? Several commentors stated that changing Thunderbird's behavior would severely decrease the security of the application. If that is true, then it would appear that Firefox has a serious security flaw, and I recommend someone notify CERT. No? Then the code in Firefox is good enough for Thunderbird.

(In reply to comment #70) > This bug has been open for 683 days, go open source! > > The requested behavior is simple - if the certificate name does not match the > name of the server one is connecting to, allow the user to choose to "accept > this certificate permanently". > > This behavior *already exists* in Firefox. The bug is in the certificate name mismatch dialog, not the "untrusted certificate authority" dialog. Firefox does not have a way to permanently make a name mismatch dialog go away. Try visiting https://amazon.com/ , accept the certificate with the name error, then restart FireFox. It will re-present you with the certificate mismatch error.

It's so sad that developers can not understand the simple pov of oridinary user. I'm developer myslef (focused on web) and user experience is the very important thing for me. In case Thunderbird - it is so lame that when i set the option to periodically check my mail for every 10 minutes and i have host with lame certificate - the message with warning will appear every time without even the possibility to _remember my choice to accept my choice for this particular Thunderbird session_. It is very annoying and should be changed by Thunderbird developers. Of course it can be cause for endless discussion but imvho this bug makes my life much harder. Plase change this.

(In reply to comment #45) A long way back on this discussion, I think comment #45 is THE solution. I didn't find any comment on this, but maybe I missed it in the middle of all the other stuff. Maybe this could be done as an extension, that way people could choose which way they want it - more security or less annoyance. Let me just mention (I'm not sure anyone's done it before) that I get this issue not when starting TB and checking for mail, but rather when SENDING mail. This is because my ISP only allows Authenticated SMTP (SMTPA) and I have a proxy computer between me and the ISP (which causes the name mismatch). So, I would defend the option of following the solution (brilliantly) proposed by Tom Metro on comment #45, but making sure it's available for the SMTP server as well. The solution could be implemented as regular UI, as an Extension, or even as a tweak (about:config or something).

I have not yet read this bug in total, it is very long. But this bug is not specific to Thunderbird, it applies to Firefox and Seamonkey, too. A cross-application solution should be found. I propose the product of this bug be changed to Core / Security PSM. Please also note bug 94904 and bug 99411. I contains related suggestions (which I have not yet reviewed either).

Could we avoid storing certificates for fixing this problem? Could we just store a hostname-in-cert to hostname-connecting-to string pair? We could say, whenever we see a valid certificate issued to hostname-in-cert and we are trying to the associated hostname-connecting-to, we could skip the warning. However, there is obviously a certain danger with implementing this feature. The user could make the "remember" decision too quickly, without having looked at the displayed test in detail. Therefore I propose, this "remember mismatch permanently" feature should be implemented together with bug 276533, see bug 276533 comment 5. Instead of displaying a secure lock icon (when talking about browser windows) we should extend the lock icon by a visual feedback visualizing "the site is authenticated, but partly because of your own decision to trust".

Without re-opening the whole debate about what's right and what's wrong from a security point of view... A volunteer could easily write an extension that would supress this error dialog. For those of us foolish enough to want to ignore this dialog, we could go out and install the extension. No modifications to the mozilla source would be required and you wouldn't have to wait for a more complicated discussion / implementation that happend in the mozilla source. An extension author can write a small extension which implements nsIBadCertListener like we did for software update: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1588 But this implementation would wrap the default implementation, forwarding all calls to the real listener except for confirmMismatchDomain which should return false.

"Foolish to want to ignore this dialog" seems to be a bit exagerrated, in context of comment #1, which started it all. Anyway: 1) Would such an extension be capable of killing the dialog on per domain basis? And only if some other conditions are met? For example when certificate is issued by someone else, however that "someone else" is strictly defined to be "someone" yet not "anyone" else? Generally we don't want this dialog to be destroyed everytime. 2) Extension has a small downside: it might be installed without user knowing it - or am I completely wrong with this?

Hi people, I am a nobody here. I am just a regular Firefox/TB user. However, this bug is just so annoying that I am forced to switch back to IE/Outlook. Hope some day this bug will be gone because I love FF/TB, but I really can't deal with seeing this annoying pop up every time.

I think dennison's comment above shows the real problem here. Under some circumstances, the mismatch dialog will pop up *every time* Thunderbird checks for new email. This happened to me when I first started using Thunderbird and prompted me to start following this thread. Since then, Thunderbird hasn't exhibited the same behavior (even on different machines accessing the same mail server with the mismatched cert.) I think most people would be content if the mismatch dialog occured once and only once for each instance of Thunderbird, instead of for each time Thunderbird checks for mail. Unfortuantely, I can no longer duplicate the problem of Thunderbird notifying me of the mismatch every time it checks for mail, even though I'm using the same mail server I was when I experienced that problem, so I am unable to provide any details that would help identify the situations under which this problem occurs.

(In reply to comment #78) > Hi people, > > I am a nobody here. I am just a regular Firefox/TB user. However, this bug is > just so annoying that I am forced to switch back to IE/Outlook. Hope some day > this bug will be gone because I love FF/TB, but I really can't deal with seeing > this annoying pop up every time. >

(In reply to comment #78) > Hi people, > > I am a nobody here. I am just a regular Firefox/TB user. However, this bug is > just so annoying that I am forced to switch back to IE/Outlook. Hope some day > this bug will be gone because I love FF/TB, but I really can't deal with seeing > this annoying pop up every time. > ===================================================================== (oops)-sorry for the blank. New user. ==================================================== TEMPORARY FIX Desperate for a quick fix? Just a quick note which may be of use to anyone with a comment such as the one above. Someone has created an extension which re-installs the checkbox to remember this preference. The post can be found here: http://forums.mozillazine.org/viewtopic.php?t=370852&highlight= Thanks all for creating the state-of-the-art in browsing and email.

*** Bug 324923 has been marked as a duplicate of this bug. ***

(In reply to comment #81) > http://forums.mozillazine.org/viewtopic.php?t=370852&highlight= What about a temporary fix for seamonkey?

Can we have a vote for cloture to resolve this bug? And similarly for the related circumstance, an expired certificate, which also does happen in the real world with dismaying regularity.

(In reply to comment #84) > Can we have a vote for cloture to resolve this bug? While the extension works great for me, I grow tired of managing all these extensions and I believe some functionality that is currently provided by extensions should built-in. This is definitely a perfect example of that. I would therefore vote to leave the bug open to encourage this functionality to built-in.

I agree. IMHO security issues should not be handled by extensions as long as it is possible to built the feature into the main app.

(In reply to comment #86) > I agree. IMHO security issues should not be handled by extensions as long as > it is possible to built the feature into the main app. Right. When a user regularly accesses a mail server with a domain mismatch problem, repeatedly showing the dialog reduces the security of Thunderbird, while suppressing the dialog increases security. Making users in this situation install an extension to get more security seems too high a hurdle. Not to mention that the extension doesn't actually implement nsIBadCertListener, as comment 76 indicates would be the correct solution to the bug. Instead, it merely "clicks" the OK button in the dialog. It's a workaround, not a solution.

> Can we have a vote for cloture to resolve this bug? There is absolutely no reason to close it IMHO. Extensions are for extra functionality, not bug workarounds.

(In reply to comment #87) > (In reply to comment #86) > > I agree. IMHO security issues should not be handled by extensions as long as > > it is possible to built the feature into the main app. > > Right. When a user regularly accesses a mail server with a domain mismatch > problem, repeatedly showing the dialog reduces the security of Thunderbird, > while suppressing the dialog increases security. Making users in this > situation install an extension to get more security seems too high a hurdle. > > Not to mention that the extension doesn't actually implement > nsIBadCertListener, as comment 76 indicates would be the correct solution to > the bug. Instead, it merely "clicks" the OK button in the dialog. It's a > workaround, not a solution. I'd be interested in a patch that implements comment 76. I exchanged some e-mails with a couple extension writers who were going to collaborate on a solution using this technique, but I haven't heard back from them in a while.

Comment 76 appears to propose to ignore all cert name mismatch dialogs. Is that really what you're proposing? Do you understand the implication of such a proposal on, say, auto update security? See bug 340198.

(In reply to comment #90) > Comment 76 appears to propose to ignore all cert name mismatch dialogs. > Is that really what you're proposing? > > Do you understand the implication of such a proposal on, say, auto update > security? See bug 340198. > I was envisioning the extension checking against the list of domains the user wants to ignore the mismatch dialog for in confirmMismatchDomain, forwarding the rest of the errors on to Thunderbird's implementation.

Are there really any domains for which the user wants to ignore ALL name mismatch errors? These would be domains for which the user doesn't care if he gets MITM attacked or not. I think what these users want is the ability to remember *a specific cert* as being acceptable for *a specific host name* not listed in it. That's not vulnerable to MITM attacks using other, previously unseen, certs.

> I think what these users want is the ability to remember *a specific cert* > as being acceptable for *a specific host name* not listed in it. > That's not vulnerable to MITM attacks using other, previously unseen, certs. Right. I think what we want here is to offer users the ability to turn off cert name mismatch dialogs only for connections to configured email servers and only for specific host/cert combinations. For other kinds of connections (automatic updates, remote content like images in HTML mail, etc.) we should continue to do what we're currently doing when we get a mismatch (i.e. cancel the load or prompt the user).

Re: comment #88, this isn't a bug - witness the severity : "enhancement" . Re: commment #75, you may not need to store the entire certificate to implement this RFE. You could just store 2 hashes (done with 2 different algorithms; or more if you are really paranoid) of the certificate, along with the hostname for which you want the cert to always be good for.

(In reply to comment #1) > this is especially annoying when you have thunderbird set up to check mail > every minute -- it presents the dialog each time. Can anyone confirm that? If true, that is a separate problem. That would be a bug, pure and simple, in the way the email client is using SSL. This bug is about host name mismatch overrides not being remembered after restarting the client process (browser or email). If the email client doesn't even remember the mismatch override within the same process lifetime, then the email client is not giving libSSL the info needed to cache the session, or to find it in the cache. A separate bug should be filed for that, if confirmed.

(In reply to comment #95) > (In reply to comment #1) > > this is especially annoying when you have thunderbird set up to check mail > > every minute -- it presents the dialog each time. > > Can anyone confirm that? > If the email client doesn't even remember the mismatch override within the > same process lifetime, then the email client is not giving libSSL the info > needed to cache the session, or to find it in the cache. > A separate bug should be filed for that, if confirmed. > The logic behind it is that the IMAP/POP/SMTP connection is often completely new. New connection, new SSL transaction, etc. I know our system has a load balancer in the way, and after so long of idle time the connection is simply flushed, so the SSL state information is long gone. For active live connections that persist the dialog is not presented again. If there are no security implications I don't see what the issue is. I've been over that in previous comments though.

> ... after so long of idle time the connection is simply > flushed, so the SSL state information is long gone. > > For active live connections that persist the dialog is not presented again. Just a thought: given this, might it be possible for folks who get the dialog on every mail check to avoid it by increasing the frequency of their mail checks? (i.e. to avoid the cache timeout?)

Kelly Kane, The duration of an SSL session is not tied to the duration of any TCP connection nor any group of TCP connections. An SSL session between a client and a server typically lasts until 24 hours have elapsed, or until the client process ends, whichever occurs sooner. An SSL session may be used by multiple TCP connections between the same client and server, whether those connections overlap (e.g. are simultaneous) or are purely sequential (one after another) with no overlap. The re-use of SSL sessions avoids the costly RSA, RSA< or ECC computations, AND it avoids all the cert validation logic, by reusing the previously validated and negotiated session secrets. It never hurts to try to use an old session. If the other end no longer honors that session, it just starts a new one anyway. There are no extra connections, nor round trips, nor other bad side effects of attempting to restart an old connection, and there is significant benefit to doing so when an old session is succesfully reused. At this point, I wonder how much of the perceived problem is due to the cert mismatch info not being preserved over multiple sequential process lifetimes, and how much of it is due to failure to re-use SSL sessions that already live in the local process's session cache. The former requires significant new development. The latter would simply be a misuse of th existing NSS API, and proably trivial to fix. The "issue" with failing to re-use the SSL sessions is huge user inconvenience and bad user experience. Indeed, this is the same issue with failing to preserve cert name mismatch issue across process lifetimes, but presumably the frequency of one problem is much greater (and hence perceived more severe) than the other. Is there another bug about the lack of SSL session reuse in a single process lifetime? I really don't want to further lengthen this bug about that topic.

(In reply to comment #95) > > this is especially annoying when you have thunderbird set up to check mail > > every minute -- it presents the dialog each time. > > Can anyone confirm that? Well, unless I have misconfigured Tb 1.5.0.5, yes I have this problem with 2 mail servers. Every 20 minutes or so (the time between two successive checks for new emails), I have to click "OK" twice (once per server). Did someone say "annoying"? ;)

Fred (?) Buclin, Do these server certs have valid DNS names in them? Can you access those servers by the names in the certs? If so, What happens if you reconfigure your mail accounts to fetch the mail from the servers with the names in the certs? I'll get the mismatches simply disappear. Others have reported success with this method. Better to light a candle than curse the darkness.

(In reply to comment #100) > Better to light a candle than curse the darkness. Hum, yeah, this works. Shame on me for not trying this earlier. :-/ Thanks Nelson.

As mentioned before by Nelson Bolyard, any issue having to do with a domain mismatch dialog being shown multiple times during a single Thunderbird session is NOT the issue described in this enhancement request. This issue deals with a common situation under shared hosts where Hostname A must be specified on the client side, but a certificate for Hostname B is always presented on the server side.

I'm the author of the Remember Mismatched Domains extension. I'd really like to update RMD to implement Scott's <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=228684#c76">'Comment 76'</a> suggestion but am not sure it's possible. I'm able to successfully provide a custom notificationCallbacks for the MessageBrowser ("messagepane") however it seems other components also trigger the Mismatch dialog... If anyone has suggestions on how I can get this going for those as well I'd be very happy to implement a more 'proper' solution. As it stands I'm running out of ideas (as resorting to soliciting assistance in bugzilla might indicate).

*** Bug 362737 has been marked as a duplicate of this bug. ***

How can disable this message without the workaround with an extension? Can I delete the certificate or where is this informations stored in TB?

I have been frustrated by the constantly popping-up dialog boxes as well. The extension does elegantly solve the problem: https://addons.mozilla.org/en-US/thunderbird/addon/2131 I would love to see this standardized in the client as well, perhaps under the Edit/Preferences/Advanced/Encryption tab. I understand the security arguments against making this extension a standard feature, but consider this: 1) User frustration over constantly popping-up dialog boxes shifts user preference away from Thunderbird and toward other email clients like Outlook, with the resulting security problems. 2) User frustration over constantly popping-up dialog boxes causes users to quickly click the "OK" button, ignoring the text. What if it had been a real security breach, featuring a MITM redirection attack to a new domain or IP address that the user hadn't seen before? The design of the extension, remembering pairs of domains/IP addresses and only those pairs that have been pre-authorized by the user, is exactly the correct approach. If a real MITM attack should occur, the user will be presented with the correct dialog box again. 3) Many users are powerless to change the SSL certificates of the email sites they use. The SBC Yahoo example above is a good example. Even a huge web corporation like Yahoo can't get it right when switching from SBC to AT&T. Without the extension, all users of SBC Yahoo email will be presented with endless dialog boxes. That's a lot of frustrated users! 4) Many low-cost web hosting providers only use a single certificate to cover all of their domains. Due to the high cost of getting an official certificate that is signed by the recognized authorities, many small providers only do this once, and then let all of their customers share a common certificate. Of course, the domains won't match. The users need this extension, to get around the annoying dialog boxes. This approach is still about as secure as it's going to get, since if an attacker breaks into the web server containing many virtual hosts, they can grab all of the data anyway, and it wouldn't make a difference whether the virtual domains each use an individual SSL certificate or share a common certificate between them. 5) Expired certificates are just as annoying as mismatched certificates. The design of this extension, remembering pairs, works elegantly well to solve this problem as well. Instead of containing two domain/IP address pairs, the pair here consists of the certificate domain and the expiration time. The user is given the choice to remember this pair, and not have to answer any more dialog boxes until the expiration time changes again. The user is still protected against a substitution attack, because a real dialog box will be displayed if an attacker unexpectedly substitutes an old, expired, possibly-cracked certificate that the user hasn't accepted before. So, these 5 reasons are my votes for getting this extension's features built directly into the Thunderbird client. It's not something that should be marked as INVALID due to a perceived security problem, on the contrary, it helps security by easing the constant nagging that tricks users into blowing past dialog boxes and not reading them. It saves the nagging for a real security breach, when it is much more important to nag the user!

Thank you Josh for composing that. It is always frustrating to me when programmers will not listen to their users. Not having this feature does indeed make it less secure rather than more secure. The typical user will click the accept button without reading it when they are confronted with endless warnings.

Will this be fixed as part of bug 327181, or will Thunderbird need its own changes?

(In reply to comment #112) > It is always frustrating to me when programmers will not listen to their users. Um, in case you haven't noticed, there are only two full-time developers working on mail&news.

(In reply to comment #114) > Um, in case you haven't noticed, there are only two full-time developers > working on mail&news. Of course he didn't notice. How could he? How would he, or anyone, know which developers are working on what? I certainly have no idea, and I don't know where that information is. Perhaps you could enlighten us?

Please, let's not get into that kind of discussion. Bugzilla is not meant as a forum, it's meant for bugs and on how to fix them. If you really think this should be fixed, I guess you could set the blocking1.9? flag.

(In reply to comment #113) > Will this be fixed as part of bug 327181, or will Thunderbird need its own > changes? Thunderbird will not need its own changes, the code in bug 327181 and bug 387480 is planned to work with any application and protocol. A backend enhancement to cert fetching in bug 327181 will be required, because xmlhttprequest by default blocks connections to mail protocols. The new interface/service would have to get accepted for shared ff3/tb3 branch. Hopefully I can get it done soon enough. That new service would have to do a ssl connection to the server, obtain the cert even though the certificate is bad, close the connection without bringing up any error messasges, and make the cert status available for the UI in bug 387480. If you want to get this done asap, feel free to contribute programmer resources to get this done. I'm willing to provide guidance if someone steps up.

I don't think this qualifies as a blocking bug anymore, due to there being a valid workaround (extension). The argument about security for the common user isn't very strong for making it a blocking bug, because I'm sure this wouldn't be the default option. I don't think the common user is going to realize that they can go into some advanced security option to disable this, they will probably just keep hitting OK. Thus, the users who understand this issue and want to fix it already have an option of fixing it by downloading the extension. That is not significantly harder than enabling an advanced option. Don't get me wrong, I'd love to see this feature/bug added. However, I also realize now that there is a good workaround for it, and that if there was an advanced option, it wouldn't really be much different from the extension that already exists. I'd rather have programmers working on bugs that have no easy workaround.

I agree to Stevens last paragraph, but I see no reason not to include the extension as default. This way every user will get the close at hand option to add the specific pair as trusted. I would like to comapre this to the fature with allowing popups for a certain site. Of the functionality of the NoScript extension. Making the extension a natural part of the software would just follow the natural behaviour of FX.

(In reply to comment #118) > I don't think this qualifies as a blocking bug anymore, due to there being a > valid workaround (extension). As stated previously, extensions are for adding features, not for fixing bugs.

(In reply to comment #120) > As stated previously, extensions are for adding features, not for fixing bugs. Whether or not the lack of some particular feature qualifies as a bug is not always clear-cut; in addition, since the present report is of "enhancement" severity, it is not about fixing what people usually call a bug, but rather about adding a feature. However, this is not the right place to discuss it: you might find more sympathetic listeners in some of the newsgroups on the news.mozilla.org server.

Can this bug be closed now? Should it be morphed into a Thunderbird-specific bug about adding the UI to fetch certs as part of account creation (or do we have that one already?)?

I agree this bug should be fixed as part of bug 387480, or better, I'd like to mark it as a duplicate of bug 387480. The workaround for mail server is: - connect first - then go to servers tab and add exception (see bug 399043) The security engine will not offer an immediate click-through that we had in the past. We have implemented a multi-step-assistance for adding exceptions, which comes with warnings and requires consideration, as part of bug 398718 and bug 401575. What's left for mail, what could be done to improve the user experience for mail servers with bad certs? Because mail accounts are configured, that configuration UI seems to be the right place to add a hint/link/button to the add exception mechanism. If you want to do that, I propose to file a separate bug against the mail UI.