4 ms·
I may be naive, but it seems like it might be more secure if the first step was to deploy a self-signed cert on the server, step 2, give Let's Encrypt the publi
by Rebles 7y ago
I may be naive, but it seems like it might be more secure if the first step was to deploy a self-signed cert on the server, step 2, give Let's Encrypt the public key of the self signed cert, so Let's Encrypt can validate who you are, then proceed with Let's Encrypt's regular validation process, obviously replacing your self-signed cert with the one issued by Let's Encrypt at the end.
- smw 7y agoWouldn't an attacker be able to create a self-singed cert just as easily?
- tialaramex 7y agoSelf-signed. Yes, an attacker would not ordinarily find this harder to pass than the http-01 challenge today. Validation using this approach was method 3.2.2.4.9 ("Test Certificate") and is no longer permitted for new issuance under current Baseline Requirements. Let's Encrypt offers three ACME methods which implement 3.2.2.4.6 ("Agreed Upon Change to Website"), 3.2.2.4.7 ("DNS Change") and 3.2.2.4.10 ("TLS Using a Random Number").
- movedx 7y ago> 3.2.2.4.9 > Baseline Requirements Where can I find these details? Sorry if I'm being a bit dense here.
- tialaramex 7y agoThe CA/Browser Forum publishes the Baseline Requirements to their web site https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ In recent years the BRs are using RFC 3647 structure. This RFC gives an outline for how to write policy documents for PKIX (X.509 Public Key Infrastructure for the Internet) and rather than wrestle with each organisation having its own preferred way to organise much the same information the trend is to require RFC 3647, so you know the stuff about names will be in section 3 for example The RFC 3647 structure doesn't break down as far as 3.2.2.4 but 3.2.2 is where people explain how they're going to validate organisation names, and so in the Baseline Requirements 3.2.2.4 is where the "Ten Blessed Methods" are described, the authorised means by which public CAs can determine if the name you want a certificate for is really yours.
- movedx 7y agoThanks for sharing that, friend. Appreciated.
- mittalprat 7y agoIndeed, the self-signed cert idea doesn't work in this context.
- kardos 7y agoSounds like the TLS-SNI-01 challenge that had a fatal flaw in some circumstances: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...
- tialaramex 7y agoThe problem with tls-sni-01 is that it assumed nobody would be crazy enough to let you configure their HTTP-only web server to answer HTTPS requests for their names. So logically if a server answers HTTPS requests for a name, on an IP address that DNS says is the right address for that name, that must be the right server, no? But it turns out cheap bulk hosting sites, especially using Apache HTTPD often did this because it worked fine by default. The symptom for ordinary users would be you try to visit https://cat-videos.example/ https://cat-videos.example/ and it gives a certificate error saying the site has a certificate only for aaa-microwave-repairs.example do you want to continue? If you say "Yes" you get an error page. Eventually you remember it was http://cat-videos.example/ http://cat-videos.example/ no need for the 's' and that works. Weird but ultimately harmless. What has happened is the Microwave repairs people paid for working HTTPS, with a valid certificate for their name, the Cat Video people didn't bother. But both set the bulk hosting site as the correct IP address for their servers. Now, when you connect to that IP address and ask for cat-videos.example using SNI, the remote server should go "Er, no?" and you just get an error. But Apache's default behaviour instead figures you want the default web site and default certificate, which will typically be alphabetically first on that server. This destroys the security assumptions for tls-sni-01, because "it's safe unless people use cheap bulk hosting" is essentially identical to "it's not safe" and getting Apache to fix things was too late. Bad guys could sign up for a bulk host used by their target for non-TLS sites, and add a bogus site named like aaaaaaa.bad-guys.example and use this to attack the target with tls-sni-01 challenges. So, the replacement ACME challenge doesn't rely on SNI it uses ALPN instead. Also some people actually tested to check that Apache isn't also dumb enough to go "Um, I don't recognise this ALPN, I guess that means I should press on anyway and cause breakage" which fortunately it is not.
- drcongo 7y ago
- foota 7y agoWait... How does letsencrypt know who is giving them the public key cert?
- contravariant 7y agoPresumably they can then confirm that the public key matches the certificate that's currently on the webpage. Unless someone successfully preforms a MITM attack on letsencrypt but then all bets are off.
- bawolff 7y agoGiven that this article is about mitigating the risk of someone doing precisely that, i don't think "all bets are off" is a good position to take on that scenario. To summarize TFA: lets encrypt is now verifying domain ownership from multiple data centers. The idea being if someone tries to mitm the verification process (through bgp hijacking or whatever) its much harder to do that across the entire internet and go unnoticed then it is to do it on just one network path