10

https://en.wikipedia.org/wiki/Let's_Encrypt

https://en.wikipedia.org/wiki/Information_security#Authenticity

AFAIK with "Let's Encrypt", we could create HTTPS websites with only one command.

Question: But what provides authenticity, if anybody could create a valid HTTPS cert to any domain? How does Let's Encrypt ensure that I am the domain owner, and not an attacker that wants to MITM the domain?

Community
  • 1
freaking-good-question
  • 191
  • 5
  • 4
    Did you try reading [their technical overview](https://letsencrypt.org/howitworks/technology/)? – cpast Jan 06 '15 at 06:51
  • You do need to verify that you own the domain (by a DNS record or a file upload). This is typically how domain validation is done when you purchase a domain from provider A, then purchase hosting from provider B and you want to link the two up. Let's Encrypt is using the same concept to provide certificates. BTW, this only gives level 1 cert (DV) - in simple terms, encryption only. It doesn't give the authentication given by level 2 (OV) and level 3 (EV - green bar). Level 1 certs should never be seen as authentication as anybody with a domain can have it for the domain. – ADTC Jul 25 '15 at 20:40

4 Answers4

16

If you follow the links from the first Wikipedia link you provided, you'll find the spec for the ACME protocol that Let's Encrypt will use. And what it says is:

Because there are many different ways to validate possession of different types of identifiers, the server will choose from an extensible set of challenges that are appropriate for the identifier being claimed. For example, if the client requests a domain name, the server might challenge the client to provision a record in the DNS under that name, or to provision a file on a web server reference by an A or AAAA record under that name.

Mike Scott
  • 10,118
  • 1
  • 27
  • 35
1

I think there is a fundamental misunderstanding in this question. HTTPS does not provide reliable authenticity. The use of Domain Validation by CAs helps to ensure that the certificate corresponds to the domain, but if you go to citti.com when you meant to go to citi.com, caveat emptor! AFAIK, the risk of MITM attacks involving a false certificate has been limited to the realm of the theoretical, but exploits have been demonstrated.

For this reason, Extended Value Certificates were created. The idea is that the CA owner performs deeper validation that the request for a certificate is coming form the appropriate, authorized party for the domain. In principle, this provides a higher assurance that the particular certificate is trustworthy. When a browser see an EV Cert, it adds a green field with the corporation's name to the address bar. Users are supposed to learn to expect this and not proceed without it. I do not believe this has been adequately communicated to the general public, so much of the potential value is not realized.

It must be recognized that EV Certs are not, at heart, a technical control. They are dependent on users' knowledge and actions. In this sense, even with EV Certs, HTTPS is not a reliable source of authenticity, IMO. None the less, it has great value and users who do look for EV certs and prefer sites that use them do get substantial value.

JaimeCastells
  • 1,156
  • 1
  • 9
  • 16
1

As Mike Scott has said, Let's Encrypt describes how they will be authenticating certificates.

Remember: SSL issuance practices are entirely standardized by the CAB Forum. Let's Encrypt is following the same rules that all other CAs are required to follow. They are just doing it via the command line. The certificates they will be issuing match the issuing practices of "Domain Validated" (DV) certificates offered by other CAs.

Vincent L
  • 108
  • 5
0

Authenticity in TLS certificate issue as currently practiced by most CAs in pretty weak. This is not a problem that is unique to lets encrypt.

Some quick terminiology

Client: a user who wants to access the website and whos Sever: the machine running the website or other service.

Most current CAs only require you to be able to receive email at an administrative address associated with the domain. Typically they give you a choice between one of the contact addresses from whois, or one of several "administrative" usernames at the domain. A MITM close to the client will be frustrated by this but a MITM close to the server (assuming web and mail are hosted together as is typical) can simply MITM the SMTP sessions and get himself a certificate.

Lets encrypt propose to take a slightly different approach, the lets encrypt servers will require the client to complete a "challange", either placing a specific file in the server's document root or creating specific DNS records. Again this will frustrate a MITM close to the client but a MITM close to the server will be able to intercept these requests and get a certificate.

So-far this is approximately the same level of (in)security as most current CAs.

However according to https://community.letsencrypt.org/t/will-you-allow-overlapping-certificate-requests/135/8 . There will be an additional requirement if there exists an existing certificate for the domain the user will be required to demonstrate control of it. Therefore (unlike with most current CAs) a MITM close to the server can get the first certificates for a hostname but they can't get certificates for a domain that already has one.

Peter Green
  • 4,918
  • 1
  • 21
  • 26