With Chrome backing away from HTTP Public Key Pinning and other industry thought-leaders calling for its death, I figured I'd take some time to review some existing and upcoming (and tedious) controls that aim to fix some of the many shortcomings within the SSL/HTTPS ecosystem. In so doing I figured I’d summarize some of these concepts into a single blog entry, for anyone else trying to increase their understanding of how these pieces fit together. New standards bring new acronyms and we have a host of them to cover. We'll touch on HPKP, HSTS, CT, Expect-CT, CRL, OCSP Stapling, Expect-Staple, Must-Staple, CAA, CSP, and the Secure Cookie attribute. For this article's purposes I'll refer to SSL interchangeably with TLS.



HTTP Public Key Pinning (HPKP RFC7469)

HPKP is an HTTP response header that allows the pinning of specific certificates to sites. It helps protect users from connecting to attackers who have managed to procure a legitimate site certificate either through private key theft or CA compromise. HPKP literally includes cert public keys within an HTTP response header. Get it wrong and you lock your users' ability to connect to your site for max_age length. HPKP is going away in Chrome 67 and was never adopted by Edge, Safari, and Opera. As such, we’re no longer recommending it.

Outages due to HPKP configuration errors have earned it negative vernacular like "HPKP Footgun" and "HPKP Suicide" after pinning goes awry and users can no longer connect. There is also the threat that HPKP could be used in ransom attacks whereby servers are pinned to attacker’s certs until settlement is reached. To be fair, you probably have other more serious concerns than HPKP ransomware in the event of a fully rooted web server.

The following HPKP policy is pinning a site’s cert, a backup cert, and two intermediary certs. Once a browser receives this policy, the site must present certs representing these pins or the connection will fail and the policy won’t be reevaluated for 60 days (5184000 seconds). This policy includes all subdomains as well as an HPKP reporting URL for browsers to log errors.

Public-Key-Pins: pin-sha256="VfJheHlgui7iM8J1OXgDtTNYNYVvH/cCr1KTBypojkM=";

pin-sha256="8Rw90Ej3Ttt8RRkrg+WYDS9n7IS03bk5bjP/UXPtaY8=";

pin-sha256="xahupZ7DWm9CLCgV5QIfj4hFDujfB8fcfDJz8ywWNZw=";

pin-sha256="grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME="; max-age=5184000; report-uri="https://www.depthsecurity.com/HPKP/reports"; includeSubDomains

HTTP Strict Transport Security (HSTS RFC6797)

HSTS is an HTTP response header that site operators can use to force browsers to connect with TLS even when user/links/hrefs explicitly specify cleartext HTTP://. Remember FireSheep? HSTS contains an obvious weakness in that initial requests from new users will still be in cleartext unless the user explicitly requests HTTPS://. A browser's initial request after max_age expiry is affected by the same weakness. Some browsers (Chrome, Firefox, Opera, Safari, IE 11, and Edge) and VPN services have implemented HSTS preload lists in order to avoid the cleartext initial request problems for new users and users that have had their max_age value expire. You can submit your own HSTS policy to many of these preload lists if you wish to be included.

Another issue is that HSTS supercookies can be used to fingerprint browsers, de-anonymizing them over VPNs and Tor. Using browsers’ HSTS functionality you can store one bit of information per site you control. Imagine you setup N unique FQDNs where N is the bit-length of unique tracking resolution you want. Say N=32, and FQDNs are hsts0.depthsecurity.com, hsts1., hsts2., … hsts31. You also enable HSTS on these sites. On a user’s first visit to the website you're tracking on, generate a random 32-bit number. Convert it to boolean and make users send requests to your FQDNs that represent wherever 1-bits are set. Later, to identify that particular browser (or 1 in 2^32 = 1 in 4,294,967,296) you make it connect to all 32 sites via HTTP://. Each browser is guaranteed to send HTTPS requests to the sites it already connected to (1’s positions) because of the HSTS headers they received earlier. HTTP:// requests are 0s and HTTPS:// requests are 1s. This is called an HSTS super cookie.

The example HSTS policy below instructs browsers to only reference HTTPS:// resources no matter what for that site. Once a browser receives this policy, they will implicitly connect via HTTPS:// for two years (63072000 seconds) before reevaluating the policy. The policy requests that the site be included in any HSTS preload lists that ingest sites with the preload directive.

Strict-Transport-Security: max-age=63072000; preload

Certificate Transparency (CT RFC6962):

The CT project, initiated by Google, aims to increase transparency of certificate issuance. This makes it difficult for CAs to issue a certificate without it being visible to the domain owner. CT also helps prevent users from accidentally communicating to sites using certificates that were fraudulently or accidentally issued. It does so through the concept of logs, monitors, and auditors. Although CT has nothing to do with revocation, it does allow site operators to know when they should revoke certificates.

