Neutralizing and protecting against rogue TLS certificates in the wild

Techniques for fighting mis-issuance of TLS certificates

The web has reached the tipping point where encrypted traffic – connections protected by HTTPS, which is HTTP over SSL/TLS – has overtaken unencrypted (HTTP) traffic. There are many reasons for this change, variously called HTTPS Everywhere or Always-On SSL, which we described in a previous FYI blog post. While this move certainly improves the security and privacy of interactions on the web, there still remains the Achilles’ heel of this ecosystem – the problem of mis-issuance of cryptographically legitimate certificates to rogue site operators. This blog post describes recent steps taken to guard against such occurrences, using techniques which can raise the necessary alarms before much harm propagates.

The Achilles’ heel of internet security is the mis-issuance of cryptographically legitimate certificates to rogue site operators.

 

The entire edifice of SSL/TLS-based security rests on certificates issued to the legitimate operators of websites, so that browser indicators (the secure lock icon, for example) based on various cryptographic checks can reassure users that they are communicating with their intended destination. Mis-issued certificates, whether available through lax procedures at a certificate authority (CA) or by a malignant act, removes that critical trust. A browser’s cryptographic checks cannot distinguish a duly-vetted legitimate server from a man-in-the-middle that has improperly obtained a cryptographically valid certificate. The latter might arise owing to the (mis)placed trust in a compromised root CA embedded in the browser or one issued by a corrupted intermediate CA that is in a legitimate chain of trusted certificates.  This is, for example, why Google is reducing trust in SSL certificates issued by Symantec and why even Microsoft is the latest and last browser vendor to no longer going to trust anything issued by the WoSign/StartCom certificate authorities.

Some CAs make mistakes and fix them; some have a habit not well controlling certificate issuance.  This seriously damages our trust in a secure internet.

For frictionless security in web interactions, it is just such situations that need to be managed preemptively. Two of the techniques described below, Certificate Authority Authorization (CAA) and Certificate Transparency (CT), attempt to address the problem starting at the certificate pre-issuance stage. The other two, HTTP Public Key Pinning (HPKP) and HTTP Strict Transport Security (HSTS), follow a trust-on-first-use-but-verify-afterwards principle. Used together or separately, these techniques can go a long way towards regaining that trust in the TLS/SSL ecosystem that is often eroded by news of cyber security breaches involving rogue certificates.

TLS Certificate Authority Authorization

Certificate Authority Authorization (CAA) offers a risk reduction step for legitimate domain owners to maintain a degree of control over which Certificate Authorities (CAs) can issue certificates attesting to the ownership of their domains (or sub-domains thereof). This is especially useful for owners of popular domains which are often the target of rogue site operators. As described in an Internet standards-track document, RFC 6844, a domain owner adds a DNS record, the DNS CAA record, identifying one or more CAs. These are then the only ones that can issue certificates for the domain.

The DNS CAA record can be granular, allowing a domain owner to restrict the certificate issuance to the parent domain or any sub-domain thereof. It also requires a CAA record check of the domain that is a CNAME for the original domain. There are important nuances, such as the order of looking for the CAA record from the highest level downwards and stopping when the first record is found; thus, this higher level record overrides any choices lower down the domain name hierarchy.

The process is that a CA, when requested to issue a certificate for a particular domain, must validate that the requesting customer has control over the domain. (This is the basic first step for issuing all certificate types). Next, it would check the domain’s DNS CAA record to see if it is on the list of approved CAs. If there is no CAA record or if the CA’s name is present, then it may issue the certificate (assuming other steps needed by the type of certificate requested also complete successfully).

CAA offers an automated check by which the domain owner proactively identifies the issuers for its certificates. If the CA is on the white list, it may consider itself authorized to issue a certificate. When CAA is fully deployed, rogue domain owners cannot go CA-shopping in search of a CA whose certificate issuance policies might be lax enough to issue it a cryptographically legitimate certificate.

Use of CAA allows you to restrict issues of certificates for your domains(s) to be by only your trusted certificate authority.

The list of DNS providers that support CAA is growing. Starting September 2017, support of CAA will be a mandatory baseline requirement defined by the CA/Browser Forum (CABF) for all CAs when issuing certificates. There are bound to be teething troubles as CAA is more widely deployed, but operational and technical issues are being identified and resolved.

TLS Certificate Transparency

We provided an overview of Certificate Transparency (CT) in our earlier post; so we will confine our description here to the most relevant points.

CT is a way to make domain owners aware of certificates issued in their name. A CA populates at least one CT log[1] with details about each certificate requested. Domain owners can directly check CT logs (which should be publicly accessible) or use third party monitors to check such logs for certificates requested for their domain.

Each certificate entered into a CT log contains a token, called a Signed Certificate Timestamp (SCT), which the issuing CA embeds or “staples” to an issued certificate. When a browser receives a certificate from a visited domain as a part of the secure session setup, it can verify from a valid SCT that the certificate request was properly logged by the CA. This check will provide it with added reassurance that the CA took steps to make domain owners aware of the issuance of the certificate. If there are no (or a certain minimum number of) SCT(s), the browser should not accept the certificate, or at least warn the user that the server is not trusted via the appropriate visual warnings.

One expects owners of popular sites, particularly those targeted by rogue site operators, to be particularly scrupulous in monitoring CA logs to ensure early take-down of mis-issued certificates.

