Flaw in Let’s Encrypt Procedure
Let’s Encrypt will be revoking up to 3 million of the TLS certificates it had issued. This drastic action is in response to a bug discovered in the validation procedures, which was acknowledged on Feb 29th on their official blog. The flaw was fixed the same day it was discovered. It could have allowed a client to receive a TLS certificate covering multiple domains, but with only one of the domain’s ‘CAA record’ being checked/validated.
Here is the official statement about the flaw from the Let’s Encrypt’s blog:
When a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.
Potential Security Implication:
While this seems to be a major breakdown of security protocol, the reality is that there’s only a small chance this could have been exploited in a real-world scenario. First, the scope of this bug is only relating to CAA validation. CAA (Certificate Authority Authorization) is basically a record that companies can add to their DNS which states “The following CAs are allowed to issue certificates for our domain: GoDaddy, Verisign, etc.)
This record is entirely optional, and the vast majority of domains don’t have a CAA record defined. Up until 2017 it was also completely optional for CAs to even check this record. So at the worst, the certificates issued are no less secure that the ones prior to CAs implementing CAA verification.
Further, Let’s Encrypt was performing the first CAA check properly for all domains. This check is valid for 30 days; but if the certificates were not issued immediately, a second check is made to ensure all domains STILL validate. This second check had the flaw when multiple domains were being requested.
So, the only potential exploitation would be if an attacker HAD owned a domain name at one point and had made a request for a Let’s Encrypt including that domain, but then later lost or transferred ownership to another party (who took ‘Let’s Encrypt’ out of the CAA record), and then still continued the issuing process to receive the certificate. They would still need to validate that they control the domain.
According to their blog post, only 445 certificates of the 3 million even had a corresponding CAA record in DNS which didn’t include Let’s Encrypt. These have all been revoked already.
It’s vital to note that this vulnerability has nothing to do with the required domain ownership checks. These ensure a domain is owned by the requester (including HTTP-01 and DNS-01 challenges described here). These validations were still in place the whole time and do not have any known vulnerabilities.
Effect of the Revocations
Those 3 million websites and servers relying on Let’s Encrypt for their public TLS certificates need to request and install a new certificate. Otherwise, website visitors will receive a certificate warning by their browsers indicating that the site is not secure. The warning will indicate that the certificate has been revoked. If the TLS certificate is being used for an SMTP server for secure (TLS) email, it could even prevent other mail servers from relaying emails to the server if the other server requires a valid certificate.
The procedures put in place by Certificate Authorities are vital to maintain the public’s trust in the certificates they issue, and the internet in general. CAs must follow very strict guidelines when it comes to issuing certificates, which are outlined by various bodies such as the CA/Browser Forum.
In circumstances like this, it’s imperative to take immediate action to maintain the trust in the CA and the process in general. But it’s also important to understand the scope of the vulnerability before jumping to conclusions. Let’s Encrypt took a balanced approach. They revoked the certificates that could have been affected by this flaw (based on CAA record). But they also gave administrators additional time for all the other certificates issued while the flaw was present.