Closed Bug 471798 Opened 16 years ago Closed 10 years ago

need UI to warn if SSL cert changed

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 787133

People

(Reporter: felix-mozilla, Unassigned)

References

Details

(Whiteboard: To vote hit the (vote) link, no need to comment [bug etiquette])

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121714 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121714 Firefox/3.0.5 Mozilla needs some UI to warn the user if the SSL cert changed since the last time we went to this site. Right now, if I go to a site, and someone manages to get a certificate for that site (see http://blog.startcom.org/?p=145 or https://events.ccc.de/2008/12/30/the-cat-is-out-of-the-bag/ for examples) and pulls a man-in-the-middle attack on me, I don't find out. I want mozilla to tell me and NOT send any data to the site before I approve. I realize this would yield false positives when the certificate is renewed, but mozilla could detect that and warn in friendly colors that the old certificate has expired in the mean time and it's probably OK. This is a really important UI thing to have, even if you disable it by default. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Seconded.
+1. My bank sends letters with the certificate fingerprints. They also inform me about certificate updates. With the suggested UI this is actually useful since probably most users don’t compare the fingerprints everytime.
+1
Whiteboard: To vote hit the (vote) link, no need to comment [bug etiquette]
+1
Let's nip this "+1" meme in the bud: please VOTE for the bug instead of adding a comment just to "me too" (link on the "Importance" line). Martin F.'s comment 3 adds interesting extra information (I had no idea some banks did that), we're not objecting to comments like that. [highmind63 already noted this in the Whiteboard. I'm commenting anyway so it'll be more visible to people new to the bug.] This may be a dupe, it's not a new suggestion (although the ones I'm thinking of might involve self-signed certs which is a different issue).
Severity: normal → enhancement
bug 286107 is similar but different as it suggest that as default behaviour on all sites.
wow Martin F.'s comment 3 your bank is probably a really good bank, it actually understand the security methods. Ive been trying to get my bank for a long time to sign a private key so that i can log in without insecure passwords, but they just don't understand the underlying technology. I hear this type of thing with real security certificates is more common in Europe.
This add-on may be implementing what is requested here... https://addons.mozilla.org/en-US/firefox/addon/6415 ... but it would still be nicer to have it built-in.
+1
Unfortunately certificates at servers (and elsewhere) change very frequently and I believe that's not a good defense, except for those that really understand digital certificates. The vast majority will learn to ignore the warnings and with every additional warning Firefox sends to the user, the user will be annoyed even more. I prefer to keep this to the minimum necessary. Instead CAs MUST implement controls to prevent occurrences as mentioned above. Some already did and others are on the way...also Mozilla and the community have vastly improved the review and approval process for CAs, I believe that an improvement can be felt already now and more is to come.
We are unlikely to implement this as described, as Eddy mentions, there are sites whose certificate management policies would make this a really terrible user experience. BUT I understand the desire for this kind of feature and I think there's a way to get much of the same functionality over in bug 495115. STS will allow sites to specify that they require all-HTTPS access in a persistent way, and will optionally allow them to "pin" their certificate/CA for some period as well. This allows for sites to renew their certificate without incident, but prevents a rogue CA or fraudulent cert from impersonating the site, unless it is obtained from the same CA as the legitimate one, drastically reducing the attack surface. When a certificate change happens which contravenes an explicit STS policy, we can be a great deal more confident about warning the user.
The STS spec doesn't actually say anything about certificate pinning... I think what Johnathan mentions was proposed by Gerv as an extension to STS (lockCA, or something like that). See: http://www.mail-archive.com/public-webapps@w3.org/msg05668.html Making this bug depend on strict-transport-security since I think the lockCA extension would mostly solve this problem. The STS spec says that https-by-default is opted into by the server, but we're going to enable it as a site permission so users can also manually set STS enforcement for sites of their choice. I imagine lockCA would be part of this as well (and thus part of the site permission UI).
Depends on: 495115
Carrying over the confirmation from bug 286107.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 556258 has been marked as a duplicate of this bug. I just add this comment here to make sure the finer points of 556258 are not lost in the merge: 1. The warning could only occur for certificate changes where the certificate is still far from expiration. That way, we would avoid needlessly spamming the user (and thus trivializing the warnings). This would also work without the site publishing an explicit STS policy (but, of course, _if_ the site did publish an STS policy on our previous visit, we would use that, rather than our own heuristics). 2. The warning would be much sterner if a change happens towards an other CA, especially one CA with a lower "trust rating" (to be defined) or geographic plausibility (Brasilian site suddenly using a Chinese CA).
We could resolve this one pointing to Certificate Patrol Add-On: http://patrol.psyced.org/ also at https://addons.mozilla.org/firefox/addon/6415/
This has been resolved in another bug. See https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning to learn more about deployment & browser support.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.