Limiting the risks of SSL certificate mis-issuance

The entire HTTPS ecosystem is based on trust. At the very top of this trust chain there are the certificate authorities.

Certificate authorities play a fundamental role in HTTPS, and have an enormous responsibility. Certificate authorities are responsibile for verifying the authenticity of the entity requesting an SSL certificate, vetting the request, and issuing the SSL certificate that will make it possible to switch to an encrypted, trusted, and authenticated connection for a website.

The implications and consequences should a certificate authority ever be compromised are extremely dangerous.

What's wrong with SSL?

One of the main sources of risk in the current SSL certificate issuance system is that certificate authorities are allowed to issue SSL certificates for virtually any entity. It doesn't matter that if for the last 10 years you've purchased SSL certificates from AwesomeAuthority Inc. Any other SSL certificate authority, including Less Awesome Ltd can technically issue SSL certificates on your behalf for your domains.

This has happened in the past. Several times: here, here, and here, wait here, no here, etc. In most cases, mis-issued certificates were the result of attacks against specific SSL certificate authorities, in other cases fake certificates were issued intentionally to bypass certain technical problems.

Easy to understand, popular domains are generally the target of the majority of certificate mis-issuance. It happened to Google several times, in 2011 and more recently in 2015 when employees of a popular certificate authority issued, without authorization, SSL certificates for the domain *.google.com.

Perhaps one of the most famous incidents in CA history was the one that involved Diginotar, that eventually led to the CA being distrusted by all major browsers and root programs. A more recent issue is the one involving two popular CAs (WoSign and StartCom) that were eventually distrusted due to a number of technical and management failures.

Unfortunately, the list of CA incidents and attacks against the PKI system is quite long. If you are interested to learn more, I definitely encourage you to buy the amazing book Bulletproof SSL and TLS by Ivan Ristić, which dedicates an entire chapter to some of the most relevant attacks.

The eye of the Root programs

Fortunately for us, mis-issuances and CA vulnerabilities are taken very seriously by most popular CAs, as well all root certificate program representatives. Becoming a CA is a very long and complicated process which requires applying and complying with all root program rules. For instance, here's the Mozilla CA Certificate Policy.

In the recent situation of WoSign and StartCom, Mozilla conducted an extremely comprehensive audit of the CA violations, that eventually led to the removal of the CA root certificates from the Mozilla root store, as well from Google, Apple, and all other browsers and operating systems.

Root program maintainers have a key role in preserving the security of the SSL ecosystem. However, investigations take time. An effective attack generally happens in an extremely short time-frame, and the initial impact may not be immediately actionable by root programs.

Limiting the risks of SSL certificate mis-issuance

At this point, as a website owner, you may be interested to know what the solutions to protect yourself from SSL certificate mis-issuance are.

Here I want to discuss 3 possible measures to limit this risk. It's important to understand that none of them are a comprehensive or definitive solution. In fact, each of them has a caveat which you should keep in mind.

The 3 counter-measures are:

• Certificate Transparency (CT) logs monitoring
• use of DNS Certification Authority Authorization (CAA) record
• use of HTTP Public Key Pinning (HPKP) headers

Let's take a look at each of these points.

Certificate Transparency logs monitoring

Certificate Transparency (CT) is a project that was created to monitor and detect fake, forged or mis-issued SSL certificates. The idea is simple: each time a certificate authority issues an SSL certificate, the authority should log the issuance in a CT log along with the details of the public SSL certificate.

Logs can then be monitored for suspicious certificates. For example, monitors can tell if an illegitimate or unauthorized certificate has been issued for a specific domain, and they can watch for certificates that have unusual certificate extensions or strange permissions.

There are also several tools online you can use to query CT logs. My favourites are crt.sh and censys.io.

For instance, here's the list of SSL certificates issued for the name dnsimple.com, and here are the details of our current SSL certificate.

Some companies also offer SSL certificate monitoring as a product. For example, the monitoring product from DigiCert, a popular certificate authority.

Pros:

• Simple way to audit SSL certificate issuance
• You can programmatically detect mis-issued certificates
• You can be notified in case of mis-issuance

Cons:

• CT relies on the CA capability to send issued certificate to a CT log
• No default notification, it requires you to monitor CT logs or subscribe to a third party service

