Certificate Authorization (CA) compromises, like the infamous DigiNotar case in 2011, have demonstrated how real the risks of man-in-the-middle (MITM) and other attacks are.
In the years since the incident, a number of new security features have been added to Transport Layer Security (TLS), HTTPS, and the web Public Key Infrastructure (PKI). These features aim to make the CA system auditable, prevent MITM attacks, and/or prevent illegitimate certificate issuances.
In a paper we recently presented at the ACM Internet Measurement Conference 2017, we analysed how these different security extensions are used in the Internet.
Our analysis suggests a correlation between configuration effort, the incurred risk to site availability, and actual deployment status. Easy to deploy technologies that also have little risk to availability, consistently show the highest deployment. In contrast, technologies with either high deployment effort or high risk (in terms of misconfiguration and accidental downtime) tend to have a lower deployment.
In this post, I will discuss some of the more widely used HTTPS security extensions and how they improve HTTPS security for users.
HTTP Strict Transport Security (HSTS)
HSTS is a special HTTP header that instructs a browser to only access a domain via HTTPS in the future. An example looks like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This example instructs browsers to only use HTTPS to connect to this domain as well as all subdomains of this domain for the next year.
HSTS also requires that the domain has a valid certificate. Browsers will refuse unencrypted connections, as well as connections that provide invalid certificates (such as self-signed certificates).
In our research, we found HSTS to be used in 3.5% of the 300 million domains we scanned. About 80% of domains that use HSTS use a max-age value that is greater than 6 months, indicating confidence among operators that they can sustain TLS support. Under this assumption, HSTS comes with very little risk to site availability, that is, you cannot accidentally lock visitors out.
HSTS should not be confused with HTTP Public Key Pinning (HPKP), a different HTTP header that allows domains to specify that only certain CAs or public keys may be used for a domain. In contrast to HSTS, HPKP carries a much higher risk if the configuration is not precise, that is, domain owners can make their domain unavailable by accident (for example, if they specify a wrong public key).
We see very little use of HPKP: only 0.02% of domains we scanned use it. Shortly after the publication of our paper, Google also announced that Chrome will no longer support HPKP — this header will likely soon vanish.
Certificate Transparency (CT)
CT is an effort that aims to make unnoticed attacks on the PKI near impossible. The key idea is the public disclosure of issued certificates and an infrastructure of logs, auditors, and monitors.
CT has proven its worth recently when it uncovered the improper issuance of certificates by a number of CAs, including Symantec (who recently sold off their CA business).
In CT, users or CAs submit certificates to semi-trusted public logs run by independent parties. Browsers can verify that a certificate has been logged by CT by validating a data structure that is typically embedded in the certificate. This makes CT very accessible to domain owners as they do not have to take any steps to enable it.
Google Chrome currently enforces CT for Extended Validation certificates. The extended validation indicator is only displayed if Chrome can validate that the certificate is logged in CT. Google plans to mandate CT for all newly issued certificates starting April 2018.
Due to its easy accessibility for domain owners, we find a relatively high deployment of CT: we saw it being used on more than 10% of domains. In our passive measurements, we saw CT being used in about 30% of connections. This is due to popular sites with CT being accessed very often, extending the benefits of CT to a large user base.
You can check the inclusion status of your certificate at crt.sh
Certification Authority Authorization (CAA)
CAA is a DNS-based system that lets a domain owner indicate which CAs may issue certificates for the domain. In contrast to other methods, the CAA record is only checked by the CA during certificate issuance; it is not checked by browsers. A CAA record that only allows the Let’s Encrypt CA to issue certificates for example.com would look like this:
example.com. CAA 0 issue "letsencrypt.org"
The CAA measurements for this publication occurred in April 2017, when CAA was not effective yet: CAA was voted into effect by the CA/B forum on 8 September 2017. We hence consider the low deployment of ~3,000 domains observed in April 2017 as interest by users to adopt CAA even before coming into effect. We also consider CAA a low risk to domain name owners, which might encourage future adoption. This suspicion is supported by our continued measurements of CAA, which show about 113,000 domains using it as of December 2017.
If you want to use CAA on your domain, we recommend using the record generator at https://sslmate.com/caa/
Enable security extensions (if you haven’t done so already)
Our primary finding is a strong correlation between deployment numbers and usability (ease of use) and low risk of all these new technologies.
If you operate a domain with TLS and have a recent certificate, especially an Extended Validation one, you are probably already using CT. You can check this by searching for your certificate at https://crt.sh.
We recommend to enable HSTS for any domain you own — as long as you thoroughly consider whether to include subdomains or not, there is practically no risk. If you have a preferred CA, you should use CAA to reduce the number of CAs an attacker can potentially trick into mis-issuing a certificate.
This article as well as the research paper were authored by Johanna Amann (ICSI), Oliver Gasser (TU Munich), Quirin Scheitle (TU Munich), Lexi Brent (University of Sydney), Georg Carle (TU Munich), and Ralph Holz (University of Sydney).
Johanna Amann is a senior researcher at the International Computer
Science Institute, an independent non-profit research institute affiliated with the University of California, Berkeley.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.