4

I'm currently setting up a pfSense firewall in my lab. It supports SSL Inception which works pretty well for most sites.

But there are some sites which use HTTP Public Key Pinning to prevent MitM attacks and this is a real pain because the systems behind the firewall have not just been setup and have pinned public keys in some cases which then breaks SSL for those sites.

One way to get around this is disabling HPKP which is possible in firefox by setting security.cert_pinning.enforcement_level to 0 and it works well. Is there another way to get around this problem?

// The host I tried this on was a Kali machine with the Iceweasel browser.

The Error that was shown to me said the connection was droppen because of HSTS which was of cause very confusing because there were also websites that are using HSTS and the interception worked just fine. I then figured out that this seemingly has to do with HPKP and after disabling it the HSTS errors didn't show up anymore.

This seems to be a software specific issue. After @Steffen Ullrich Pointed out to me that this should not be happening I tried it with a Windows 7 Client and Chrome as a browser and it worked just fine.

davidb
  • 4,285
  • 3
  • 19
  • 31

3 Answers3

6

In case of legal SSL interception the proxy CA which is used to issue the certificates for the intercepted connections gets explicitly imported into the browser/OS as trusted. In such a case browser will ignore both the builtin pinning and also the pinning done with HPKP header. This is explicitly done this way to make legal SSL interception (in firewalls, for security reasons) possible. Which means there is no need to disable public key pinning in such cases.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I did import the CA Certificate in the browser. This is why it worked on the most websites in the first place but it did not work on the sites with HPKP anyway. The firewall is running on pfsense and the CA Certificate is generated by this box too and as such not signed by any trusted CA. Might this make the difference? – davidb Jul 06 '16 at 05:45
  • @davidb: that's strange. Which browser+version/OS do you use and do you have the problem with both builtin pinning (i.e. google.com) and explicit pinning (HPKP header)? And no, these proxy CA do not need to be issued by a public CA since you trust them explicitly by importing them into the browser. – Steffen Ullrich Jul 06 '16 at 06:03
  • I'm using Kali Linux with iceweasel as a browser. Im having a problem with explicit HPKP. – davidb Jul 06 '16 at 08:48
  • @davidb: public CAs are not permitted to issue certificates for SSL Interception products, for good reasons. – Lie Ryan Jul 06 '16 at 11:37
  • @davidb: what is the exact method you use to add your root certificate to the browser? It's possible the way you added the Root Certificate causes the browser to not flag the certificate as user installed. – Lie Ryan Jul 06 '16 at 11:45
  • @davidb: I've tried with Kali and it worked for me as I've expected. It even issues the helpful information to browser console that it ignored the HPKP header: _Public-Key-Pins: The certificate used by the site was not issued by a certificate in the default root certificate store. To prevent accidental breakage, the specified header was ignored._ – Steffen Ullrich Jul 06 '16 at 20:10
  • I added some information to the question... maybe this gets it straight. – davidb Jul 06 '16 at 22:00
  • @davidb: unfortunately the information do not help to reproduce your problem. I've actually checked various sites with the latest Iceweasel in Kali Linux (with both explicit and implicit HPKP) and got no errors. Thus the problem might be caused by your specific version of Iceweasel, the way you've imported the CA, the CA properties or the specific target site or a specific non-default configuration of Iceweasel. But all of these are unknown information. – Steffen Ullrich Jul 07 '16 at 05:12
1

Is there another way to get around this problem?

Yes, you can configure your SSL interception tool to delete any HPKP headers in responses.

You'll need all users to start with a dedicated browser profile, that's only ever used under SSL interception. If the same browser profile is ever used without SSL interception, the real server may pin their Certificate again and cause issues when the user reenable SSL interception.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
0

As far as I understand HTTP Public Key Pinning and Certificate Pinning one of their main goals is to prevent MITM attacks.

So you would prove these technique wrong if you could break it without disabling.

aventurin
  • 226
  • 1
  • 2
  • 7