The CA system we currently have is insecure. Governments try to hack CA’s, hacker try to hack CA’s, Criminals try to hack CA’s basically anyone tries to hack CA’s. So if one of these hackers succeed that person can issue a certificate that is valid for whatever domain he want. No browser or client will ever doubt that certificate as it is issued by a trusted CA. This occurred when a Dutch CA Diginotar was hacked. Hackers used that certificate for gmail and so forth.
In defence for this security issue a RFC was created. Here’s where HKPK (HTTP Public Key Pinning) is introduced. This technique is quite simple. A pin can be generated with a certificate. This pin is always the same with that certificate. You’ll need to have 2 certificates per CN or SAN. So if you have a certificate from let’s say StartSSL for the domain www.example.com you’ll need an additional certificate for www.example.com or let’s say a wildcard certificate for *.example.com. Next you generate a pin for these certificates. You enter the pin into a HTTPS header and your secure.
When a clients connects to your site it saves this pin. Lets say a CA gets hacked and a certificate is generated for your domain. Then that hacker uses your certificate for example in a MITM attack of if it is a government it can alter DNS for your domein. Then the client connect to your site again and the certificate does not match the saved pin. The client browser present you with an error that someone is trying to intercept the traffic and further processing will be stopped.
For now only a maintained list by Google is being used for HKPK. On this list are only large sites like Facebook, Twitter and Google. But soon this RFC will be implemented and available for anyone who uses a SSL certificate. When HKPK is being used a hacker or government will have to burn a CA every time they try to intercept traffic. A very nice result. Yet in the world before HKPK we have more than 1500 certificates.
By the end of 2015 HKPK is already proven to be valuable. Only for google.com Symantec issued a certificate while Google did not request the certificate. Symantec fired those employees. But this must only be the tip of the iceberg. Image how much HKPK can contribute to a safer net. I can only imagine that some government already are deleting certificates
But what if the certificate expires? Well that one is easy. You have two certificates in the header. Than just use the not expired certificate. Request a new certificate generate the new pin. Enter this in the header and remove the old pin. The only thing important here is that you must use a shorter period than the time between the expiration of certificate1 and certificate2.
So how do you make this work? First you’ll need to generate a SHA256 pin. You can do this for an online certificate like this:
Non-SNI
openssl s_client -connect www.bexit.nl:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
SNI
openssl s_client -servername www.bexit.nl -connect www.bexit.nl:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
Or for a certificate by running this command
openssl x509 -in certificate.pem -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
When you’ve generated the pins you can add them to the header by using a string like this:
Header always set Public-Key-Pins 'pin-sha256="hOKXjMHg/QuZ2q6n6Hzp6j+P+217O6Mzd70WJ2LgEBw="; pin-sha256="t3EN6WT7PvqYPL0af/BoG4YAjVucNaIhg+CkT/sDExM="; max-age=15768000'
Be careful not to enter a very long timeframe as you might run in to trouble later on.