In conclusion, CT monitoring is a simple way to audit SSL certificate issuance. However, CT logging is mandatory only for EV certificates, therefore it's up to each CA to log a new certificate. Most popular CAs these days send their logs to a CT server. The CA/B forum is also in discussion about making CT logs mandatory.

Moreover, Google has announced that Google Chrome will require Certificate Transparency from October 2017. This means that if your certificate was purchased from a CA that doesn't log issuance in a CT server, it will be rejected by Google Chrome.

Use of CAA record

A Certification Authority Authorization (CAA) record is used to specify which certificate authorities (CAs) are allowed to issue certificates for a domain. The purpose of the CAA record is to allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain.

DNSimple announced the support for the CAA record at the beginning of 2017. As such, you can now create CAA records to control the issuance of your certificates for domains hosted with DNSimple.

Pros:

• You as a domain owner are in control of the configuration
• Allowlist-based approach, for granular control
• Automatically applied to subdomains
• You can specify a report email where CAs can send violation reports

Cons:

• Limited support from DNS providers
• Partial (and volunteer-based) support from CA

In conclusion, the CAA record is a very simple DNS-based configuration that allows to domain owners to grant the authorization to issue SSL certificates. Unfortunately, as with the CT logs, CA are currently not forced to implement CAA record support. Therefore, if a compromised CA doesn't properly implement CAA support, the mis-issuance will still happen.

The CA/B forum is currently discussing the possibility of making CAA support mandatory for all CAs. Should the proposal be approved, each CA will be required to obey to CAA records if present. A failure to obey may lead to the distrust of the CA in root programs.

Use of HTTP Public Key Pinning header

Public key pinning is a security feature which tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of forged certificates.

In other words, the web site owner can expose, using a proper HTTP header, a list of authorized public or private keys for a specific web page (or domain). If the client should receive an SSL certificate from the server that doesn't match any entry in the list, the client should mark the request as invalid.

As with the CAA record, this is another example of partially delegating to the domain owner the ability to explicitly authorize certain SSL certificates. The HPKP header contains several possible configurations. First and foremost, you need to specify the list of public or private keys you want to authorize. You can then specify if the authorization should be applied also to the subdomains, and you can also provide an URI where validation failures can be reported. You can then use services like report-uri.io to collect and monitor violation reports.

Pros:

• You as a domain owner are in control of the configuration
• Allowlist-based approach, for granular control
• You can specify a report URI where clients can send violation reports
• Widely adopted support by most of web browsers
• Easy HTTP-based deployment

Cons:

• Limited support from non web-browser HTTP clients
• Volunteer-based support from clients
• Possible misconfigurations may effectively cause a denial of service to your domain
• Requires some technical knowledge to properly generate the header

In conclusion, the public key pinning (HKPI) is a good approach to protect your users, who are accessing your website with a browser, from a MITM attack and/or forged certificates. It only requires configuring an HTTP header, therefore there are not specific deployment challenges. However, the proper generation and maintenance of the header requires some careful planning, as an incorrect configuration may effectively kick out your visitors for a very long time (even years!) and cause a self-denial of service.

Conclusion

As we have seen, mis-issued certificates represent a significant risk for your users. Unfortunately, there is no bullet-proof solution. However there are at least 3 good practices you can combine together to reduce the risk of mis-issued SSL certificates and limit the impact of forged SSL certificates.

2016 represented the year of HTTPS, where HTTPS became dominant over HTTP. It's likely that HTTPS will continue to be a dominant topic in 2017 with the introduction of TLS 1.3 and the various security-related initiatives proposed by browsers and CAs to improve the SSL eco-system.

At DNSimple we do our best to stay on top of new features, as we demonstrated with the deployment of the CAA record, integration with Let's Encrypt to offer free SSL certificates, and the release of activity monitoring to audit your account activity. We also have other new security features planned for 2017, stay tuned! In the meanwhile, if there is any feature you'd like us to implement, don't hesitate to let us know.

Share on Twitter and Facebook

Simone Carletti

Italian software developer, a PADI scuba instructor and a former professional sommelier. I make awesome code and troll Anthony for fun and profit.