902884 - Allow sites with self-signed certificates to set HSTS state

Status: NEW

(Firefox :: Security, defect)

Description

[nodiscc]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:22.0) Gecko/20130328 Firefox/22.0 (Nightly/Aurora)
Build ID: 20130807022136

Steps to reproduce:

I've setup my home server (apache2 on Debian) to send HSTS headers. I can verify that the home page HTTP headers (over HTTPS) contain Strict-Transport-Security:max-age=15768000;includeSubDomains in Firefox developer tools.


Actual results:

When I try connecting over plain HTTP, Firefox still allows me to do so.


Expected results:

Firefox should automatically switch to HTTPS on future connection attempts, disallowing plain HTTP connections.

This is a followup to http://www.reddit.com/r/firefox/comments/1jvo2t/hsts_not_working_on_firefox_22/

Comment 1

[nodiscc]

Additional info: this happens when the certificate is self signed. As I said, enabling HSTS for sites that present a self signed certificate has a major advantage if it's combined with cert pinning.

I was told that this could prevent a client from accessing the server if an attacker MitM'ed th *first* connection and set HSTS headers for a site that doesn't actually allow HTTPS connections. As the HSTS flag would remain set in the browser, all future requests to the real server would time out. I think it's unlikely to happen, but in this eventuality there could be an "always connect to this site using secure connections" checkbox in the first self-signed certificate warning dialog, unchecked by default, and only if the server sends HSTS headers.

Comment 2

[Mark Goodwin [:mgoodwin]]

Ah, are you the redditor I was talking to yesterday?  Thanks for filing the bug anyway.

As I mentioned in my response, I think there are reasons why the default behavior is what it is; we don't want users to get DoS until they clear private data by a malicious MiTM (e.g. coffee shop / airport wifi) causing them to accept a cert for some reason (yes, there are other attacks that can happen in this scenario but we know users do this sometimes).

So I think step 1 here is getting information on what is going wrong to the user. With that in mind, I've filed bug 903006.

Then I think we should add a pref to allow developers to disable the the current behavior (ideally on a per-domain basis).  We should also have a think about whether there's a possible way of allowing this for normal users (I'll talk to some other people to see if work has already been done here).

Comment 3

[Mark Goodwin [:mgoodwin]]

As per your reddit comment, for a 'user feature' version of this; we'd want to allow HSTS *and* pin the cert. Again, I'll talk to some people and find out what the thinking is.

Comment 4

[nodiscc]

Attachment: Mockup of an opt-in HSTS setting

Hi, just had an idea on how this could be implemented, UI-wise. Excuse the half-baked mockup but you should get the idea. There's a checkbox in the "site identity" dropdown/popup box which allows adding the current site to the HSTS-enabled list - it should only display if the user is connected over HTTPS *and* has added an exception. Notice the orange lock icon meaning HTTPS connections are not yet forced - it should turn to grey once the site is in the HSTS list.

Take what you want from this mockup, feedback welcome.

Comment 5

[nodiscc]

Hello, are you willing to reconsider this?

all in all, the self-signed certificate warning is explicit about this: you should have checked that the fingerprint of the received cert matches the one you expect from this server. Clicking "Add an exception" without checking exposes you to MitM attacks, and if a malicious/public wifi router presents a crafted cert and you add an exception, either:

 * The real server does not accept HTTPS connections, in this case you get DoS next time you try to connect over a connection that does not spoof cerificates. The warning dialog, well, warned you. I think this is very unlikely.
 * The real server acccepts HTTPS connections and you will get a "certificate changed" dialog next time you try to access the server over a proper connection. Then at least you know your connection has been MitM'd in the past. You should have checked the cert fingerprint.

I think the benefits outweigh he disadvantages. 95% of the time people just type my server address in the URL bar, hit enter, and connect over a plain insecured connection. If they forget to manually add https:// they'll just keep  browsing that way. This kind of defeats the purpose of HSTS.

Adding a pref to allow HSTS on self-signed certs is another compromise.

Comment 6

[Ralf Hauser]

see also Bug 1092243 and Bug 1119778

Comment 8

[Daniel Veditz [:dveditz]]

The current summary "Allow SITES with self-signed certificates to set HSTS state" is never going to happen, but a similar "Allow USERS to enable HSTS for sites with self-signed certificates" could increase the security for sites that use them.

Comment 9

[Ralf Hauser]

see also bug 1381462