A Valentine’s Day Warning for Let’s Encrypt TLS-SNI Users
A Valentine’s Day Warning for Let’s Encrypt TLS-SNI Users
Many organizations need to use free certificate authorities. If your business doesn’t have a budget for a paid CA, it’s certainly better to deliver your website or web app through HTTPS with the help of Let’s Encrypt than to use the plaintext web through HTTP. Recent versions of popular web browsers on both desktop and mobile such as Mozilla Firefox and Google Chrome have started to warn web surfers that HTTP sites are “not secure.”
I imagine that has probably convinced many organizations which previously avoided HTTPS because they didn’t want to pay for TLS certificates to sign up with Let’s Encrypt so that their users wouldn’t be dissuaded to visit their websites with a web browser-delivered warning. Also, Google has acknowledged that HTTP web pages are now being ranked lower in their search engine than HTTPS web pages, so many new Let’s Encrypt customers probably have search engine optimization in mind as well.
If your organization uses Let’s Encrypt as a CA, there’s an important deadline coming up very, very soon. On February 13, 2019, Let’s Encrypt will disable support for TLS-SNI-01 domain validation. Especially if you use multiple subdomains on the web, such as blueberry.website.com, strawberry.website.com, www.website.com, web.website.com, this will probably affect you. If you don’t change how your TLS certificates are configured, you’ll find that your HTTPS-delivered web content will no longer be properly accessible to your users. And there are significant security concerns as well.
Unfortunately, last year it was brought to the attention of Let’s Encrypt that they had a vulnerability pertaining to their deployment of Server Name Indication, specifically TLS-SNI-01 and TLS-SNI-02. Server Name Indication makes it possible for multiple certificates to be used with the same IP address and TCP port number. That’s especially necessary for web domains which use multiple subdomains. SNI is an extension to the TLS networking protocol which enables the hostnames that a web client is trying to connect to during the handshake process to be validated. But the vulnerability that was discovered in how Let’s Encrypt deploys SNI enables a cyber attacker to acquire TLS certificates for domains that they don’t own. That makes a certain type of man-in-the-middle attack possible, because a certificate is a machine identity that acts as a key to unlock TLS encryption.
When you administrate a web server, it’s pretty easy to create new subdomains to your domain name. Let’s say that there’s an online shoe retailer and their domain name is choosyshoes.co.uk. A year ago, the store had an online promotion where if a customer buys a pair of shoes, they get to choose a second pair of shoes at or below the retail price of the first pair for free. So https://bogo.choosyshoes.co.uk was deployed to make a dedicated website for the promotion. It’s the kind of thing online businesses do all of the time. The buy-one-get-one promotion ended a while ago, and Choosy Shoes stopped delivering content at the bogo.choosyshoes.co.uk subdomain. Choosy Shoes still uses a CA to deploy TLS certificates for www.choosyshoes.co.uk and some other subdomains of theirs.
An external cyber attacker sets up a legitimate account with the same web hosting provider that Choosy Shoes uses. Choosy Shoes’ web administrator forgot about the bogo.choosyshoes.co.uk subdomain, which had been abandoned months ago. Exploiting the vulnerability in how Let’s Encrypt implements SNI, the cyber attack could add their own HTTPS web server for bogo.choosyshoes.co.uk, use the same CA that Choosy Shoes uses, Let’s Encrypt, and impersonate the shop online.
Let’s Encrypt decided to mitigate the vulnerability by disabling SNI for new accounts but allowing previously existing accounts to continue to use SNI... for the time being.
Now the time’s almost up. On February 13th, 2019, Let’s Encrypt will disable SNI completely. They suggest TLS extensions DNS-01 and HTTP-01 as an alternative for the name validation needed to deploy multiple certificates for one IP address.
Whether or not your organization uses Let’s Encrypt as a CA, this incident should serve as a useful warning. Effective network cryptography requires full visibility into all of the machine identities that your organization uses. Do you have any abandoned or orphaned subdomains? What about main domains? Are there any addresses which point to network resources that you have which lack necessary machine identities or have improperly configured machine identities? Don’t wait until spring for this sort of spring cleaning, full machine identity visibility should be acquired as soon as possible.
Related posts
Like this blog? We think you will love this.
About the author
Guest Blogger: Kim Crawley
Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.
Read Posts by Author
