251407 - Changed https certificates look the same as new ones when the 'do you want to accept' screen comes up.

Status: RESOLVED DUPLICATE of bug 1112408

(Core Graveyard :: Security: UI, defect)

Description

[Chris Morris]

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.

Comment 1

[Gervase Markham [:gerv]]

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/

Comment 2

[Chris Morris]

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

Comment 3

[Kai Engert (:KaiE:)]

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