1143337 - Show visual warning if HPKP / DANE-TLSA or CAA has activated MiTM status

Status: RESOLVED WONTFIX

(Firefox :: Security, defect, P3)

Description

[will-i-am]

Attachment: Example of actual result (visit to twitter.com with a user-installed root certificate)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/8.0.3 Safari/600.3.18

Steps to reproduce:

1. Install firefox as default
2. Install a anti-virus solution (or MitM proxy) that adds a root certificate, like Avast does.
3. Accept any root certificate addition that will be prompted on installation
4. Leave the security.cert_pinning.enforcement_level on the default 1 (meaning it will Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default); source: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status)


Actual results:

Website will show correctly, click on the lock icon will just show it's validated.
See screenshot.


Expected results:

Website should show correctly, but clicking on the lock icon should very clearly state that the certificate that was used was NOT a certificate Firefox trusts by default and was installed by the user. Users should be advised this is not normal.

This might increase awareness and make a transition to status '2' of security.cert_pinning.enforcement_level more fluent.

Comment 1

[:Gijs (he/him)]

mmc, thoughts?

Comment 2

[[:mmc] Monica Chew (no longer reading bugmail)]

There's no reason for this to be a security-sensitive bug, but I don't have access to change that.

Re: the default pinning enforcement level, see https://bugzilla.mozilla.org/show_bug.cgi?id=1059392. The big obstacle to changing this will be enterprise.

Re: UI changes to notify users more when pinned sites are circumvented by user-installed roots, rbarnes has been thinking about this especially since superfish. I'm not sure if any bugs have come out of this.

Comment 3

[:Gijs (he/him)]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #2)
> Re: UI changes to notify users more when pinned sites are circumvented by
> user-installed roots, rbarnes has been thinking about this especially since
> superfish. I'm not sure if any bugs have come out of this.

rbarnes? :-)

Comment 4

[Richard Barnes [:rbarnes]]

Gijs: Sorry, this has just been low on the priority list.  There might be some utility to this indicator, though ISTM that in most scenarios (a) the user is already aware of the monitoring (e.g., because they installed the AV), (b) the user can't do anything about the monitoring (e.g., corporate), or (c) the monitoring thing is aggressive enough it would modify Firefox to suppress the indicator (e.g., Superfish).  Happy to keep this bug open to discuss.

Aislinn: Thoughts on this from a UX point of view?  Basically we would want to provide the user some notification that they're not guaranteed to be talking to the real site.

Comment 5

[Ash Grigas]

(In reply to Richard Barnes [:rbarnes] from comment #4)
> Gijs: Sorry, this has just been low on the priority list.  There might be
> some utility to this indicator, though ISTM that in most scenarios (a) the
> user is already aware of the monitoring (e.g., because they installed the
> AV), (b) the user can't do anything about the monitoring (e.g., corporate),
> or (c) the monitoring thing is aggressive enough it would modify Firefox to
> suppress the indicator (e.g., Superfish).  Happy to keep this bug open to
> discuss.
> 
> Aislinn: Thoughts on this from a UX point of view?  Basically we would want
> to provide the user some notification that they're not guaranteed to be
> talking to the real site.

I think something minimal when the user opens the control panel is the right level here since people for the most part can't take an action on the feedback we give them. I would suggest we add a line of copy below the secure connection copy like we do for the insecure password on developer edition
https://www.dropbox.com/s/026pp8hvafoq5p1/Screenshot%202015-11-16%2010.33.44.png?dl=0
versus changing the icon in the url bar.

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

This is a decision for Firefox front-end.

Comment 7

[:Gijs (he/him)]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #6)
> This is a decision for Firefox front-end.

Panos/Jonathan, can you ensure this gets radared to the folks working on the location bar security indicator? Thanks.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

We'll discuss this on Friday.

Comment 9

[nospam]

(In reply to Panos Astithas [:past] from comment #8)
> We'll discuss this on Friday.

Can you give us a result?

Comment 10

[:Gijs (he/him)]

(In reply to nospam from comment #9)
> (In reply to Panos Astithas [:past] from comment #8)
> > We'll discuss this on Friday.
> 
> Can you give us a result?

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

The result of the discussion was to set the priority of this bug to P3, which means we intend to work on it in some future version of Firefox.

Comment 12

[will-i-am]

As HPKP is becoming less and less implemented, incorrect DANE/TLSA or incorrect CAA matches could be considered for the same warning.

Comment 13

[mozilla.org]

It's been a year, any chance of getting this included?
As the DNSSEC validator (www.dnssec-validator.cz) does no longer work with Quantum Firefox (and seems to have issues with the DNSSEC root key switchover, maybe just on my machine :-)), showing some information about the TLSA record status (DNSSEC verified) directly WITHIN firefox would be great.

See also: bug 672600

Comment 14

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1135776#c10 this is a wontfix beyond what we have already completed.