Tuesday, October 24, 2017

building HTTP PKP header for insert thru a f5 LTM_POLICY

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.

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.


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


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
     ^      ^
=(  @  @ )=
        /  \

No comments:

Post a Comment