User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040707 Galeon/1.3.16 (Debian package 1.3.16-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040707 Galeon/1.3.16 (Debian package 1.3.16-1) A site has a https certificate that is not signed by a widely-known Certification Authority (CA). Mozilla correctly asks the user if they would like to accept the certificate, giving choices of permanently, temporarily, or not at all. They select permanently, and the site works fine from then on. The problem comes when this https certificate changes - Mozilla provides no warning that this certificate is a different certificate to the one remembered for this site, despite this being an obvious sign of a man-in-the-middle attack. While it is possible for a user to manually check that they do not already have a certificate, this is a multi-step process. Reproducible: Always Steps to Reproduce: 1. Set up an SSL-capable web server on a computer. 2. Give this web server an SSL certificate created using a one-off CA. (self-signing) 3. Start Mozilla and connect to the https server and accept the certificate permanently when prompted by Mozilla. Do not take any steps to trust the CA itself, only this particularly certificate. 4. Shut down Mozilla. 5. Stop the web server, and create a new certificate/certificate authority pair. 6. Restart the web server with this new certificate. 7. Connect to the server as in step 3 and observe the 'unrecognised certificate' dialogue box. Actual Results: The 'unrecognised certificate' box in step 7 is identical to that in step 3. There is no warning that the certificate is for the same host as one that already has a different trusted certificate. Expected Results: Given a prominent warning that the certificate for this host has been CHANGED and the new certificate is not trusted. Warn that this may be a symptom of a man-in-the-middle attack. Consider ssh's way of doing things - cim@dinopsis:/usr/home/cim$ ssh mitm @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. ...etc... before refusing to connect. PuTTY (the Windows SSH client) has similar behaviour. The reproducibility information isn't *quite* correct - the one circumstance I found in which it failed to be reproduced was when the CA information for the changed (i.e. potentially malicious) certificate was identical to that of the first (though the CA key itself was different) *and* the certificate serial number was the same. Obviously this is an easy thing for a black hat to avoid, though. This bug affects Firefox and Mozilla as well as browsers based on them.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

I still think this is an issue, and it would be a security improvement for users if something were done about it. That said, no other major browser seems to have fixed this issue either (though Opera and Internet Explorer are less susceptible). Close it and say you won't fix it if you like, but I don't think it should just be marked as closed solely because it's been too low priority to be looked at in any detail yet (and I admit the scenario I've described is only a problem in certain situations, so I wouldn't expect it to be a high priority) Thanks -- Chris

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody