Why is tls-sni-01 even used?
All the SNI server has to do to complete the challenge is to repackage the same information it gets from Let’s Encrypt. An attacker can thus have certs issued for any domain that resolves to the machine without actually having access to that machine.
I moved this to a new topic since it didn’t seem to be directly related to the previous one.
Can you describe what your concerns are? What is the role of the attacker in your scenario - are they in a position to effectively intercept/MitM connections from the CA/validation server? That’s a game-over scenario for all validation methods, including dns-01 for domains without DNSSEC. This is true for just about any CA out there.
Some people have called DV certificates “TOFU [Trust On First Use], but scaled for efficiency”. I think that’s pretty accurate and an acceptable trade-off, given that the alternative would likely be to make the validation process too complicated for universal TLS deployment.
I control thebox.com. I set up port 443 to respond to tls-sni-01.
Without my intent, an attacker requests a cert for thebox.com. Because the only response that LE looks for is the same information that’s in the SNI request, my server will fulfill that challenge.
The attacker now has an LE cert for my domain.
The problem is that LE has no way of knowing that it really is my server that you’re talking to. My server is probably only configured to respond to certain SNI requests (à la Apache), but tls-sni-01 builds in no protection against there being a “dummy” SNI server that just parrots back a fresh certificate for any SNI request that it receives.
It would be as though HTTP authz only involved having the web server parrot back the requested filename.
Was this not what prompted the creation of tls-sni-02?
@FGasper: Yep, you’ve identified exactly the issue that led to tls-sni-02 being invented. We’re planning to implement -02 in Boulder soon as part of our move to the latest ACME spec.
Also, MitM isn’t a game-over for, say, normal HTTP DCV because the contents of the returned DCV file are a shared secret between the party that requests the certificate and the CA. The server can only fulfill the HTTP DCV challenge if the requestor can make the HTTP request respond in a way that only the CA and the requestor know. It’s effectively saying, “I want you to prove that you’re ‘@pfg’ by saying that thing we talked about in secret a bit ago.”
That’s not the case with tls-sni-01 because there is no shared secret between the requestor and the CA that isn’t also given to the server as part of the request. It would be as though I said to you, “I want you to prove that you’re @pfg by saying ‘@pfg’ to me.”
That being the case, how is it appropriate to issue tls-sni-01 certificates?
The risk with tls-sni-01 is that someone might choose to implement a validation server that automatically generates certificates based on SNI handshakes and echoes back what it was given. That’s less than ideal, but it’s not a critical vulnerability in the service. Are you aware of a validation server that does that?
A MitM is definitely a game-over scenario. Your threat model implies that only the legitimate server/domain owner would be able to create an account and request a challenge token for a domain. That is not the case - the attacker can do so as well, thus giving them all they need to generate the correct key authorization. This is true for http-01, tls-sni-01/02 and dns-01 without DNSSEC.
The request containing all the information needed to pass the validation is definitely not optimal (hence the existence of tls-sni-02), and it is something that would indeed be problematic for the HTTP challenge because many web servers echo back the request URI (as demonstrated by the recent GoDaddy misissuance), but it’s not something that any TLS servers I’m aware of do by default (or really in any common configuration scenario). The bigger concern - as @jsha mentioned - is the footgun this represents for validation server implementors, who might open themselves up to misissuance. It’s a good improvement, but I don’t think it warrants an immediate depreciation.
@jsha I’m not aware of one, but there is also a MitM problem in that, if I create such a server, then any DNS queries that resolve to my box can produce certs. So basically, tls-sni-01 relies on DNS alone to be correct for authentication. I’m not aware of anything else that treats plain-vanilla DNS that way. (?)
-@pfg An attacker can only create the needed goods for key authz if he/she compromises my access to the machine. Normally that doesn’t just rely on DNS, but also on some shared secret—SSH key, password, etc.-
That's not the case - there's (currently) nothing that permanently binds ACME accounts to DNS identifiers. An attacker can create a new account (independent of whether there's already an existing account under which a certificate for the victim's domain has been issued), request an authorization for the victim's domain, calculate the key authorization and solve the challenge from the MitM position.
I see your point. Something about it still “smells funny”, but I do agree that, in general, an attack on tls-sni-01, like one against http-01, relies on control of both DNS and the response to the query on the box.
Yep, what @pfg said here. To put it another way: all Domain Validation is fundamentally vulnerable to MITM.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.