4 ms·

I think you may not be very familiar with Let’s Encrypt’s challenges. Allow me to briefly explain the gist of them: The two most common challenges are an http

by brirec 7y ago

I think you may not be very familiar with Let’s Encrypt’s challenges. Allow me to briefly explain the gist of them: The two most common challenges are an http challenge, and a DNS challenge. The http challenge gives you a response code to host as a file on the domain during the validation period. This challenge is, for all practical purposes, random, and cannot be guessed. Then, after your script tells Let’s Encrypt that the response to its challenge is available and up-to-date, Let’s Encrypt performs an http GET request to retrieve that response, and checks to ensure it is exactly what the script provided. Only then does it proceed with signing your CSR and giving you a valid certificate. This requires (at least temporarily) a web server running on port 80 at the domain in question, and in order to break it you would need to be able to effectively either hijack the A record for the domain as read by Let’s Encrypt, or to break into the web server to properly issue a certificate that one then steals. Impossible? Probably not. Impractical? Very. DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers. So, to put it rather simply, >Are the challenges used by Let’s Encrypt secure? Yes, so long as you trust your DNS and web servers not to be compromised. And if they are, it’s frankly game over anyway. Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances. Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit. Honestly, I don’t think there is much (if any) point in still using manual verification. The human aspect of it also opens up chances for forgery, and so on. Let’s Encrypt’s challenges are specifically designed to be difficult or impossible to hijack, and so far as I understand it the private key should never leave the server it will remain on. So again, to answer your question succinctly and to the best of my knowledge: yes, the challenges used by Let’s Encrypt are most certainly secure.

xg15 7y ago
> DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers. > Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances. What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar. Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other. > Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit. Again, it's harder for a rogue CA to abuse my certificate - but instead, a rogue registrar could now easily manipulate my DNS record and receive a valid cert of its own.
- Reelin 7y ago
  I think there's an underlying assumption that your server, your DNS registrar, and all the CAs present in your root store are trustworthy. It may not be a particularly safe assumption, but it's presumably better than unverified TLS or trust on first use (for the majority of present day usecases). If anything, I would expect universal adoption of automated verification methods to improve security. Instead of only needing to trick a single CA out of an entire root store into issuing a certificate, you would instead need to hijack the DNS listing without being noticed by _anyone_ (and hopefully all CAs, as well as everyone else, would be on the lookout for this).
- tialaramex 7y ago
  This is correct. But perhaps even more correct would be to say it _consolidates_ the risk at your DNS registrar, since of course bad guys who seize control of your DNS records could anyway deny all service and capture anything unencrypted. You should definitely not use an untrustworthy DNS registrar or registry for important things, but that was true regardless and it hasn't stopped the .com TLD (which is run very badly indeed) making a tremendous amount of money.

by brirec 7y ago

xg15 7y ago

> DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers. > Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances. What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar. Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other. > Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit. Again, it's harder for a rogue CA to abuse my certificate - but instead, a rogue registrar could now easily manipulate my DNS record and receive a valid cert of its own.

Reelin 7y ago
I think there's an underlying assumption that your server, your DNS registrar, and all the CAs present in your root store are trustworthy. It may not be a particularly safe assumption, but it's presumably better than unverified TLS or trust on first use (for the majority of present day usecases). If anything, I would expect universal adoption of automated verification methods to improve security. Instead of only needing to trick a single CA out of an entire root store into issuing a certificate, you would instead need to hijack the DNS listing without being noticed by _anyone_ (and hopefully all CAs, as well as everyone else, would be on the lookout for this).
tialaramex 7y ago
This is correct. But perhaps even more correct would be to say it _consolidates_ the risk at your DNS registrar, since of course bad guys who seize control of your DNS records could anyway deny all service and capture anything unencrypted. You should definitely not use an untrustworthy DNS registrar or registry for important things, but that was true regardless and it hasn't stopped the .com TLD (which is run very badly indeed) making a tremendous amount of money.