Security/Foreign Certificate Warning

From MozillaWiki
Jump to: navigation, search
Warning signWarning: This is just a draft proposal for a new Firefox feature

Description

Firefox shows a non-dismissable banner at the top of each page when the site you're connecting to uses a dodgy cert somewhere down in the chain.

The precise definition of a dodgy cert is TBD but it would trigger when a root cert is added that's not part of the Mozilla CA program and is part of the chain for the currently visited site.

Non-dimissability

Flow
Toolbar Indicator
Information Page

There are three axes to look at when considering how dismissable the banner should be:

  • How easy is it to dismiss?
    1. It's not dismissable at all.
    2. You need to click on the banner, read the explanation page, and scroll down to find the "dismiss" button.
    3. You click the X on the banner.
  • How long does it stay dismissed?
    1. It shows up next time you navigate to a page that meets the triggering conditions.
    2. It's gone until you close the browser.
    3. It's gone for 30 days.
    4. It's gone forever (in that browser profile).
  • How hidden is it once it's dimissed?
    1. The message is shorter, but it's still there.
    2. It gets down to just a warning icon (which could expand when you mouse over it).
    3. It's completely gone from the UI.

Requirements

  • Security Engineering:
    • Persistent, non-dismissable message in a fairly prominent place
    • Looks like a warning (or a reminder), not an error message
  • User Experience:
    • Consumes zero site real estate
    • Message can resize to consume minimal tab real estate (it still has to consume some space, but we minimised it as much as we could)
    • Not in-your-face; users won’t get annoyed and switch browsers

Use cases

  1. Malware: a user bought a new Lenovo laptop and has the Superfish root cert installed in their browser.
    • User action: take steps to remove the malware and then verify that the warning is gone
  2. Corporate surveillance: a user works in a company that deals with sensitive data and monitors all employee web browsing as per their employment contract
    • User action: avoid visiting personal sites on company property
    • User action: if the website (e.g. online banking) should be whitelisted and not mitm'ed, contact local system administrator to get this fixed
  3. Parental filter: a parent installs a surveillance proxy to watch what their children are doing online
    • User action: none, but keep in mind that your parents are watching
  4. Anti-virus products: a user installs an anti-virus product which scans all visited sites for malware
    • User action: none, your traffic are protected by the XYZ Security Suite
  5. Debugging: a developer installs mitmproxy to debug TLS traffic
    • User action: don't forget to remove the mitmproxy root cert once you're done testing

Impact

The banner is a warning, not an error. There are lots of legitimate reasons why a non-Mozilla approved root cert can be added to the browser.

However, in almost all of these legitimate cases, the extra warning can be said to be a useful reminder.

In the non-legitimate use cases, the warning can alert users to a serious security problem.

Challenges

  1. By showing a warning, you can perceive that Firefox is broken and switch to another browser that doesn’t show any warnings.
    • Clicking on the warning should open a page in content (similar to what we do for invalid HTTPS certs) which explains the possible causes of this warning and what you can do about it.
    • Whatever happens, we must assure user that Firefox is not broken. On the contrary, it’s the other browsers that aren’t showing them any warnings. It's an opportunity to show the user that we care and that we have their back.
  2. Often, nothing you do will fix the problem because the root cert reinstalls itself and the problem is deeper (e.g. Superfish)
  3. The name of the certificate issuer is under the controller of the person minting the cert (i.e. the attacker in malicious cases).
  4. Organizations using private CAs would be affected by this even though in this case there is no MITM (see rsleevi's comment on a similar feature).
    • It's not clear whether this would be perceived as bad for internal sites (see mnot's comment).
  5. Giving users a simple explanation for why this is something they should worry about and giving them some actionable suggestions for resolution/mitigation.

Related