Let's Encrypt Flaw Allowed Hackers to Hijack Certificates - Maritime Cyber Alliance
Welcome
About
News
Anonymous Reporting
Tools
MCA Chatter
Library
V-ID Terminal
Support
My Account

News

Icon representing US Coast Guard Bulletin: Cyber Adversaries Targeting Commercial Vessels
US Coast Guard Bulletin: Cyber Adversaries Targeting Commercial Vessels

June 21st 2019
Icon representing Would you pay $1m for a laptop full of malware?
Would you pay $1m for a laptop full of malware?

May 23rd 2019
Icon representing Singapore Opens Maritime Cybersecurity Operations Centre (MSOC)
Singapore Opens Maritime Cybersecurity Operations Centre (MSOC)

May 22nd 2019
 
 
 

Let's Encrypt Flaw Allowed Hackers to Hijack Certificates

 
January 15th 2018
The organization behind Let’s Encrypt has moved quickly to fix a vulnerability which could have allowed attackers to obtain certificates for domains they did not own.

The Certificate Authority (CA), which hands out free SSL and TLS certificates to make the internet a safer place, was notified of the bug last week by Detectify researcher Frans Rosén.

The problem was identified in the ACME protocol’s TLS-SNI-01 challenge process.

During that process, the ACME server validates a domain name by generating a random token and communicating it to the ACME client. That client then creates a self-signed certificate with a specific, invalid hostname and configures the web server on the domain to be validated to serve that certificate.

“The ACME server then looks up the domain name’s IP address, initiates a TLS connection, and sends the specific .acme.invalid hostname in the SNI extension,” explained ISRG executive director, Josh Aas. “If the response is a self-signed certificate containing that hostname, the ACME client is considered to be in control of the domain name, and will be allowed to issue certificates for it.”

However, Rosén noticed that in at least two large hosting firms, multiple users were hosted on the same address, and some users had the ability to upload certificates for arbitrary names without proving domain control.

These two properties violate the assumptions behind TLS-SNI and together could enable an attack.

For its part, the Internet Security Research Group (ISRG) disabled TLS-SNI-01 as soon as it was informed of the vulnerability.

The most recent update from Aas had the following:

“We have decided to re-enable the TLS-SNI-01 challenge for certain major providers who are known not to have issues while we investigate re-enabling TLS-SNI-01 in general. We’re doing this as a safe way to restore service faster for a large number of sites.”

Hari Nair, director of cryptographic research at Venafi, argued that the issue stems from weak security practices at some hosting providers.

“Let’s Encrypt has mitigated the damage to a certain extent, but ultimately, how effective those steps will be depends on how well hosting providers implement certificate security on their end,” he added.

“It’s possible that there could be a spate of revocations in response to this event. The reality is that detection of mis-issued certificates is extremely hard and checking for revocation status is not something that the industry has traditionally done well, so it’s not clear how much impact revocations will have.”

In the meantime, organizations must stay vigilant to the possibility of mis-issued or maliciously issued certificates, although Google’s move to require Certificate Transparency for all certificates, including DV certs, will help surface these kind of issues sooner, he concluded.

Source


Keywords