76

Let's Encrypt is an initiative from the Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, IdenTrust, and researchers at the University of Michigan that aims to automatically provide every domain owner with a recognized certificate that can be used for TLS.

In order to prove that you own a domain, you need to install a file with particular (randomly generated) contents at a particular (randomly generated) URL on that domain. The Let's Encrypt server will verify this by accessing the URL, before signing the certificate.

Now, suppose I have some attack which will make the domain awesomebank.example resolve to my server. Suppose I can also MITM some peoples' connections to https://awesomebank.example/. TLS is intended to prevent me from seeing or altering their communications to the server without being detected.

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)? Doesn't the existence of a fully automated CA make the Internet less secure?

forest
  • 65,613
  • 20
  • 208
  • 262
user253751
  • 4,610
  • 3
  • 21
  • 17
  • 12
    "...some attack which will make the domain awesomebank.example resolve to my server". This is called DNS poisoning. Once you achieve this, why would you perform MITM. All the customer's data is coming to your server. It is game over then. But you can't pull this off easily unless you convince the DNS registrar of awesomebank.example to resolve it to your IP or you exploit a vulnerability in their DNS infrastructure. Even that can be mitigated through DNS change locking. – void_in May 04 '15 at 08:06
  • 22
    Many existing CAs are already automated. They only check if you can receive emails to admin@example.com. – CodesInChaos May 04 '15 at 08:08
  • 2
    Even DNS (cache) poisoning only works if the cache is used. If the resolver is designed to specifically follow the delegation chain on each lookup, and perhaps even do so for all alternatives and make sure that the responses match, this attack can be mitigated easily to a high degree of confidence. Since certificate signing is a relatively low-frequency operation, something like that would not significantly affect other systems nor significantly increase the time required to get a certificate. – user May 04 '15 at 08:54
  • 3
    This is a flaw with this entire CA-based PKI. Alternative solutions like using a web of trust instead (like PGP) would be more resistant to this type of attack, because you'd need to fool multiple people into trusting your MITM identity, as opposed to a single CA. –  May 04 '15 at 12:42
  • 5
    @void_in "All the customer's data is coming to your server" would only be the case if the clients actually establish the TLS connection to your server. For that to work, you (normally) need to have a valid (signed by trusted CA) certificate for the domain name. And to get that you need to trick the CA during the verification process. – resistor May 04 '15 at 20:53
  • Let's Encrypt's image is supposedly good. Otherwise this question would be "Is Let's Encrypt trustworthy?" or [similar](https://security.stackexchange.com/questions/127575/is-startssl-com-a-trustworthy-site/127630)... – rugk Jul 20 '16 at 17:32
  • 1
    [No longer theoretical](https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation) – JimmyJames Apr 06 '17 at 18:24
  • Right after I read the article at Wired https://goo.gl/zAqLKJ, I landed here @JimmyJames - What a coincidence, I was about to post the same comment. – Karthik Apr 10 '17 at 01:47

7 Answers7

71

Same security as other DV certs

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)?

Nothing. If you own the network, then you own the network. And DV type certs (see below) rely on the network for proof of domain ownership. There are usually no out-of-band checks. (Nobody will call your phone, nobody will check your photo ID, nobody will visit you at the place the company is registered to, etc.)

Doesn't the existence of a fully automated CA make the Internet less secure?

Nope. Same level of security as DV type certs.

There are (currently) three assurance levels for x509 certs:

  • DV, Domain Validation
  • OV, Organization Validation
  • EV, Extended Validation

DV is the cheapest. It basically means "If somebody can answer an email to admin@example.com, then that person gets a certificate for example.com".

There are additional checks for OV, EV.

More info about cert types: GlobalSign.com: What are the different types of SSL Certificates? (Archived here.) Wikipedia: https://en.wikipedia.org/wiki/Public_key_certificate#Validation_levels And a lot more background info in these slides here: RSAConference2017, Session ID: PDAC-W10, Kirk Hall, 100% Encrypted Web -- New Challenges for TLS

Further reading

StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
  • 2
    Note that the e-mail check, while common, is not the only automated check in use. In particular, many existing CAs give the option of exactly the same web-based proof that Lets Encrypt describe in their docs. – IMSoP May 04 '15 at 13:29
  • Yes. I've just never come across anything but the e-mail version in the wild. – StackzOfZtuff May 04 '15 at 14:00
  • 5
    Working in a web dev agency, I was heartily relieved when Comodo started offering DNS and HTTP verification, because it means we no longer have to explain the process to the non-technical staff who have access to the admin@ e-mail account. Or, worse, to the IT staff who need to create such an inbox especially for the purpose. – IMSoP May 04 '15 at 14:21
  • While DV and EV are industry standards (standardized by the CA/Browser Forum), as far as I know OV is GlobalSign only. For example both DigiCert https://www.digicert.com/ssl-certificate.htm, and Entrust http://www.entrust.net/ssl-certificates.htm offer EV and a bunch of their own variants (but not OV). – Mike Ounsworth May 04 '15 at 17:54
  • @MikeOunsworth While not standardised, I think the broad concept of OV as a step between DV and EV is fairly common; see e.g. [Comodo's knowledgebase](https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/312/16/what-is-an-organizationally-validated-certificate). – IMSoP May 06 '15 at 08:05
  • "*Doesn't the existence of a fully automated CA make the Internet less secure?* Nope. Same level of security as DV type certs." It seems Let's Encrypt is *more* secure since wouldn't a MitM attack not be as easy with it as with a centralized CA? – Geremia Mar 10 '16 at 02:21
15

Yes, the protocol you describe only ensures that "the person who picks up the phone at awesome bank" when you call them, is the same person who picked up the phone at awesome bank when the Let's Encrypt server called them. If I have the ability to intercept calls to awesome bank both from Let's Encrypt and from you, then I can fool you.

Ideally what you'd want TLS to tell you, is that "the person who picks up the phone at awesome bank" when you call them is actually an employee of awesome bank. But this is difficult to automate, since computers can't just figure out who someone works for, so better-validated certificates cost more. Let's Encrypt isn't doing anything less secure than other CAs do already.

One hopes that Let's Encrypt will try to make it more difficult to intercept their calls to awesome bank, than it is to intercept yours. Some internet access points are easier to mess with than others (unsecure wireless scores low), and messing with multiple access points simultaneously is harder than just one (so perhaps Let's Encrypt will confirm that it receives the same file when it downloads it from many different places in the world, although I haven't looked whether they consider that necessary). With the exception of organisations like the NSA, MITM attacks in practice tend to be localised and temporary.

So, it will provide some measure of security only to the extent that it's harder to MITM Let's Encrypt than it is to MITM you. We suppose that it's easier to control your access to the internet than it is to control either that of Let's Encrypt or that of awesome bank, and that's why you "trust" Let's Encrypt as a CA.

Naturally none of this is really phone calls, it's inbound socket connections.

Steve Jessop
  • 2,018
  • 11
  • 14
  • You could ensure that "the person who picks up the phone at AwesomeBank" is actually using AwesomeBank's phone, if DNSSEC was used. – user253751 May 05 '15 at 03:31
  • 2
    @immibis: well, you can be "sure" you have the right IP address using DNSSEC. Your routing could still be hijacked. DNNSEC also allows for reliable CERT records, but I'm not up to date on what that wins you. – Steve Jessop May 05 '15 at 11:51
8

Let's Encrypt is designed to help against a range of attacks and to push the generalization of TLS usage to have a globally safer and more private internet. It is aimed more precisely to remove technical and financial constraints which may prevent some webmaster to use TLS certificates more broadly.

However, as any security measure, this will not be a miracle product solving all possible securities issues and allowing you to stamp your website as "100% secure website!" (even if some websites do not hesitate to use such stamps...). Security implies the combination of several layers, each one designed to address their own class of threats.

If one really manage to take ownership of your domain name, then most chances are that the fact that the Let'sEncrypt certificate delivery is automated will not have more impact in this case than in another situation.

As a reminder, all you need to get a cert from classical CA is to own an administrative address like "admin@example.com" and pay some money. If you manage to get the domain ownership, then you are free to redirect the email to a mail server of your own, thus effectively owning the email address of your choice too.

This is not a theoretical threat. You will find here and article written by someone whose domain has been stolen in order to take ownership of his email. In this precise case it was in order to access the password reset emails sent from third-party societies, however in his position the attacker would as well been able to generate new certs for this domain and build a phishing site which will be considered secured by the browsers.

WhiteWinterWolf
  • 19,142
  • 4
  • 59
  • 107
  • Not "take ownership of the domain", but if I can trick a DNS resolver into *temporarily* resolving to my address (e.g. with cache poisoning) then this gives me the non-temporary ability to impersonate that domain. – user253751 May 04 '15 at 09:09
  • 1
    You would not only need to poison the cache of the CA DNS resolver (whether it is Let'sEncrypt resolving your website address or another CA resolving your mail server address does not matter here), but you would also need to poison the cache of each and every visitors you want to redirect to your phishing site when they go to the `https://awesomebank.example` URL (otherwise having the cert will be useless if you cannot impersonate the website). Might be doable to some extent as a part of a very targeted attack, but remains clearly limited and not doable at a large scale. – WhiteWinterWolf May 04 '15 at 09:25
  • 2
    If MITMing a website was so difficult, then surely we wouldn't need TLS to prevent it? – user253751 May 04 '15 at 09:32
  • MITM is not the only threat, there is also eavesdropping, and the complexity of all of them directly depends on your network position compared to the target. As the name imply, you have to be able to put you somewhere "in the middle" of the communications between your targets. A outsider end-user (as opposed to ISP, government agencies, etc.) will not be in good position to do a massive MITM, so he will either have to artificially move his position by gaining access to some machines offering better MITM possibilities, or use another mean depending which is the more profitable. – WhiteWinterWolf May 04 '15 at 09:47
  • 2
    If we were only concerned about eavesdropping, browsers would accept self-signed certificates. – user253751 May 04 '15 at 21:35
  • 2
    @immibis: Self-signed certificates only protect against passive MITM attacks. An active MITM attacker can create a self-signed certificate. – Brian May 05 '15 at 13:21
  • @Brian An active MiTM attacker would also break Let's Encrypt. – ithisa May 06 '15 at 02:10
  • @Brian You said "MITM is not the only threat, there is also eavesdropping". But if eavesdropping was the main threat, then browsers would accept self-signed certificates, because eavesdropping without MITM is then impossible. – user253751 May 06 '15 at 05:26
  • 2
    @user54609: An active MiTM attacker only gets one chance (per certificate) to compromise Let's Encrypt, and must do so by compromising connection to Let's Encrypt (which is signed by a trusted CA). With a self-signed certificate, *every* connection is vulnerable to active MITM attack. – Brian May 06 '15 at 07:39
  • 1
    @immibis: It is not Brian who said that, and I never said that eavesdropping was the main threat. I just said that MITM is not the only one, eavesdropping is also a threat. That's why TLS does not limit itself to ensuring authentication and integrity, but also confidentiality. Go to some public or shared wifi, start Wireshark and monitor activity involving port 80, then you will quickly see why eavesdropping is an issue and how TLS effectively prevents this. Otherwise you may want to open a new question since discussing the security benefits and limitation of TLS seems a bit out of scope here. – WhiteWinterWolf May 06 '15 at 08:43
7

The use of an automated check is not unique to this CA, but is common for entry-level certificates. As stated in other answers, there are 3 levels of certificate in use:

  • Doman Validation proves only that you had control of the domain at the time the certificate was issued. (And that the certificate hasn't been explicitly revoked since then.)
  • Organisation Validation involves an extra check that the company name listed in the certificate is valid.
  • Extended Validation includes a much stronger audit of the company applying for the certificate.

For a basic DV certificate (and as the first step in OV and EV applications), most CAs will use some form of automated "Domain Control Validation". For instance, Comodo offers 3 options:

  1. An e-mail must be received by one of a short list of generic addresses at the domain, such as "admin@", on the assumption that only authorised staff would have access to these mailboxes.
  2. A specific CNAME record must be added in the DNS zone for the domain, proving that the applicant has DNS control.
  3. A URL must be added with specific content in the root of the domain's HTTP, proving that the applicant has control of the web server pointed at by the domain.

The ACME protocol being developed as part of the Lets Encrypt effort is to automate the client side of this check. Their Technology Overview actually mentions both the DNS-based and HTTP-based checks as examples which could be automated in this way.

The idea is that the software you install can automatically determine how to meet these challenges based on the configuration it has access to. If it can find and write to the Document Root of the domain to be validated, then the HTTP-based challenge is very easy to automate. The more traditional e-mail based validation method would be trickier to automate, due to the complexities of mail delivery, but doesn't actually differ in the amount of proof it provides.

IMSoP
  • 3,790
  • 1
  • 15
  • 19
5

The primary defense against MITM attacks during issuance is to perform the validation check -- observing the server or its DNS -- from many geographically dispersed locations. This is how many CAs today operate for automated web checks to detect forgery and fraud.

From what I heard in the IRC room, Let's Encrypt will be doing the same for all of the validation checks.

J.C.
  • 151
  • 2
1

Remember you need to MITM not the users of the site, but Let Encrypts validation servers to be able to get that certificate, its going to be much harder.

Lets Encrypt has recently talked about how they use Multi-perspective validation to help protect themselves against such an attack - the idea being that they will validate your ownership of the domain from different places in the internet, such that you would need to MITM multiple data centers around the world.

In this case I think Lets Encrypt is more secure than other certificate providers that are not going to such lengths to protect themselves. This is nothing unique to Lets Encrypt - if you can MITM the certificate provider, you can use any of them, it just might be more expensive for you.

mcfedr
  • 162
  • 4
  • Well, some certificate providers do attempt to verify your real-world identity. Not so much since LE started existing. – user253751 Sep 03 '20 at 11:22
  • 1
    For EV certificates they should do this, but for DVs that Lets Encrypt give you, other providers are similar and tend also to be automatic, but in a less structured way that ACME protocol. – mcfedr Sep 03 '20 at 11:28
0

To get practical on this in 2020 - I ran the following test with SSL labs https://www.ssllabs.com/ssltest/analyze.html?d=certbot.eff.org and they report eff.org (a site which enables you to integrate LetsEncrypt with your server) as A+ - this is their highest level available. So as long as you setup your server correctly it is possible to achieve the same results as for paid certificates.

From my understanding self-signed certificates offer the same level of encryption as CA signed its just that people recognise the authority. With LetsEncrypt they've become a recognised authority with the browsers hence how they can operate.

Furthermore they have a 90 day limit which means that in the event your keys are hacked they are issued more regularly. As this is done automatically it shouldn't be as painful as normal renewals!

Antony
  • 115
  • 4