Hello, when I apply a cert for my domain, it asked me to put a file on the my webserver such as “/var/www/html/.well-known/acme-challenge/XXXXXXXXXX”. Is this method safe?
Could the following sitiation happen?
Assume someone controls a very important router(the entry of the whole country), and all the traffic between my server and Let’s Encrypt server should be transferred by this router, so he/she can easily cheat the Let’s Encrypt server. So Man-in-the-middle attack occurs, and He/she can claim that my domain is his/hers.
How does Let’s Encrypt deal with this?
Thank you!
Yes, the situation you describe could happen. If it does you should report it to Let’s Encrypt. Under the Certificate Transparency programme you can watch out for this happening (every certificate issued is logged for everyone to see) for names you control. However such a powerful adversary is very difficult to defeat affordably.
2 Likes
hi mengqingzhong
all communications to letsencrypt is done via HTTPS
So even if someone could sniff your traffic they could not decrypt it.
As they cannot decrypt it they cannot provide authentication.
Second layer of the protection is the private key. The private key is on your server and to complete the validation you need to sign the request. If someone knew what the request was for example they could not sign it so letsencrypt will not let them complete the transaction.
The third layer of protection is the nonce methodology. This prevents replay attacks as every request requires a new nonce (hence you cannot replay a message).
Thank you very much. According to what tialaramex said, if someone who controls a core router ( the gate of the whole country), he can apply certs for all domains that resolves to IP addresses in his county. The only way to protect our domains is monitering his domains by ourselves. We should make sure that no one else apply a cert for our domains periodically. We can check that at https://www.google.com/transparencyreport/https/ct/
Thank you very much! I learned from you that we should moniter the stauts of our domains periodically at https://www.google.com/transparencyreport/https/ct/ .
this is incorrect
just because they control the router does not mean they have the private key which is needed to sign requests.
it also doesn’t mean they will be able to decrypt traffic between you and letsencrypt
If he is the first person to apply a cert for a domain, he can create a new key. How can Let’s encrypt know he is the bad guy?
yeah nice, but an attacker with access to e.g. a state level router which happens to be in the route could try to create his own certificate and MITM the validation because the validation itself it done over plain HTTP.
ergo, the attacker doesnt try to mitm the challenge of the owner to do weird stuff, but he issues his own and MITMs that to get a cert for himself.
of course this can be found out via certificate transparency.
one thing I can recommend is this little thing:
https://ctadvisor.lolware.net/
it emails you everytime when a new cert for your domain (or any subdomain) appears in CT logs.
he doesnt even need to be the first one. it isnt as if LE cares about who (in other words which account) tries to get the cert for any domain, because they are as the name says Domain Validated. have control of the domain and there you have it.
one thing that may be intresting would be making it possible to kill HTTP validation at the DNS Level, especially if the DNS provider you use has DNSSec which makes it VERY hard to try to manipulate anything.
hi mengqingzhong
this is a theoretical limitation of domain validation
even if he has the key and obtains the certificate - what purpose does it server
he will not be able to install the key and certificate on your servers
yes there is the possibility of a proxy however there are a few technologies like APLN which remove this
there are also extended validation certificates (not available from LetEncrypt) or organisation validated certificate which minimise this
Yes, I agree. I don’t think use HTTP in the validation step is a good idea. But if we use HTTPS, we should have a valid cert first, so we are embarrassed; In order to get a cert, we need a cert first, it is a circle.
Using the email address in WHOIS maybe safer that using HTTP.
If a state has google’s or github’s cert, the state can be the middle man to monitor people in the whole country…
Alas emails may be intercepted by such a powerful adversary too, and most certainly they can alter WHOIS which is not even an encrypted system.
Right! Thank you!
Monitoring our domains by ourselves is the only method.
I am not joking, this did happen in Sep 2014. It lasts about a week. When I open google at that time, the browser tells me that the cert is not valid. I am sure that the cert is a fake.
or DNS (especially if DNSSec is enabled)
sadly true but DNS Could be a thing. especially with it's tree like structure.
or let someone do that for you (see link above)
1 Like
Got it! Thank you very much!
@mengqingzhong, I agree with your concerns that an infrastructure provider can spoof domain validation requests, get a valid certificate, and then perform hard-to-detect man-in-the-middle attacks. Unfortunately it’s hard to work around this because we don’t have a clear way to confirm who really controls names and sites on the Internet other than “experimentally” or “empirically”.
In addition to Certificate Transparency, which people mentioned, you can use the Certificate Authority Authorization (CAA) mechanism.
This involves creating a DNS record that says which CAs (if any) are allowed to issue certificates for your domain name. If you control the DNS for your domain and if it’s hosted outside of your country or network, it may be hard for an attacker to interfere with what people elsewhere see from the DNS, so they can learn whether you do or don’t want certs to be issued at a particular time. One option would be to post a CAA record saying that no certificates should be issued, and then briefly change it at the time that you want to obtain certificates (to allow your chosen CA to issue them), then change it back afterwards. Edit: we have to be careful with this approach because maybe some browsers will reject the certificate if it’s issued by a CA that CAA records say is not permitted. So we need to check browser behavior before adopting this solution.
A limitation of this is that if the attacker notices what you’re doing, it can try to very quickly get a fake cert at the same time. However, this is probably somewhat harder and less reliable (though maybe some attackers will try to get practice doing this attack if this defensive measure becomes popular).
Let’s Encrypt checks and obeys CAA records, and many other CAs do too. There is a discussion going on now at the CA/Browser Forum about making it mandatory for all CAs to check and obey CAA.
Another measures that can help defend against fake certs is HPKP
where you can tell clients about what keys to expect when they visit your site (so if someone later gets a fake cert, users who’ve visited the real site before won’t be fooled by the fake one and will reject it). You have to be careful when using this technology because if you lose your private keys or have to make an unexpected change to the site’s certificates, visitors can be completely locked out of visiting the site for a long time, until the pinning rule expires.
Monitoring Certificate Transparency is also quite valuable because if we can catch people performing these attacks to cause certificate misissuance, we can investigate who did it and how, and also prioritize defenses to prevent it from happening again.
Thank you for raising this issue, and I hope these suggestions help with your concerns.
1 Like
shouldnt actually TLSA be used for exactly this purpose
but stupid question could it be possible to inform LE by DNS (even better if the domain has DNSSec) to only do DNS validation for LE?
Yes, after looking at the CAA specification, I've started a discussion on Wikipedia because I think the current Wikipedia explanation is probably wrong and browsers aren't supposed to check CAA.
I can look into this. (Edit: @pfg says below it's already in progress!)
The ACME WG is working on a CAA extension that would allow domains to be bound (limited) to certain ACME accounts, as well as limit the supported challenge types. See: draft-ietf-acme-caa-00
@pfg nice stuff, now we are finally seeing something REALLY intresting. the only prolem is that (same with TLSA) that your provider has to support this record type instead of just using a TXT record similar to SPF ot DKIM (which actually once had its own type of record, dont ask me why)