By
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
Lorem ipsum dolor sit amet, consectetur elit.
Thank you for subscription
Scroll to the bottom to accept
VENAFI CLOUD SERVICE
*** IMPORTANT ***
PLEASE READ CAREFULLY BEFORE CONTINUING WITH REGISTRATION AND/OR ACTIVATION OF THE VENAFI CLOUD SERVICE (“SERVICE”).
This is a legal agreement between the end user (“You”) and Venafi, Inc. ("Venafi" or “our”). BY ACCEPTING THIS AGREEMENT, EITHER BY CLICKING A BOX INDICATING YOUR ACCEPTANCE AND/OR ACTIVATING AND USING THE VENAFI CLOUD SERVICE FOR WHICH YOU HAVE REGISTERED, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY AND ITS AFFILIATES TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY AND ITS AFFILIATES. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICE.
You shall not access the Service if You are Our competitor or if you are acting as a representative or agent of a competitor, except with Our prior written consent. In addition, You shall not access the Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, and you shall not perform security vulnerability assessments or penetration tests without the express written consent of Venafi.
This Agreement was last updated on April 12, 2017. It is effective between You and Venafi as of the date of Your accepting this Agreement.
The Venafi Cloud Service includes two separate services that are operated by Venafi as software as a service, each of which is separately licensed pursuant to the terms and conditions of this Agreement and each of which is considered a Service under this Agreement: the Venafi Cloud Risk Assessment Service or the Venafi Cloud for DevOps Service. Your right to use either Service is dependent on the Service for which You have registered with Venafi to use.
This License is effective until terminated as set forth herein or the License Term expires and is not otherwise renewed by the parties. Venafi may terminate this Agreement and/or the License at any time with or without written notice to You if You fail to comply with any term or condition of this Agreement or if Venafi ceases to make the Service available to end users. You may terminate this Agreement at any time on written notice to Venafi. Upon any termination or expiration of this Agreement or the License, You agree to cease all use of the Service if the License is not otherwise renewed or reinstated. Upon termination, Venafi may also enforce any rights provided by law. The provisions of this Agreement that protect the proprietary rights of Venafi will continue in force after termination.
This Agreement shall be governed by, and any arbitration hereunder shall apply, the laws of the State of Utah, excluding (a) its conflicts of laws principles; (b) the United Nations Convention on Contracts for the International Sale of Goods; (c) the 1974 Convention on the Limitation Period in the International Sale of Goods; and (d) the Protocol amending the 1974 Convention, done at Vienna April 11, 1980.
In the meantime, please explore more of our solutions
In the meantime, please explore more of our solutions
This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly. Find out more on how we use cookies.