At the moment many SSL cert providers require that an email be sent to a user on the domain (or the user in the whois record) before issuing a cert.
Will the same safeguard be in place for SSL certs issued via let’s encrypt?
From what I’ve seen/read, the letsencrypt client has a built in webserver which is listening to the domein. It then polls the domein on the port the client is listening to. If it works, it’s your domain. (someone elses domain wouldn’t point to your server, you see?)
The ACME protocol on which Let’s Encrypt is based allows for multiple challenge types to prove you control a given domain name. The ones Let’s Encrypt plans to support at launch are SimpleHTTP and DVSNI.
The SimpleHTTP challenge requires you to place a specially formatted file on your webserver. The DVSNI challenge requires you to configure your webserver to respond with a specially formatted x509 certificate when a certain name is requested via SNI.
In either case, you can run the official Let’s Encrypt client, which will automate the challenge process either using your already installed Apache or Nginx (with no downtime), or using a built-in webserver in the client.
10 Likes
All of these methods are different examples of Domain Validation (DV), which is an effort to confirm that the certificate is being issued to the same party that controls the domain name. There are several different methods that existing CAs use for DV, and the methods @jsha describes here are similar to those—and should all be approved by the CA/Browser Forum’s Baseline Requirements relating to DV.
Currently the Let’s Encrypt CA hasn’t implemented an e-mail-based validation method.
1 Like
It looks like the protocol is simple/consistent enough that standalone Discourse instances shound be able to do it.
“using a built-in webserver in the client.”
I assume the client is a binary vs a script then?
1 Like
Hi @kroboto,
The client is a Python program, distributed as Python source code. The standalone authenticator plugin in the client uses the Python socket library to accept incoming network connections. Python programs, including those distributed as source code, can easily make and receive network connections this way.
3 Likes
That is actually good to hear. I can read Python. C gives me headaches.
2 Likes
How will I need to adjust my firewall rules to allow these incoming connections? Will there be a list of known hosts/addresses that requests will originate from in order to limit connections to those hosts only?
1 Like
I believe that’s because the focus here is AUTOMATING the whole process. Currently all the CAs require a user to receive an email and click on a link to confirm ownership.
Hi @mikev, hopefully you’re running the client software on a server that’s able to accept incoming HTTPS connections from the general public, at least for the duration of the validation process.
I’m not sure whether we’ll publish a list of hosts that may perform validations. One security challenge for DV validation is that an attacker might be able to manipulate the network path between the host that performs the validation and the host that responds. To address this, we might in the future perform validations from several different locations on the Internet. We might not want to let prospective attackers know all of the network paths or locations that they’d have to manipulate in order to interfere with the validation for a particular name or server.
2 Likes
An attacker would still only need to know one path or location, the destination, wouldn't they?
Part of the original Boulder (the Let’s Encrypt backend) design is to use multiple validation authorities in order to validate a domain from multiple paths, mainly to avoid this exact problem. The design work for this is still ongoing.
1 Like
An attacker would still only need to know one path or location, the destination, wouldn't they?
Nope, the attacker would need to make the attacker's server look like the real server from the perspective of each validation server that we used, which could be n different and independent paths. They don't simply have to knock the genuine server offline; instead, they have to be able to be seen as the genuine server by each validation server.
Problem: If you don't have a way to cycle IP addresses, an adversary can just request a certificate once and look at what IPs request the URL.
Perhaps one or two static IPs plus a pool of low-cost EC2 servers spread across all available regions? And throw in some other cloud providers too. The vantage points would need to make sure that the requests were signed by the Boulder server (should make a new root for just that, don't want to overload the HSM) to not become an amplification attack helper.
Yeah, we’re considering how to approach this and may end up doing something along those lines.
2 Likes
How would Let’s Encrypt treat a request for a subdomain certificate where there exist a EV (Extended Validation) certificate on the main domain from an issuer that Let’s Encrypt trusts, say one of its sponsors?
Would Let’s Encrypt consider issuing a bootstrapped EV or OV (Organization Validation) certificate rather then DV (Domain Validation)?
They don't simply have to knock the genuine server offline; instead, they have to be able to be seen as the genuine server by each validation server.
If they control a node very near to the original server it should be possible...
Also discussed here BTW:
I'm really glad to hear that you are going to use multiple vantage points to verify ownership. I was wondering whether one of these verification agents could route traffic through the Tor network as a cheap way to increase the number of vantage points.
2 Likes
We’ve also considered that possibility!
2 Likes