1135776 - show a different UI for certificates issued by non-built-in root certificates

Status: RESOLVED WONTFIX

(Firefox :: Site Identity, defect)

Description

[Dana Keeler (she/her) [:keeler]]

(I thought there was already a bug on this, but I couldn't find it.)

When verifying a certificate presented over TLS by a website, we may find a trusted path to a built-in root or a user-installed root. If the latter, we should indicate this somehow to the user. Initial ideas are using a different icon (i.e. modify the lock icon) and perhaps something in the identity drop-down (and maybe something in the Security tab of the Page Info window).
This requires some UX/design work.

Comment 2

[kanepyork]

From what I can see, we currently have:

 - No SSL: Grey globe
 - Mixed content: Yellow warning sign
 - User-confirmed exception: Grey warning sign
 - Normal SSL: Grey lock
 - EV SSL: Green lock + organization name

I like the suggestion to use a blue lock or an open padlock, never showing EV details, with mouseover + click wording stating that this is due to the use of a user-installed CA root.

Comment 3

[kanepyork]

Attachment: "Unknown ssl" mockup

I made this mockup for the Chrome bug report, so figured might as well put it here too.

Comment 4

[Cesar Eduardo Barros]

(In reply to kanepyork from comment #3)
> Created attachment 8570970 [details]
> "Unknown ssl" mockup
> 
> I made this mockup for the Chrome bug report, so figured might as well put
> it here too.

Could you put here a link to the Chrome bug report, in the "See Also" field if you can edit it, else in a comment? (If it does not exist yet, a link in the other direction would be useful too.)

Comment 5

[kanepyork]

Sure.

Chromium bug report: https://code.google.com/p/chromium/issues/detail?id=81623

Comment 7

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Note that this sort of interception is a safety risk to women in abusive relationships and other marginalized groups and usually conducted by the spouse/partner/caregiver installing hostile software on the target users' devices.

The warning should be conspicuous enough that the user sees it, can hide it, and cover its tracks so the person installing the malware does not know the target has been warned.

This will mean that we need to be aware of enterprise installed roots, and not warn on those (assuming the user has been notified through employment agreements, etc, about monitoring.)

Comment 8

[Eric Rescorla (:ekr)]

1. It looks to me like Chrome isn't doing anything here because they don't consider local attackers part of their threat model.
2. We're generally moving away from adding a lot of UI to distinguish small difference between cases because the data suggests users can't distinguish them.
3. I don't know how to distinguish between enterprise roots and roots installed by malicious local attackers.

Comment 9

[Eric Rescorla (:ekr)]

It's also worth noting that the absence of a MITM certificate does not mean that you are not under attack from a MITM attacker. Consider the case where an attacker uses their MITM access to install a malicious version of some of the JS on the page with a very long cache lifetime and then uses that to report back on the user's behavior even after they are no longer MITMing the connection. So, the absence of the MITM indicator is not a reliable indicator

Comment 10

[Johann Hofmann [:johannh]]

For the reasons Ekr listed this is a WONTFIX for primary UI, however we did add an indicator in secondary UI (the identity panel) to offer concerned users a non-intrusive way of verifying the source of trust in bug 1549605.