As far as I know you validate the domain only by accessing the site via HTTP. As explained in a talk on BlackHat it’s theoretically possible to get certificate for a domain you don’t control with bad BGP routing.
Can Let’s Encrypt somehow mitigate this attack?
I mean as of what I’ve read on the website the nonce is at first signed, so this is secure as I think.
But what’s the verification with a DNS record, which is - according to
the site - also offered as a verification possibility? As far as DNSSEC
is not used this is not secure.
Email verification (like what StartSSL does) seems the simplest way.
I think the DNS record verification means you create a DNS record that
it then checks. Implying again, that you control the domain in question. No
doubt you could argue that this is also open to attack via DNS cache poisoning or something…
Maybe something involving signed GPG keys could also be used?
Yes some kind of signing is probably the only way to prevent this attack.
However a simple email verification is no problem if you can manipulate BGP routing. So you can just deliver webmaster@example.com to your own mail server - or - as mails are commonly unencrypted it’s only needed to intercept it (in StartSSL you get just a few numbers/letters send you have to enter later).
If I understand correctly how Let’s Encrypt works from the very basic “how it works” info, there are currently two approaches to zero touch “domain validation” certificates:
E-mail verification, as used by just about every other service
TCP connection based, which seems unique to letsencrypt
The first works by sending a token or a link to a mailbox that seems to be at least a bit related to $DOMAINNAME and the second works by making a TCP connection to the server currently reachable as $DOMAINNAME to exchange tokens.
E-Mail verification has many technical attack vectors in approximate reverse order of ease: BGP Hijack, DNS spoofing, mailserver hack, individual mailbox credential theft, desktop compromise, exploit config mistake/bad data in DNS, exploit bad/old data (e-mail address) in whois, snarf e-mail data in transit or at rest on an insecure endpoint, etc etc. Lets not even get started on social engineering.
The letsencrypt approach principally shares only the first two: BGP Hijack & DNS spoofing. Letsencrypt seems to have lots of smart folks involved and there are many of things that can be done if you want to harden the connection from the point of view of one or two authentication servers to make these attacks less successful.
I haven’t dug into their technology, and there may be public papers on how this is secured, but off the top of my head stuff like running a custom recursive DNS lookup algorithm, obviously enforcing DNSSEC where it exists, and implementing DNS recursion very conservatively, for example making fresh authoritative queries as you recurse rather than using cached values (& maybe comparing against cached values at one or two major external recursive services to detect the probability of short term spoofing).
There is also plenty of stuff that can be done to harden BGP from the perspective of one or two discrete endpoints where your auth servers live to take a more conservative view on whether the AS path you are using to reach a network at this instant is possibly hijacked (from the baseline like use only connectivity providers that perform path filtering against databases, to more fun stuff like monitoring your routing table to build up an AS path history and detect short term changes and injection of more specifics, for extra fun do this validation at multiple places on the Interwebs via diverse providers etc etc).
I recon this probably has (& certainly can) be made a heck of a lot more secure than the e-mail auth style certificates that are already out there.
@rjp: That’s a good summary, although validating with a TCP connection (in particular an HTTP fetch) is not unique to letsencrypt. WoSign uses it, and I believe GoDaddy and some others as well.
Since CAs are, for many domains, bootstrapping trust for the first time, there will always be some amount of exposure to BGP hijacking and other MITM attacks on the validation channel. We have a few plans to mitigate the issue. One of the big ones is through Proof of Posesssion challenges: If Let’s Encrypt knows about an existing valid cert for a given domain name (e.g., through CT), you will have to prove that you control the private key for that cert. This should, in theory, mean that a temporary BGP hijack could not cause issuance for a domain name that already has a cert.
BGP hijacking is rare, but it’s an ultimate attack against unauthenticated connections. It’s certainly a likely attack method for a government that imposes censorship. Unfortunately, there’s not much that can be done if an entire country’s routing has been compromised. Let’s assume a site is hosted in such a country:
DNS verification is not only easier to spoof, it’s also vulnerable to the same BGP attacks. It’s likely that some nameserver in the delegation chain for the domain is also hosted within that country, meaning that requests to it can be rerouted. Effective MITM attack.
WHOIS records are harder to hack, but compromised routing lets us down again here. VeriSign provides “thin” WHOIS services, meaning that it delegates WHOIS authority for domains to specific registrars. If the registrar has its servers in the compromised country, an effect MITM attack can be launched. Unlike DNS, which has DNSSEC, WHOIS offers no mechanism for verifying the authenticity of records. (WHOIS is the protocol that would be used to obtain the email address for a domain name, assuming it weren’t restricted to a specific set of predetermined mailboxes.)
For TLDs that offer “thick” WHOIS services, the security of WHOIS information depends entirely on the security of the registry, the registrar, and the protocol used to communicate between the two. Unfortunately, a popular protocol for that purpose, EPP, is often unencrypted. EPP transmits plaintext passwords, so that leaves it vulnerable to MITM and spoofing attacks when combined with BGP hijacking.
SMTP offers encryption, but not authentication. Even if a sane email address is obtained or otherwise chosen, any attacker able to interfere with DNS (as explained above) is still able to launch a MITM attack to intercept email messages, even if they are encrypted.
@jsha’s case involving an existing certificate is unfortunately the only simple way to avoid a high-profile MITM attack, short of requiring tedious/expensive out-of-band verification.
Hi there. I’m the guy who held the said talk on BlackHat.
As it’s been mentioned before, generally the issue cannot be solved from the CA’s point only. Nevertheless, we at Qrator Labs (not an ad, so no hyperlinks ) maintain our own BGP monitoring solution, and now we are going to integrate Let’s Encrypt API into our core services (to provide TLS certificates for our customers via that API to secure their data). So we’ll take care at least of part of the problem: hijacking of network prefixes hosting Let’s Encrypt’s verification software.
As a side note, it’ll be great it Let’s Encrypt applies for its own AS and network prefix, so that we can give them an access to the data on the security of their network. Yet this is not necessary.
@ximaera, it would also be useful if someone who performs BGP monitoring could give us access to a data feed about routing anomalies related to other networks (that host sites that we’re trying to validate), if that information isn’t considered confidential. I’ve talked to people working in the BGP monitoring field about this before, but we didn’t come to a conclusion about using their tools and data.
@schoen, the information about routing and security issues of other networks actually is confidential (well, not per any agreement, but due to general security considerations), however, we are now thinking about how to provide this limited portion of data to CAs through review mechanisms of some sort. When my colleagues will be heading at least some alpha release, I’ll let you know, and, as a matter of fact, it will be available to Let’s Encrypt servers for free.
I think the discussion should not go into reasoning about how frequent the hijacks are (see bitcoin story). There is no assurance in any certain moment that some traffic is not terminated in wrong hands (unless that traffic is signed with trusted keys). Therefore everyone should accept that TCP/IP connection to an IP is generally not a secure way to check validity of certificate request on it’s own.
Which begs another question… Why there is no ways to either:
disallow issuance of letsencrypt certificate completely or without secondary verification;
specify additional verification information that hijacker could not control (existing certificate signature or DNS record)
IMO two methods combined might create additional level of defense.
It's possible to disallow Let's Encrypt from issuing certificates for a domain with CAA records.
Proof of Possession challenges should help here, and are part of the ACME spec, so I'd imagine Let's Encrypt will implement them eventually, once all the edge-cases have been figured out.
When it comes to Domain-validated certificates, I don't think there's currently any validation mechanism in production at any CA that fully protects against BGP hijacking. In the end, even the more commonly used email validation relies on a TCP/IP connection which can be hijacked just as easily. That being said, Let's Encrypt is doing more than most (if not all) other CAs to mitigate this to a certain degree by supporting CAA and having plans for PoP challenges.
Proof of possession can create availability problems if the reason for the renewal is a lost certificate. Maybe it should not happen too often if it is combined with some AS path monitoring. Yet, these things could be correlated in disaster scenarios.
ACME protocol has DNS challenges, which currently use DNSSEC if it is available. There is also the option of using CAA, and the acme-methods extension limits the channels that can be used. If a CAA record sets the only available acme-methods to DNS( with SEC) then BGP hijacking should not work. It is also possible to limit the accounts that can request certificates.
The threat of BGP hijacking mainly concerns high profile targets, so opt-in protection against BGP hijacks with CAA & DNSSEC might be a good compromise. I don’t know if, for example, certbot automates the creation of CAA records, but that could be a useful feature in clients.
Edit: oh, this was a one year old post, sorry for the bump.
) maintain our own BGP monitoring solution, and now we are going to integrate Let’s Encrypt API into our core services (to provide TLS certificates for our customers via that API to secure their data). So we’ll take care at least of part of the problem: hijacking of network prefixes hosting Let’s Encrypt’s verification software.