5 ms·

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure?

• simias 7y ago
  The challenges used to verify ownership and whether the task is automated or not are mostly orthogonal issues. I don't see how automating the renewal makes it less safe, if anything it removes human error from these tedious tasks.
• iso1210 7y ago
  How does doing it manually verify that certificate is issued to the legal owner of the web site and not a hacker?
  • brirec 7y ago
    It doesn’t. It actually opens up more opportunities for error, intentional or otherwise, that can possibly be exploited by a malicious actor.
• jchw 7y ago
  Humans are actually detrimental to preventing abuse.
• 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.
• gruez 7y ago
  >The fact that it's automated results in less human intervention along the way, which on one hand lowers costs, on the other hand makes it detecting scams harder (unless they deploy some really Machine Learning that detects frauds). You think that other CAs manually issues their DV certificates? >The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance. How do you feel about CAs that accept cryptocurrency, or accept prepaid credit cards?
• detaro 7y ago
  CAs are free to come up with more complicated schemes for customers that think they need them, including systems that include humans in the loop if that's what is requested. It's kind of embarrassing that hasn't happened yet, but apparently "just buy long-term certificates instead of bothering to improve things" wins out unless there is external pressure. That said, many CA verification processes are just less-standardized variants of the things LE does. If you can get LE to give you a fraudulent cert, you will also find another CA you can fool.
  • tialaramex 7y ago
    A customer can (and some high value customers do) proceed as follows: * Pick a CA you can do business with. Let's say it's Sectigo as an example here * Arrange a deal with Sectigo whereby they'll use an agreed process such as phoning a specific (confidential) contact number and speaking with Dave your Head of IT Security to confirm it's as expected before each certificate is issued for your names. Maybe this is a minimum volume deal like you'll pay them $2000 for the first up to 100 certificates per year and then $10 for each additional certificate. * Set the CAA resource in your DNS for your names to require Sectigo as the only authorised CA. Now when bad guys try to trick Sectigo it doesn't work because Sectigo calls Dave who shuts it down and you're onto them. If they instead try to trick say, Let's Encrypt the CAA resource says only Sectigo is allowed and the attack fails immediately. The Ten Blessed Methods (of which Let's Encrypt offers three) are obligatory though, you can't make a deal with a CA to just skip it, they must use one of those methods. However if minimum friction is your goal you could find a CA that also operates as a DNS registrar for your names, whereupon one of the methods (3.2.2.4.12) means they only need to confirm this fact internally, no work for you.
• duskwuff 7y ago
  > The fact that it's automated results in less human intervention along the way... Let's Encrypt is far from unique in being heavily automated. If anything, its verifications are more stringent than those used by other major CAs. > The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance Payment details are basically useless in terms of tracking abuse. Attackers have no lack of access to untraceable or fraudulent payment methods.
• brirec 7y ago
  In regards to your edits, let me also mention that Let’s Encrypt does not offer (and indeed can not offer) “Extended Validation” certificates, due to things related to the two “bad things” you mention. However, extended validation certificates don’t in fact prevent fraud the way they are intended to — indeed, a security researcher managed to get ahold of a certificate for Stripe, Inc. simply by legally registering a corporation under that entity name elsewhere and purchasing a certificate for that legal company.[1] This issue with EV certificates — the fact that they are issued to a company as opposed to just a domain name — cause them to potentially pose a greater risk to web users. [1] https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ https://arstechnica.com/information-technology/2017/12/nope-...
• snowwrestler 7y ago
  Setting aside the question of Let's Encrypt challenges... even for OV or EV certificates, the CA does not verify the organization at the issuance of every certificate. Instead, there is a verification process up front when you establish your company's account with the CA, and then each employee's account in the CA web application is associated with the verified company identity. To be more specific, once the initial company verification is done, the CA relies on their authentication scheme to ensure that the person logging in and requesting a new EV certificate is authorized to do so for that company. The importance of authentication is why both MarkMonitor and CSC require 2FA, for example. I can't think of a reason that such certificate issuance could not be automated. You would just need to have a machine-to-machine authentication scheme that you can trust and monitor. That is easier than Let's Encrypt's challenges because you can manually establish shared secrets in advance (i.e. API keys).