Closed Bug 1492498 Opened 3 years ago Closed 2 years ago
Make certificate exceptions on the new cert error pages permanent by default
Bug 1492498 - Make certificate exceptions on the new cert error pages permanent by default. r=nhnt11,keeler
47 bytes, text/x-phabricator-request
|Details | Review|
54.49 KB, image/png
(Filing this bug as a follow-up to a Slack discussion.) Previously, when we hit a self-signed certificate, we allowed the user to add a permanent exception by clicking through several dialogs. We recently changed that to be a temporary two-click exception which cannot be easily made permanent (other than by adding it manually in preferences. Getting the behavior right here is hard because there are many different scenarios in which we could encounter this, some being bad/discouraged (e.g. internet hosts, MitM attacker on public wireless) and others being ok (e.g. embedded hosts on the local home network). We cannot easily distinguish between these cases (not on a network level, and even if we could on a network level, it might still be a public LAN with an attacker). What we could do however is to check, if we visited this site/host before. If this our "first contact" with the host, it might be worth presenting the user with an easy way to add a permanent exception (and a permanent exception here would be more secure than a temporary exception). If however we have visited this host before and we successfully connected without an exception (regular cert) and we now see a self-signed certificate, that seems like an entirely different situation that makes a MitM very likely and we could make the override harder. We would still have to figure out technical details on how to confirm that we successfully visited the site before and that it didn't come with a self-signed cert previously.
Whiteboard: [cert-errors][triage] → [cert-errors]
Sorry for the delay on this. I don't think we can distinctly identify sites that were previously visited with a broken cert. I'm not sure the use case here warrants adding a field for that in places or so. Still, regular visited-ness may suffice. I'm mainly unsure about two questions: - How are we communicating to the user that in this situation we actually add a permanent exception for the site, vs. a temporary exception in most other cases? I kind of dislike the idea of doing this implicitly. - What is the best way to inform the user that they are about to enter (or have entered) a site that could be totally legitimate but requires their absolute trust and attention. Bram and Meridel, do you have any ideas? We can also chat about it if you want to know more...
I set time with Bram to discuss UX approach. Will report back.
Meridel and I have met and discussed approaches to potentially solve this problem. She will set up some time to meet with Johann to discuss these approaches. After a reasonable solution has been reached, we’ll work on the design and content together.
Johann, please see our notes here and comment on the ideas and final proposed approach. https://docs.google.com/document/d/1bRgQ6posV3srQDWTHKr9f_SsVlNQJ9K3tXaaQu6Rhr0/edit Happy to meet and discuss, as well.
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Priority: -- → P1
Summary: Treat TLS self-signed exceptions on first visit different to follow-up exceptions → Make certificate exceptions on the new cert error pages permanent by default
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6aefbed9ce43 Make certificate exceptions on the new cert error pages permanent by default. r=nhnt11,keeler
You need to log in before you can comment on or make changes to this bug.