[RyanZAG]

Does anybody know if there is any protection built in against MITM or DNS poisoning attacks?

It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate.

For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which routes along a set path - say 2.3.4.5 and 3.4.5.6. To verify that I control amazon.com, letsencrypt is going to try and fetch http://1.2.3.4/something (through DNS resolving). If I can get MITM access on 2.3.4.5 and pass back /something to the request, letsencrypt is going to generate a certificate for me that I can use to say I am amazon.com for the entire world.

Is there any protection against this built into letsencrypt for this? Maybe checking if amazon.com already has https:// ? Although I'm not sure if there is any way to get around a DNS poisoning attack...

In essence, this seems to mean that you can take a single successful MITM and turn it into a globally authorized MITM. Right?

[0x0]

You can already do that today with most CAs.

They may do domain validation by looking up WHOIS and emailing the contact address there.

You could MITM the DNS MX lookup and respond with an IP address of an SMTP server you control, and grab the validation code in the verification email as it is dutifully delivered to you just as easily.

Edit: In fact, come to think of it... For DNS you might not even need to MITM, just be able to spoof the IP source in an UDP package and correctly guess the remote source port + possibly a query ID, and race the real DNS server? I wonder how feasible that would be at for example 1 Gbps?

[bracewel]

Boulder (the CA backend) has two solutions to this problem

a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate

b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuance (servers which would move over time)

Currently (a) is mostly implemented but (b) needs quite a bit more work before it can go live.

[devit]

What happens if the user loses the key?

What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one?

Also, how can the new owner revoke all certificates delivered to previous owners?

[AnthonyMouse]

Certificates expire. Presumably the answer to all of your questions would then be to wait for the old certificate to expire.

So if you want to mitigate the consequences at the outset, use certificates that expire quickly. Which should be easy when renewing a certificate is free and automatic.

[bracewel]

Either wait for the certificate to expire, register a new certificate for the domain with another CA which LE will see and can then be used to prove ownership, or ask the originally issuing CA to revoke the certificate which will remove the need for the challenge completely.

[devit]

I interpreted "you must prove control over both the server and the key used in the existing certificate" as meaning that if a Let's Encrypt certificate for the domain has been created in the past, you need to own its key (presumably proved by signing something with it) to get another one.

Is that wrong?

Waiting for certificates to expire could mean waiting for years, unless they have auto-renewing very short-lived certificates (but then you have the same problem for the authentication used to automatically get those certificates).

[MatthewWilkes]

LetsEncrypt does use very short-lived certificates (90 days) for this reason. However, you have to remember than when you buy a domain you already have no idea if any CA has issued valid certificates for it.

[M2Ys4U]

According to their 31C3 talk, they will use multiple connections from multiple locations (possibly including Tor?) to mitigate against these attacks.

[RyanZAG]

Thanks, this is the real answer I was looking for and not the hand waving about trusting everyone up above. That sounds like a good solution to me.

[superuser2]

Any CA performing domain ownership validation would be vulnerable to the same thing. If you can fake its WHOIS requests or make it appear as if the domain making the request does in fact have the "canary" file they told you to host to prove ownership, then you can get any CA to give you a cert for any site.

You have to trust something.

[0x0]

If the registrar held the job of being a CA, then at least there wouldn't be a spoofable link between the CA and the domain owner - the registrar already has your account information and proof of ownership, 100% verified, when your domain is held with them...

[nailer]

Sure, but registrars would need to start doing a lot better job of checking the identity of people applying for domains, otherwise we'd just end up with domain validated certificates all over again.

As the grandparent post notes, all CAs completely automate domian validation at present.

[0x0]

My point is that regular domain validated CA should be the sole job of registrars. It would even prevent parallel certs being fraudulently issued - a domain can only be registered at one registrar at one time.

Sure, you could have the other CAs still offer EV (real-world identity) validation as a value-add.

But it's pretty silly that, currently, you have to pay a third party (today's CAs) to validate something that the registrar already knows for sure.

[kej]

The other side of that argument is that if your registrar is also your CA, they have the ability to give bogus SSL certs to an evil server and the ability to direct your domain to that evil server.

[0x0]

They can already do that, as they could temporarily hijack your NS records and buy a cert somewhere else. If you can't trust your registrar, you have bigger problems (I'd say "all is lost")

On the flipside, having a registar act as the only valid CA would mean that choosing a trustworthy registrar suddenly has real value. Power users could make an educated opinion on the trustworthyness of a given domain validated CA. Domain owners could be sure they're not at risk for how in the current system, an adversarity could get a valid parallel SSL certificate from a sloppy bargain-bin CA, even if the domain owner picked the most expensive and diligent CA and registrar for themselves.

[RyanZAG]

Agreed - but by making this a fully automated system you open up an easily testable and repeatable source of attack.

I don't think "You have to trust something" is really right in this case, as you're basically saying "You have to trust every single router between letsencrypt and every server on the internet".

I guess it's correct that with most current CAs now automating a lot of this with minimal manual checks, this is probably happening already? I wonder how many amazon.com valid certs are floating around the place? (Or more likely, smaller sites where people wouldn't be checking if the cert is really valid). The original point behind the costs charged by Thawte et al was that they would actually validate that you're who you say you are. I guess that ship has sailed though.

[superuser2]

All mainstream CAs issue certs through a fully automated process, and have for at least a decade. Generally you are required to receive emails sent to the administrative contact in WHOIS, put something in a DNS TXT record, place or file they give you at a URL they give you, or some combination of the above.

There are Extended Validation (EV) certs where a human verifies your ownership of a legal entity. Chrome presents these as a big green bar with the name of the corporation in the URL bar. Most certs (including Amazon's) are not EV certs.