CT logs are already in operation, and this pre-issuance step to log every certificate issuance request for all certificate types is slated to become a mandatory baseline requirement of the CA/Browser Forum (CABF) in April 2018.

HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP) is another Internet standards-track document, RFC 7469, which tackles the certificate mis-issuance problem from a different angle. It does not prevent a CA from issuing a certificate for a site. However, it allows the domain owner to constrain the CAs whose certificates can be used for its site to those that it indicates (“pins”) to the browser[2]. In essence, with lots of technical details omitted, the site operator identifies a set of public keys in its site certificate’s chain of trust that it provides to the browser (using a HTTP response header) in the first interaction. It expects the browser to verify and honor (for a specified period of time, previously indicated) this choice when presented with a certificate in future visits. The net result is that the server, after the first interaction, tells the browser to remember the “fingerprints” (i.e., the public key(s)) that it should expect when subsequently interacting with this server.

The idea is that a mis-issued certificate with a (cryptographically) perfectly valid chain of trust will not be accepted if some or all the stored (“pinned”) public keys are not included. Take for example a site certificate’s chain of trust, such as A (root CA) -> B (intermediate CA) -> C (the example site). The site owner can chose to “pin” the browser to the public key[3] for C, and/or B, and/or A. If C is “pinned”, which is the strictest constraint, no certificate will be accepted that does not include the public keys for C, B and A. If pinned to B, certificates issued by B to other entities can be accepted, which might leave the site open to impersonation attacks if B is compromised. Pinning just the trust anchor, such as A, leaves the site wide open to just the sort of attack that this technique is supposed to guard against because any and all certificates descended from this root CA can be considered legitimate[4]. There are many other caveats for the proper ways to pin, but it would be too detailed for an introductory post such as this.

A few important features include the following:

• Each pin is accompanied by a maximum age field specifying the time the pinned public key should be remembered by the browser. Setting this value is an art, as too short a value renders its protection useless, while too long a value means that any change in the server’s certificate in the interim makes the site unavailable for a browser until its stored pins’ timers expire.
• There must be at least one pin, called a backup pin, where the public key isn’t in the site certificate’s chain of trust.  This helps against recovery in case the pinned public key cannot be used for any reason. The site continues by serving the backup certificate validated by the backup pin.
• An includeSubdomains field indicates that the policy extends to subdomains under the current one.

Key pinning is fraught with dangers for the unwary, and its operational complexity requires much care and should not to be undertaken lightly. It is not surprising that only a few web sites have implemented this powerful technique and its support by major browsers remains incomplete.

HTTP Strict Transport Security

As we noted earlier, web sites are rapidly converting to HTTPS. However, their sites can often also be accessed via plain HTTP. A HTTP connection occurs if the user types the site’s URL into the address bar without an explicit protocol prefix (http://… or https://…). That’s because the default browser behavior is to choose http://….. . This is also possible when a user clicks on an “old” link which is still http://… , obtained from a saved bookmark, say, or an email.

To divert the browser away from the legacy unsecured site to the new HTTPS-based address, site operators typically redirect the browser using a HTTP 3XX response code including a redirect URL to the secure site. However, this redirection has been used as the ideal point for hijacking the connection by a man-in-the-middle. HTTP Strict Transport Security (HSTS) – defined in IETF RFC 6797, another Internet Standards track document – offers an alternative way for the site operator to inform the browser that it has accessed a site via HTTP that all subsequent interactions with that server should use HTTPS.

It does so using a HTTP response header field, Strict-Transport-Security, in the first HTTP interaction with a site which informs the browser that conforms to HSTS that the next connection to this domain must use HTTPS. A max-age parameter indicates the period of time when this policy applies, while another parameter indicates whether this policy should also hold for subdomains.

Of course, using a secure channel is only possible in subsequent interactions, leaving a slim chance that the first interaction will be insecure and thus susceptible to hijacking. To close even this door, browser vendors, led by Chrome, have created the HSTS Preload option where domains can pre-register to have their domains included in a list hardwired into browsers, so that a HTTP request for any listed domain is automatically converted into HTTPS[5]. Thus, most popular and commercially important web sites are automatically accessed using HTTPS. HSTS is or on the path to be supported by all major browsers.

TLS-enabled sites hosted by LuxSci offer one-click HSTS support – if requested by the client, LuxSci will publish the appropriate HSTS headers. Our clients have to register their sites by themselves if they wish to be included in a HSTS preload list.

Conclusions

The implicit acknowledgement behind all these techniques is that the best laid plans for web security will always be circumvented by the determined attacker, and the most one can do is to minimize the attack surfaces, or, at least, provide an early warning. None of these techniques offer a complete solution for the problem of mis-issued certificates, but when widely deployed, singly or together, they add to the arsenal of weapons that protect legitimately secured web sites.

 

Notes

[1] Techniques are defined to ensure that logs remain tamper proof and their contents consistent.

[2] It is the public key in the certificate that is pinned, not the certificate itself.

[3] Strictly speaking, this is a SHA-256 hash of the public key. We slide over such details for simplicity.

[4] There are instances of corrupt root certificates installed in browsers.

[5] The reader can type luxsci.com in the browser address bar and immediately see it converted to https://luxsci.com. That’s because luxsci.com is on the preloaded HSTS list of all major browsers.