Anyone can query certificate logs for potentially malicious certs. Monitors are public services that watch log servers for potentially fraudulent certificates. Auditors verify correct log behavior and determine whether a particular certificate appears within a log. Certificates are submitted to CT logs and the logs respond with a signed certificate timestamp (SCT), which is a contract that the certificate will be added to the log in a certain amount of time determined by the maximum merge delay (MMD). The SCT is then delivered to clients during TLS handshakes using one of three methods: an x.509v3 Extension, a TLS Extension, or through OCSP stapling. Chrome will require certificates issued after April 2018 to be logged in CT so make sure your certs support it. Chrome allows you to view SCT information from these three sources via chrome://net-internals/#events.

To correctly implement CT, site operators should perform the following steps in order to avoid service outages:



Ensure your certificate has been submitted to CT logs. Choose one of the three SCT delivery methods and implement it. Implement Expect-CT in report-only mode, without the enforce directive. Review Expect-CT reports and ensure no supported user agents are failing CT. This basically verifies that step 2 was done properly. Implement Expect-CT in enforcement mode using the enforce directive.

Expect-CT is an HTTP response header that adds teeth to CT by allowing site operators to instruct browsers to hard-fail on TLS connections when no valid SCT is presented. Failing to include the enforce directive will make the policy report-only, causing browsers to report CT failures to the report URL specified in the report-uri directive of the site headers. This provides site operators with information about whether the SCT information they are providing satisfies their users’ browsers.

There are two examples below. The first causes browsers to report CT failures to the specified report URL. The second forces browsers to deny TLS connections that fail CT for up to 30 seconds before reevaluating site headers while also reporting CT failures to the specified log URL.

Expect-CT: max-age=0, report-uri="https://www.depthsecurity.com/CT/reportOnly"

Expect-CT: enforce,max-age=30,report-uri="https://www.depthsecurity.com/CT/reports"

OCSP Stapling (RFC 6961)

While CT allows you to know when it's time to revoke a certificate, what is the best way to revoke it? OCSP Stapling, a.k.a TLS Certificate Status Request, allows site operators to bear the cost of providing OCSP status of certificates rather than every client requesting certificate status from the CA. Originally, revocation was handled only by Certificate Revocation Lists (CRLs). These are unwieldy lists of revoked certs published by CAs. They still exist but have huge drawbacks. Then came OCSP, which requires clients to query the CA for each certificate during TLS negotiations in real-time. In practice, OCSP has the following problems:

OCSP queries fail about 15% of the time and take around 350ms on average when they do succeed.

OCSP doesn't work very well in captive portal environments that often block internet access prior to authentication.

An attacker with a MiTM position on the network can prevent OCSP responses from being received.

OCSP requests leak information to CAs about what sites users are visiting and at what times.

Due to some of these issues browsers will typically soft-fail TLS connections when they don’t get a correct OCSP response, defeating the whole purpose of OCSP. Some browsers like Chrome and Firefox don't even do online revocation checks. Adam Langley puts it best: "So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it." In other words, revocation is broken and wide adoption of OCSP stapling can't come soon enough.



With OCSP Stapling, the site operator polls its CA’s OCSP server at regular intervals and includes these signed responses within TLS handshakes. This way the client maintains OCSP validation of certificates without querying the CA every time. This is becoming increasingly implemented in many common browsers and web servers. You can query a site’s stapling status easily using OpenSSL:

openssl s_client -connect depthsecurity.com:443 -status | grep OCSP



OCSP response:

OCSP Response Data:

OCSP Response Status: successful (0x0)



Response Type: Basic OCSP Response

However, as with seemingly everything SSL/TLS-related, there are problems when put into practice. What happens when a server fails to fetch an OCSP response to staple? How should clients treat TLS connections where a staple was requested but does not exist? How should servers fetch or prefetch (before expiration) staples for robust operation (they haven’t always been that great at this)? Due to all of these issues browsers still implement a soft-fail, effectively defeating OCSP stapling. If a staple isn't included by the server during the handshake, browsers will still allow the TLS connection to continue. That’s where OCSP Must-Staple comes in.

Must-Staple, a.k.a. OCSP Stapling Required, is an x509v3 certificate extension that, if present in a certificate, causes supporting browsers to implement a hard-fail approach to OCSP stapling failures. In other words, if a certificate specifies Must-Staple and an OCSP staple is not included during a TLS handshake a browser will fail the connection and display an error to the user.

Expect-Staple is currently an addition to Chrome HSTS preload list functionality that allows site operators to gain visibility into OCSP stapling failures that could manifest themselves in service outages when Must-Staple is used. Must-Staple forces site operators into a binary move from not enforcing OCSP stapling to completely enforcing it. If an OCSP Stapling-enabled application were failing to correctly staple during some percentage of TLS negotiations, its site operators would be none the wiser without Expect-Staple.

Standard HSTS Preload entry:

{ "name": "www.depthsecurity.com", "include_subdomains": true, "mode": "force-https" }



HSTS Preload entry with "Expect-Staple" added:



{ "name": "www.depthsecurity.com", "include_subdomains": true, "mode": "force-https", "expect_staple": true, "expect_staple_report_uri": "https://www.depthsecurity.com/Expect-Staple/reports", "include_subdomains_for_expect_staple": true }

