1249348 - compartmentalizing certificate overrides via containers

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Kamil Jozwiak [:kjozwiak]]

Currently, certificate overrides in fx are global. This affects private browsing and containers respectively. If a user overrides a certificate in a tab/window with a userconextid=0, that decision will propagate to the other containers including private browsing.

Example of a possible attack vector:

* user visits a sketchy website using another container and overrides the self-signed certificate that's served
* the user then loads his personal container and goes back to normal use thinking is previous decision won't affect his personal container
* the user ends up visiting a website that attempts to load the sketchy website in an iframe via a timing attack to see if the user has visited that particular website

Used the following websites to override certificate warnings:

https://expired.badssl.com/
https://wrong.host.badssl.com/
https://self-signed.badssl.com/
https://superfish.badssl.com/
https://edellroot.badssl.com/
https://dsdtestprovider.badssl.com/
https://superfish.badssl.com/

We should discuss what the correct behaviour should be relating to containers. Should certificate overrides be compartmentalized based on the container the user is in?

Comment 1

[Tanvi Vyas[:tanvi]]

We discussed yesterday in our meeting.  We decided we should have an about:config pref to make this configurable (ex: compartmentalize_tls_overrides).  If set to true, certificate overrides would only persist in the context they were set in.  This includes usercontextids and private mode.  So a cert override in private mode wouldn't be honored in regular mode.  If set to false, certificate overrides are global for all user contexts, regular and private mode.

Now we have to decide the default.  Let's look at the consequences of each option.
* If set to false, attackers could use a timing attack to leak information.  Attackers could find out if you have visited certain websites in another context, assuming those websites required a certificate override (lets call them requires-override-sites).  The attacker wouldn't know which context you visited the requires-override-site in, just that your browser visited the site at some point.  Attackers wouldn't be able to discern anything about HTTPS websites that don't require a cert override and all HTTP websites.  Users would see cert error pages less often, and hence be more likely to read them and properly make a decision about whether to visit the site.


* If set to true, attackers would only be able to determine if you visited a requires-override-site in the same context that you are currently in.  Users would see more certificate errors for a site they frequently visit in different contexts, since they will have to add the exception to each context, making them more prone to habituation / warning fatigue / ignore the error.

Do we expect attackers to try and discern information about the average users use of requires-override-sites?  Not likely; this seems like it would be more of a targeted attack.  The point of containers is for average or power users to separate their different online identities.  It is not meant to be robust enough for a targeted attack on say a journalist or a government.  This is an argument o set the pref to false.

On the other hand, do we expect average users to visit the same requires-override-site in different contexts? If not, then we could set the pref to true.

Comment 2

[Tanvi Vyas[:tanvi]]

From telemetry, 0.6% of HTTPS requests went through a certificate override.  This is a platform only bug, and not needed for the initial launch.  Marking it P3.

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-03-03&keys=__none__!__none__!__none__&max_channel_version=release%252F45&measure=SSL_CERT_ERROR_OVERRIDES&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-03-03&table=1&trim=1&use_submission_date=0

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020