HTTP Public Key Pinning Header with ISAM and WebSEAL

HTTP Public Key Pinning is a header that allows you to pin a certificate to a host, consider it the next step after HSTS ISAM for Web & Sending Security HTTP Headers the solution isn’t any different to send the header with WebSEAL.

The HTTP Public-Key-Pins response header associates a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. If one or several keys are pinned and none of them are used by the server, the browser will not accept the response as legitimate, and will not display it

To make use of this with ISAM simply add a line to the webseal configuration file, under the [rsp-header-names] stanza. (Note you will almost certainly want to consider the other headers in the post mentioned above before you get to this header.)

 

[rsp-header-names]

#
# This stanza is used to define static HTTP headers which will be added
# to every HTTP response from the WebSEAL server. This will provide the
# administrator with the ability to insert some standard security headers
# into the response, such as strict-transport-security,
# content-security-policy and x-frame-options.
#
# Please note that the headers which are defined in this stanza will replace
# any matching headers which might have been added to the response by a
# junctioned application.
#
# If multiple headers of the same name are specified in this stanza all
# but the last of the matching entries will be ignored.
#
# The format of each entry in this stanza is:
# <header-name> = <header-value>
#
# For example,
# strict-transport-security = max-age=31536000; includeSubDomains
#
# A special <header-value> of '%SESSION_EXPIRY%' can be used to
# designate a header which will contain the remaining length of time, in
# seconds, before the current local session expires. This value does not
# include the overall session timeout for sessions which are managed by
# the distributed session cache (DSC), but just the length of time before
# the session expires in the local cache.
#
# For example:
# session-timeout = %SESSION_EXPIRY%
#

Public-Key-Pins = pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubDomains; report-uri="https://www.example.org/hpkp-report"

It will be up to you to manage this header yourself, since you are typically using a secondary/backup certificate as well, that you should be keeping well away from your production system.

 

To do this with your certificates, you can follow the steps for creating the base64 output from the mozilla dev site here:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

Before you implement HPKP you might want to look at the pros and cons, this blog post from Qualys has some interesting reasoning:

https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead