1420779 - HSTS error message incorrectly claims that "the owner of accounts.firefox.com has configured their website improperly".

Status: RESOLVED DUPLICATE of bug 1450784

(Firefox :: Security, enhancement)

Description

[Ryan Kelly [:rfkelly]]

(Sorry, I don't really know what component would be appropriate for this...)

Firefox ships with a built-in TLS certificate pin for accounts.firefox.com, and we use HPKP and HSTS headers to set additional restrictions.  This means that if the user has some local software (e.g. anti-virus) that installs its own certificates and tries to MITM TLS connections, then the Firefox first-run page will (correctly) refuse to load the Firefox Accounts login form, and instead display an error like this:

  https://twitter.com/GuiColomb/status/930163516300054533

Unfortunately the error text places the blame on accounts.firefox.com rather than the local software, saying:

"""
Your connection is not secure

The owner of accounts.firefox.com has configured their website improperly.  To protect your information from being stolen, Firefox has not connected to this website.
"""

Because this is on the first-run page, it's one of the first things such a user will see when trying out Firefox, and as the tweet above shows it does not make a good impression.

Is there a way to make this text more accurately reflect the source of the problem, rather than appearing to blame ourselves for a server misconfiguration?

Comment 1

[Johann Hofmann [:johannh]]

Do we know for certain that this is because of MitM software in this case?

I remember that Chrome has recently added additional diagnostics for the MitM case to their cert error pages. I generally believe we should do the same, but I'm not sure what exactly is required to get there. Maybe Keeler or JC have an idea.

Comment 2

[Ryan Kelly [:rfkelly]]

> Do we know for certain that this is because of MitM software in this case?

It's hard to be certain I guess.  Are there other client-side failure modes that could produce this error message, such as wildly wrong clocks making it look like a certificate expired?

Comment 3

[Matthias Versen [:Matti]]

see bug 1420721 for a bitdefender MITM at accounts.firefox.com

Comment 4

[J.C. Jones [:jcj] (he/they)]

(In reply to Johann Hofmann [:johannh] from comment #1)
> Do we know for certain that this is because of MitM software in this case?
> 
> I remember that Chrome has recently added additional diagnostics for the
> MitM case to their cert error pages. I generally believe we should do the
> same, but I'm not sure what exactly is required to get there. Maybe Keeler
> or JC have an idea.

We're working on it; Gecko hasn't traditionally even passed the real certificate chains around -- we're in the middle of fixing that (e.g., Bug 1406854).

(In reply to Ryan Kelly [:rfkelly] from comment #2)
> It's hard to be certain I guess.  Are there other client-side failure modes
> that could produce this error message, such as wildly wrong clocks making it
> look like a certificate expired?

It's possible, but chances are good that if they were that far off, the mozilla.org start page would have failed to load, too.


My hypothesis is that since https://www.mozilla.org/ serves an EV certificate, the man-in-the-middle software is letting it through unmolested, but since https://accounts.firefox.com/ is merely an OV certificate, it's being actively eavesdropped upon. Some MITM software leaves EV-certificate-protected connections alone so that the EV treatment remains in-place.

Comment 5

[Ryan Kelly [:rfkelly]]

> My hypothesis is that since https://www.mozilla.org/ serves an EV certificate,
> the man-in-the-middle software is letting it through unmolested, but since https://accounts.firefox.com/
> is merely an OV certificate, it's being actively eavesdropped upon.
> Some MITM software leaves EV-certificate-protected connections alone so that the EV treatment remains in-place.

:jbuck, any idea what would it take for us get an EV-certificate for accounts.firefox.com?

> Because this is on the first-run page, it's one of the first things such a user will see when trying out
> Firefox, and as the tweet above shows it does not make a good impression.

The first-run page is moving away from iframing FxA and towards opening it in a new tab, which won't help these MitM'd users actually sign in, but will have the nice side-effect of not showing this error message right up in their face when they first start the browser.

Comment 6

[J.C. Jones [:jcj] (he/they)]

Since the last update, we added the error type MOZILLA_PKIX_ERROR_MITM_DETECTED which should trigger if our hypothesis that this is a MITM case is correct.

Johann can correct me if I'm wrong, but I believe we'll end up with a discrete error page for MOZILLA_PKIX_ERROR_MITM_DETECTED before the end of the year, which hopefully will be more informative for this new tab.

Comment 7

[Johann Hofmann [:johannh]]

At least I hope we do :)

Comment 8

[Jon Buckley [:jbuck]]

From IRC:

<jason> jbuck: not really difficult as long as firefox.com has been verified within digicert, which it probably has been already
<jason> it just costs more

Comment 9

[Ryan Kelly [:rfkelly]]

Thanks!  I spun out a separate bug to follow up on the question of using an EV cert: https://bugzilla.mozilla.org/show_bug.cgi?id=1464734

If there's a bug for the discrete error page for MOZILLA_PKIX_ERROR_MITM_DETECTED, I'd be happy for this bug to be closed a dupe of it.