What is BetterTLS?

BetterTLS is a test suite for HTTPS clients implementing verification of the Name Constraints certificate extension. This extension is placed on CA certificates which restrict the DNS/IP space for which the CA (or sub-CAs) can issue certificates. One of the most common use-cases is for CAs to cross-certify another CA, but for a limited namespace. For example, Acme Corp. could sign a certificate for an intermediary CA but include a Name Constraints extension which blacklists the intermediate CA from signing certificates for acme.com.

Another use-case for the Name Constraints extension (which motivated this project) is as a way to reduce the risk exposure of trusting an internal CA. For example, we could create an internal CA which includes a Name Constraints extension with a whitelist of internal.example.com and 192.168.0.0/16. A user who imports this CA into her browser's truststore can then be confident that this certificate will only be used for internal company pages and IPs and cannot be used to intercept secure communications with external websites.

However, the Name Constraints extension only provides these assurances if we can be confident that HTTPS clients properly enforce them...

Why BetterTLS?

In order to verify that the Name Constraints extension protects users from mis-issued certificates, we developed this test suite. As we did so, it became apparent that there are many different implementations of the certificate verification algorithm, each of which has corner cases that are not properly handled. Check out the archived results tab for examples of HTTPS clients with failing tests.

These are some examples of incorrect behavior we have observed:

If a hostname is in the common name (CN) of the subject instead of the subject alternate name (SAN) extension, it may not be checked against the Name Constraints extension at all even when it is used as the hostname for verification.
Although RFCs suggest that only hostnames should appear in the common name (CN) of a certificate, many clients will still accept an IP address in the CN. However, these implementations do not always apply IP Name Constraints against the CN.
Some implementations show a certificate as valid when one subject name matches a Name Constraint blacklist but a second subject name does not. (The RFC specification makes it clear that validation should fail if any subject name is blacklisted.)

Although this test suite certainly isn't exhaustive, the hope is that it provides a reference for developers to use in order to help verify that Name Constraints extensions are properly enforced in their TLS implementation.

Why "BetterTLS"?

This project is inspired in part by badssl.com. In a similar vein, we want to highlight some of the issues we've found with HTTPS/TLS implementations so that they can be corrected. By doing so, we hope to make TLS better for everyone.

Name Constraints Documentation

The Name Constraints extension along with its verification is defined in RFC 5280. Further useful information can be found in RFC 6125 which defines how to identify a server's hostname from certificate extensions.

Testing Clients

Browsers can be tested by visiting the test browser tab on this website. Non-browser clients (such as Java and Python) can also be easily tested against the BetterTLS test suite. Check out the testsuites folder of the BetterTLS source repository for examples on how to do so.

Contribute