3 ms·
This is not specifically a vulnerability in TLS-SNI-01 - more like a major misconfiguration by the shared hosting provider, to share ACME secrets. I guess TLS-
by mappu 9y ago
This is not specifically a vulnerability in TLS-SNI-01 - more like a major misconfiguration by the shared hosting provider, to share ACME secrets.
I guess TLS-SNI-01 does share part of the blame for making this possible in the first place.
It would be great if TLS-SNI-01 could be salvaged, for all the binaries out there - but i don't think a blacklist is a great long-term solution. How about a strict one IP = one domain lockdown until you can prove that you don't share challenges? i.e. negative responses.
EDIT: See reply
- rgbrenner 9y agoI disagree. It's a fatal flaw in TLS-SNI-01/02. Here's why: All of the information required to solve the challenge is in the attackers control. SAN-A and SAN-B (in v02) are known by the attacker. And no action or information from the target domain is required to solve the challenge. Every shared hosting provider and CDN that lets you pick a domain and upload a custom certificate can be used to solve the challenge. Your solution of restricting it to ip = one domain just reduces the vulnerable sites to sites that don't use LE and are on a shared provider. (Also note, if the provider does not implement LE.. then they are vulnerable to this attack against all of the customers.. with your solution: 1 customer for each IP owned by the service) As long as SNI is part of the TLS standard, it is incorrect to assume IP = domain ownership.
- mappu 9y agoYou're right. Thanks for clarifying.