March 13, 2016 · security http ssl https

HPKP as another security layer

Using HTTP Public Key Pinning for SuperDuper ™ security

Happily, HTTP Strict Transport Security is very nice thing for trust-on-first-use sites. But there are one thing that haunts me sometimes - hacked CA. Sure, that's quite rare thing, but who knows.
So, some iranian guy's want to do some MIM. They hacked some CA, issue fake (but valid) ssl certificates and ... the end. Or not?

Nope, if HPKP is used and it's TOFU web site.
The idea is pretty simple:
when UA makes first trusted (I hope) connection to server - it receives HPKP header(s) and store certifiates SPKI fingerprints, ttl, and other validation options for that domain. Then, in all further connections UA will check certificate for identity (whole validation process descirbed in rfc7469.

HPKP headers looks like this:

Public-Key-Pins: max-age=2592000;  

max-age - ttl for storing headers and fingerprints
pin-sha256 - SPKI fingerprints (sha256 is only supported for now) for at least two certificates
report-uri - uri for send POST request in case of failed validation (optional)
includeSubDomains - include subdomains to pinned connections (optional)

Ok, it's a game time

Let's create Subject Public Key Info fingerprints for (detailed about SPKI - here)
Easiest way is to create it from server certificate using openssl:

openssl s_client -servername -connect | openssl x509 -pubkey -noout | oubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64  

Here it is

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3  
verify return:1  
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1  
verify return:1  
depth=0 CN =  
verify return:1  
writing RSA key  

Now, it's time to add this key in headers and set ttl for pinning. But before doing this, we need another SPKI fingerprint for bad situation when original key was compromized. Due to rfc in headers must be at least two pin's. So, for correct pinning we need at least two private keys and certificates: original and back-up (preferable from another CA). Sure, no-one can forbid us to put some garbage in back-up pin(s), just for testing purposes.

About max-age

There are no limits for max-age, but UA's may set own limits. Guys from google recommends somethig around 60 days:

There is probably no ideal upper limit to the max-age directive that would satisfy all use cases. However, a value on the order of 60 days (5,184,000 seconds) may be considered a balance between the two competing security concerns.

About report-uri

Very cool feature as for me. UA will make POST request with useful info to specified uri when valid pinned connection can't be established. The little problem: only Chrome >=46 (and Chromium I suppose) can do this for now.

Sample HPKP-report from Chrome:

{ host: '',
  connection: 'close',
  'content-length': '8710',
  pragma: 'no-cache',
  'cache-control': 'no-cache',
  'user-agent': 'Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36',
  'accept-encoding': 'gzip, deflate',
  'accept-language': 'en-US,en;q=0.8' }
#payload (certifiates was truncated)
-----END CERTIFICATE-----\n",
-----END CERTIFICATE-----\n"
"-----BEGIN CERTIFICATE-----\n  
-----END CERTIFICATE-----\n",
"-----BEGIN CERTIFICATE-----\n  
-----END CERTIFICATE-----\n",
"-----BEGIN CERTIFICATE-----\n  
-----END CERTIFICATE-----\n"

served-certificate-chain - is exactly certificate chain received from server.
validated-certificate-chain - is what UA trying to verify after first fail. Usually - the same as served-certificate-chain + Root CA certificate from UA.

Ok, so let's setup a proper header using SPKI fingerprints and recommended max-age:


Check it:

curl -I ""  
HTTP/1.1 200 OK  
Public-Key-Pins: pin-sha256="TCKhYNyE/2K3N+Latb1KNH/iXqLDjmAkZhCHzN5N20c="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; report-uri="";  
Date: Mon, 14 Mar 2016 00:23:29 GMT  
Connection: keep-alive

Seems ok.

How to test?
Testing pinned connections is not trivial for now. The are some ways to verify HPKP status: in Firefox "Network" tab -> "Security": "Public Key Pinning", also HPKP Analyser is good tool.

For actually testing HPKP we need to replace pinned certificate to other valid certificate but not pinned. Just changing fingerpints doen't have any action coz UA can't update HPKP headers due certificate and fingerprint conflict and will keep old headers unchanged.

Ok, let's put not pinned certificate on this blog

Chrome reaction:

Firefox reaction:

The cool thing - there no "proceed anyway" button, which in very good for security.

So, HPKP & HSTS is not ideal but can greatly reduce MIM attacks.

Further reading:
HPKP Analyser

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket
Comments powered by Disqus