Using HTTP Public Key Pinning Securely

HTTP Public Key Pinning (HPKP) is a method to secure against man-in-the-middle attacks that are made possible by improperly issued certificates. A prominent attack was the Diginotar case , in which this certificate authority had issued valid certificates for domains such as google.com or www.cia.gov to Iranian hackers. The hacker group was then able to eavesdrop on encrypted connections and thus obtain further sensitive data. The attack from 2011 was noticed because Google had integrated certificate pinning as a new security feature in its Chrome browser shortly before the incident.

With HTTP Public Key Pinning, a browser can be informed via so-called pins which certificates are permissible for securing an encrypted connection. The pins – a fingerprint of the SPKI – are transmitted as HTTP headers in the server's response (cf. Code Example 1 ). Similar to HSTS , this is a TOFU process (Trust On First Use): during the first call of the browser, it does not yet know about any restriction by pins. It establishes an encrypted connection with the server and is then informed that, according to the Public Key Pins, only a selection of certificates is permissible for establishing the encrypted connection. For subsequent connections, the browser will only accept certificates for encrypted connections that match the stored Public Key Pin information. Thus, connections can be protected against attacks such as the Diginotar case described above.

Public-Key-Pins:
  pin-sha256="ygFAna6QwOObKwAP+LJvDLGD2MRxKQTko04tQIPZuJk=";
  pin-sha256="H9peR7D23RgyX47aT8syA8i1iZ3zr4vNiTU659U0nm4=";
  max-age=2592000; 
  report-uri="https://example.com/pkp-report"

Trust Problem of the Public Key Infrastructure Solved

Through HPKP, a website operator is able to explicitly define which certificates are permissible for an encrypted connection. Ignoring the TOFU circumstance, this method solves the trust problem of the Public Key Infrastructure. The browser knows before calling a domain which certificates it may accept. If the server responds with an unknown certificate, the browser rejects the connection. Such a blessing can, of course, quickly become a curse: if a website operator can no longer use any of the previously communicated pins for any reason, browsers will reject other connection attempts. The website can then no longer be used until the pin information expires.

Protection against Self-DoS

In view of such a scenario, several things must be considered and risks weighed against each other. Anyone who pins their own certificates must constantly check the delivered Public-Key-Pins header. One of the two pins must belong to the currently used certificate; the other pin must correspond to the certificate stored offline in a secure place. Likewise, the rolling renewal process of the pins must first be tested and later regularly checked. Fortunately, the mechanism offers the possibility to use a Public-Key-Pins-Report-Only header. With this, the policy is not mandatorily enforced, but violations can be sent to a URL.

Those who want to take less risk can also pin other certificates that are delivered in the certificate chain of the server response. It is possible to pin the intermediate or root certificate of one's certificate provider. This means giving up some control over which certificate may be used. However, this restricts the amount of potentially permissible certificates to those signed by the intermediate or root certificate, and that is still better than the status quo: trusting all certificate authorities .