The Chrome HSTS preload list Expect-Staple functionality has drawbacks like being a manual process and taking a while before addition requests land in deployed versions of Chrome. Because of this, there is an Expect-Staple HTTP response header being drafted at the time of this writing. If eventually approved, this will provide an easily-deployable, report-only feature to allow site operators to ascertain their OCSP stapling failures.



Certificate Authority Authorization (RFC6844)

While CT provides visibility into certificates that should be revoked, and OCSP stapling seems to be the only means to meaningfully revoke a certificate, what can we do to stop unwanted certificates from being issued in the first place? CAA is a DNS extension that allows organizations to specify which CAs should be able to issue certificates for their domains.



Enforcement of CAA relies upon the CA, not the browser. The idea is that when an organization requests a certificate from the CA, the CA will check the domain's DNS for a CAA record. If the CA is specified in the CAA record, the certificate will be granted. Otherwise, the CA will report the illegitimate request to the url or email address specified in the CAA record's iodef property. CAA participation by CAs was initially voluntary but is now mandatory as of September of 2017. You can generate your own records and even check your current CAA policy here. For example, the following standard zone file allows only LetsEncrypt to issue certificates for the depthsecurity.com domain, disallows wildcard cert issuance, and specifies a URL for the reporting of CAA violations. Wildcard certs are not allowed.



depthsecurity.com. IN CAA 0 issue "letsencrypt.org" depthsecurity.com. IN CAA 0 issuewild ";" depthsecurity.com. IN CAA 0 iodef "https://www.depthsecurity.com/CAA/ReportOnly"



CSP is an HTTP response header that allows site operators to define constraints on the origins of content such as frames, JS, CSS, fonts, images, and objects. I only mention it because it has HSTS-like behavior in that it can prevent mixed-content and upgrade insecure requests to HTTPS:// when sites define their sources explicitly, i.e. source=https://. The following (overly-simple) CSP policy enforces the loading of all content from https://www.depthsecurity.com:



Content-Security-Policy: default-src https://www.depthsecurity.com

The Secure cookie attribute instructs browsers to only include cookies in secure, "HTTPS://" connections. Any sensitive cookie should have it. The following secure attribute will cause browsers to avoid sending the JSESSIONID cookie out non-HTTPS:// connections:



Set-Cookie: JSESSIONID=AS348AF929FK219CKA9FK3B79870H; secure; path=/

Summary

What follows is an attempt to summarize and explain the previous content:



HTTP Public Key Pinning: HPKP is an HTTP response header allowing the pinning of certificate public keys to web servers.

HTTP Strict Transport Security: HSTS forces browsers to connect with TLS even when user/links/hrefs explicitly specify cleartext HTTP://. Preload Lists: Site operators can request being added to various browsers' preload lists and even add the preload directive for ingestion into these lists. HTTP Response Header: Site operators can use an HTTP response header to set their HSTS policy.

Certificate Transparency: CT provides visibility into when malicious/unwanted certificates are issued for your domain. Logs: Certificates are submitted to a public CT log (usually by the CA), which responds with a Signed Certificate Timestamp (SCT). Monitors: Monitors are public services that watch log servers for potentially fraudulent certificates. Auditors: Auditors verify correct log behavior and determine whether a particular certificate appears within a log. Signed Certificate Timestamp: SCTs are delivered to clients during TLS handshakes using one of three methods: an x.509v3 Extension, TLS Extension, or OCSP stapling. They prove the cert has been added to CT logs. Expect-CT: The Expect-CT HTTP response header can be used to gain visibility into browsers failing CT and to force browsers to hard-fail CT violations.

Revocation: CT might help you become aware that an unwanted/malicious certificate has been issued for your domain. Revocation is then necessary to prevent browsers from allowing connections to these certificates once they're out there. Certificate Revocation Lists: CRLs are unwieldy lists of revoked certs published by CAs. Online Certificate Status Protocol: OCSP requires every browser to query, in real-time, each certificate's CA's OCSP server. OCSP Stapling: OCSP Stapling overcomes OCSP privacy and performance issues by allowing site operators to vouch for the revocation status of their own certificates. Must-Staple: Must-Staple is a certificate extension that allows site operators to instruct browsers to hard-fail TLS connections when OCSP stapling fails. Expect-Staple: Expect-Staple allows site operators to gain visibility into OCSP stapling failures that could manifest themselves in service outages when Must-Staple is used. Chrome Preload List: Expect-Staple is only supported within the Chrome preload list at the time of this writing. HTTP Response Header: A draft implementing Expect-Staple as an HTTP response header is being discussed at the time of this writing.

Certificate Authority Authorization: CAA is a DNS-based means of restricting which CAs can issue certificates for a domain. It aims to prevent the issuance of unwanted/malicious certificates before CT and revocation are even needed.

Content Security Policy: CSP involves a lot more than HTTPS enforcement but it warrants mentioning that site operators can use it to lock down various content origins to HTTPS:// sources.

Secure Cookie Attribute: The secure cookie attribute instructs browsers to avoid sending cookies over unencrypted connections.



