expect-ct http header
expect-ct http header
The header that will eventually replace HPKP is called Expect-CT. Even though HPKP was a useful security feature, it by far wasn’t the only way to detect certificates issued by rogue CAs or to prevent them from doing so. With security mechanisms such as Certificate Authority Authorization (CAA) and Certificate Transparency, we can still be notified of certificates issued on behalf of us without our permission or knowledge and in some cases even prevent CAs from issuing these certificates altogether.
But how would these protections work and can they really replace HPKP?
Certificate Transparency Logs
The answer is Certificate Transparency (CT). That’s the reason why the security header we are going to talk about is called ‘Expect-CT’ (in other words ‘Expect the certificate to be submitted to a Certificate Transparency Log’).
These Certificate Transparency Logs are publicly accessible and therefore administrators can check them and search for their own domains. If there is a certificate issued for their domain without their prior knowledge or authorization, they can immediately take steps to protect their users.
Of course CAs aren’t motivated to add more complexity to the already heavily regulated process of signing certificates. This is why Google, as the developer of one of the most popular browsers, had to put its foot down and make the CT log mandatory for new certificates issued from April 2018.
How CT Logs Work
Let’s have a quick look at the Certificate Transparency log mechanism. CAs, by design, have to submit each issued certificate to this log. There are three parts that need to come together in order for CT to work:
- Submission of the certificates to logs, which is the task of CAs
- Monitoring the logs
- Auditing, which is done by built-in auditors in browsers
In addition, it is advised that site owners add the Expect-CT header to their responses. Browsers decide whether or not the certificates presented to them follow the outlined rules or not. Along with the certificate, browsers check the Signed Certificate Timestamp (SCT). This data contains the timestamp of when the certificate was logged. The browser uses the SCT information to check if the outlined conditions are met.
Where is the Risk?
If we have a certificate issued for our website before the obligatory start date of April 2018 in Google Chrome, and the expiration date is set 10 years ahead, Google cannot enforce the certificate transparency rules. Otherwise, this would result in a large amount of perfectly valid certificates that are no longer usable, even if they were issued before CT was invented. Since HPKP is deprecated in Chrome, there would be no way of being notified of an illegally issued certificate for our website.
However, if we set and enforce the Expect-CT header and use max-age to cache this directive in the browser for a while, during the connection to our website, certificates that do not meet the CT requirements will not be accepted even if they are signed before April 2018. This way, we eliminate the risk of older certificates being determined to be valid without our knowledge.
How Do We Implement the Expect-CT Header?
First we have to make sure that our current certificate supports CT. We can do so by generating an SSL Labs report:
Next we can activate the Expect-CT header in the HTTP response by using a header as below:
The Expect-CT header has three directives:
- max-age: This is the duration (in seconds) of the data being stored in the browser cache.
- report-uri: This is the URL to which the breach report will be sent. It must be an absolute URL (e.g. https://example.com/report) not a relative one (e.g. /report).
- enforce: This indicates whether the connection should be established, if a certificate that doesn’t comply with CT is present.
You can also use this in report-only mode which doesn’t initially enforce the CT requirement.
If everything is as expected, you can then choose to enforce.
