8

What are my options for disabling HSTS both for new sites and for those sites baked into the browser?

The use of HTTPS inspection inherently changes the thumbprint of a site by acting as a man in the middle; visiting a site previously visited without HTTPS inspection or one of the preloaded sites will result in an inaccessible site. What options - if any - do I have other then disabling inspection?

Here is an example, Gmail in Chrome with HTTPS inspection:

Main Details

Background

I am setting up a new firewall and I'm trying to clean my HTTPS inspection rules. I really want to avoid adding sites to the list that may have user contributed content, such as mail.google.com / gmail.com.

Since the last time I did this HSTS / HTTP Strict Transport Security has become a lot more prevalent.

Note - I tried to keep this generic since this could be an issue for a lot of different setups. I'm hoping for a cross OS / cross browser method that would be applicable to any firewall product but that is asking a bit much. A focus on (IE, Chrome, Firefox) using Windows (7+) would be a great start. Methods centered on Group Policy would also be very useful.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Tim Brigham
  • 15,545
  • 10
  • 75
  • 115
  • 3
    I'm having a really hard time understanding this. Is this actually meant to solve some problem? If so, what? – Michael Hampton Aug 12 '14 at 16:28
  • @MichaelHampton fair enough. Think I made it a bit too generic. I need to make sites available without disabling HTTPS inspection. – Tim Brigham Aug 12 '14 at 17:11
  • @MichaelHampton, For testing SSL stuff basically. http://security.stackexchange.com/q/102279/2379 . Or for allowing a proxy to do recording (e.g. JMeter). It doesn't matter if the setting is insanely obscure (such that the average user will never be able to blindly click-through to it), but there **needs** to be a way to do this. – Pacerier Nov 06 '15 at 09:38

1 Answers1

6

You're conflating a few different things here, and I suspect it's leading you to some false conclusions.

  • HSTS ("HTTP Strict Transport Security") is (only!) about mandating that HTTPS is used for connections to specified sites. It doesn't enforce anything about which keys, certs, etc are used to authenticate the connection.
  • Public Key Pinning specifies that, if a HTTPS connection is established to a given name, that the certificate chain must include one of a given whitelist of public keys, else the connection is considered invalid.

Since HTTPS inspection is (unfortunately) a widely-deployed practice, the general practice amongst browsers is that certificate chains which end in a locally-installed root CA certificate are exempted from public key pinning checks. I've found a statement from Chrome's Adam Langley on Chrome's behaviour (the section "What about MITM proxies, Fiddler etc?"), but my experience is similar for other browsers.

I'm fairly confident that the problem indicated in your screenshot isn't that the browser is getting hung up on a pin, but rather that it is failing to recognise the certificate as chaining to a trusted CA certificate at all. That will trigger a HSTS failure, because "using HTTPS" is more correctly specified as "using properly-secured HTTPS including secure ciphers and a trusted certificate for authentication". I would suggest double-checking that the MitM proxy's root CA certificate is installed correctly and recognised as valid by the browser(s) in use.

womble
  • 96,255
  • 29
  • 175
  • 230