Here's a quick means for inserting HTTP PubkeyPining via a F5 LTM POLICY. This process is very simple and if you have experience with f5 and PKP it quite trivial to setup.
Public-Key-Pins is a header response that's sent to the http-client that list the pubkey hash(es) in the certificate-chain . It suppose to provide protection if a rogue certificate is used or changed on web-server.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
The headers looks similar to the following;
How much of a benefit this header provides is limited and subjective to one's opinion. It can boost the website security rating if one is present.
!!!!!!!!!!!!!!It can also break you if you deploy it wrong or poorly!!!!!!!!!!
1st steps
You need to define sha256 public-key hash. Ideally you will hash the current server-certificate public-key plus one backup-key.
or
Hash the current server-certificate pubkey and one of the intermediate plus one backup
The ideal behind the backup key can follow this simple logic
If the current-certificate is compromise, you use the new private-key to generate a new CSR,
since the new CSR will have the twin of the public-key that's already added to your HTTP PKP header, you can transparently switch out certificates and not impact a end-user that has hash the sha256 PKP
!!!!! protect the backup key it's just as critical as the primary active key !!!!!
To hash an existing certificate you can use any of the following;
Ken recommends SSLLAB
The ssllab "the server check shows the expect hash" in the CA-chain
All certificate chain will have the hash computed , ssllab make it's so easy and requires very little work to hash the current chain
If you want an alternative use the HTTP PKP hash generator located at
https://report-uri.io/home/pkp_hash
It will output all hash for all certificate in the current chain to a output similar to below;
again all parts of the chain certificate at that time, will have the correct sha256 hashes generated !
Okay up to this point your almost done. Now to properly run HTTP PKP , you will need a backup pubkey. So you have to be creative.
You could do any of the following;
1: craft a RSA key { keysize 2048 } and extract the pubkey
2: Generate a new rsa key along with a csr and just hold on to the CSR. Extract the pubkey from the new yet signed CSR
After you have the pubkey for the backup key you will need to convert it to a sha256 hash using openssl, again openssl is good tool for SSL.
And then you can format the header in a format similar to the following;
Now on the F5-LTM it's really easy to apply the HTTP PKP header by using a F5 LTM_POLICY
STEPS:
1: build a named policy
2: match on the expected "Host_Header" for the site to ensure that the PKP header is appended for just that WEBSITE
3: apply the Public-Key-Pin header and ENSURE you set it as a HTTP RESPONSE
responses goes back to the webclient and requests goes to the web-server
when building the header in LTM_POLICY for the pin-sha256 you need to pre-pend "/" before the " marks, the resulting Public-Key-Pins header does not have the "" around the hash it will not pass the checks.
Ensure you apply the new LTM_POLICY after publishing it under the Virtual-Server that supports that website.
Use ssllab or report-uri-io to review headers and read the funny blog on the numerous wrong formats or incorrectly deployed PKP headers, for a laugh ;)
HEADER analyzer
Here's a few errors, if you should get it all wrong;
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
!!!!!set the max-age value to 3600 or less seconds and just for testing if you feel uncomfortable !!!
