If the IP space of the target server lies within the control of the bad actor, they could easily respond to a challenge they initiated and serve the resulting, issued certificate, along with whatever content they want. This is no different than many similar hijacks for "abandoned" subdomains. The moral of this story: don't point your domain name at an IP address controlled by bad actors.
4 Likes
“What prevents a state actor with access to your IP from issuing false Lets Encrypt certificates?“
Also there is a difference between being issued a certificate and actually utilizing it (such as a man-in-the-middle attack). Utilizing the issued certificate still requires the associated private key and operating on the domain name the certificate is issued for.
Thus if you have a valid certificate and the government has a bad actor (valid) certificate, so if you were to publish your valid certificate on your website, for all to see, the end user can check that that’s the certificate being used for their connection, if not a bad actor is intercepting the communications.
2 Likes
One way that this can be prevented... is:
When both sides are encrypting with their own private key, and they publish their public certs at an alternate location/method.
[think PGP on steroids]
2 Likes
The MiTM could replace that content with theirs - LOL
Thus:
3 Likes
True. Publish in your DNS also as TXT record.
3 Likes
Yes!
Now you're thinking outside-that-box!
2 Likes
But the concept I threw out there is still a PIA.
Edit
Also the basic concept isn’t mine, see:
https://www.grc.com/fingerprints.htm
3 Likes
It can be hard to distinguish (from a technical perspective) a "bad" government taking over a domain (through getting the TLD servers to change their NS records, or getting control over the IP routing, or whatnot), from a "good" government that has an appropriate court order and/or warrant or the like to stop an illegal-and-generally-agreed-to-be-doing-bad-things domain.
That's the whole thing about domain-validated certificates, is that they only prove control over the domain, and doesn't prove that the entity which controls the domain is the entity that a user actually wants to communicate with.
If one wants to protect against an attacker who has access to arbitrarily intercept IP traffic, but not the ability to update or sign TLD NS records, then DNSSEC-securing the domain and having a CAA record that limits to only DNS validation I think would be sufficient to stop them getting a certificate, as long as the CAs in browser trust stores are in fact following the rules and aren't under attacker influence themselves (or having a vulnerability that an attacker can exploit), though of course the attacker could still intercept the traffic and prevent any legitimate use of the domain entirely.
Monitoring Certificate Transparency logs can be helpful for detecting issues too, though only after the fact.
7 Likes
I think that @petercooperjr's comment here is a solid last word on this topic.
The only thing I'll add is that you can also use CAA to limit issuance to just your ACME account using the accounturi= parameter. So even if it's somehow infeasible for you to conduct DNS-01 challenges, you can still create a single set-and-forget DNSSEC-protected CAA record that will prevent a third-party actor from successfully completing any kind of challenge for that domain.
Also, all of the discussion above about how third-party actors might acquire a certificate for a domain you think they don't control applies to all CAs, not just Let's Encrypt. And in some cases, applies to other CAs more than Let's Encrypt, since not all CAs respect the CAA validationmethods and accounturi parameters.
7 Likes
since not all CAs respect the CAA validationmethods and accounturi parameters.
Other CAs don't have to respect those specific parameters, as long as they respect the CA identifier (or whatever it's called). No CA besides LetsEncrypt should issue certificates if the CAA record is "letsencrypt.org".
1 Like
ITYM: if the only CAA record is letsencrypt.org.
You can have more than one CAA to allow issuance by multiple CAs.
4 Likes
If anyone can divert the HTTP requests to your IP, then they can obtain a certificate from whichever CA is listed in the CAA record [via HTTP-01 authentication].
To prevent that, you could...
Run a script that:
- unlocks the CAA record [replacing it with a single CA]
- immediately obtain a cert from that [unlocked] CA
- then relocks the CAA record
(replacing the record to something with no possible match, like: "EMPTY-SET-ENTRY")
4 Likes
To fill in the details of what @mcpherrinm @aarongable and @petercooperjr noted:
- The CAA record can limit Certificates to specific CAs
- Certain CAs will respect an Account bind in the record, so only a specific Account can be used to provision a Certificate
- DNSSEC can be helpful, but it is not something that can be relied upon. While LetsEncrypt always verifies DNSSEC, not all CAs do so (see Lets Encrypt and DNSSEC verification - #5 by mcpherrinm). DNSSEC also has outages.
Combining (i) DNSSEC and (ii) CAA records with account-binding will successfully address the OP's concern with a limited number of CAs - including LetsEncrypt - when the state doesn't control the TLD (or DNS Servers). LetsEncrypt supports the RFC extensions and implements the CA/B Forum Baseline Requirements in a manner that supports this goal, but not all CA's do. Because this type of safeguarding hinges on newer extensions and protocols, there isn't a universal or "machine-only" approach to the solution. A Subscriber must ensure the CA of their choice is compatible with these goals, and their DNS Servers + TLD are also immune to compromise by state actors.
Last year there was a somewhat notorious story of this type of attack happening in Germany. TLDR, it is believed that DNS was modified by court order to allow a LetsEncrypt certificate to be issued and that certificate was used in MitM wiretapping for several months:
5 Likes
Interesting discussion! Fun fact, in some (fully developed, democratic, "first world") countries, not naming any in particular, the gov can covertly force a business to MITM their own infrastructure (i.e. zero effort on their [gov] part) and the penalty for not doing so is prison, same penalty if they ask you to do it and you then reveal that they asked you to do it. They can most definitely take control of passwords, private keys etc.
If your government decides to control your business (or your CA) for their own purposes, every other privacy/security point is moot and your only remaining choice may be to adopt a different country. You can expect to be somewhat protected by common law, but you may want to check the fine print.
Within the tech community we can sometimes be a little naive about the world around us and try to reduce absolutely everything to technological solutions and how it should (in our imagined version of society) be done, but all we can usually do is follow best practices so we're not making it too easy for adversaries. I'm now sounding like a conspiracy theorist and in my next gripping essay will be expounding on the flatness of the earth.
5 Likes
Adding onto this, there is growing concern that "Warrant Canaries" may not be legal and companies are instructed not to remove them. (See Warrant canary - Wikipedia for an overview)
This is why monitoring CT Logs is an important part of any solution to this problem.
5 Likes
Now that you mention it I recall reading about the Jabber incident as well. The articles mention that the attack could have been mitigated by using CAA records with account restrictions. They also mention how they could coerce a different CA into issuing a certificate, but this would risk the CA's reputation and risk it being blocked by browser and OS vendors, and governments probably know this.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.