7 ms·

No joint announcement with other industry 'leaders' like Google and Microsoft? What is their stance on this? Will they be making similar changes to Chrome/Edge?

No joint announcement with other industry 'leaders' like Google and Microsoft? What is their stance on this? Will they be making similar changes to Chrome/Edge? And Mozilla? And maybe I am wrong but compromised certs are game over very soon aren't they? Reducing their lifetime to 'just' a year is still plenty of time to do enough damage seemingly, so what exactly does this high-handed change bring to the table? Another reason stated that it will keep the cert management folks busy and alert also sounds like grasping at straws to prop up the decision. I wonder what the entire reasons are...

reaperhulk 7y ago
The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful. As for the other browsers, Google originally proposed SC22 (https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html https://cabforum.org/pipermail/servercert-wg/2019-August/000...) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it. So while Apple is acting “unilaterally” here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.
- mamon 7y ago
  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? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free 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). 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. Together those things make things less secure, not more. EDIT 2: Both types of Let's Encrypt challenges look like pushing down the responsibility to either web server owner or DNS service. Maybe that's a good thing, since at least there's one fewer party that can screw things up.
  - 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.
michaelbuckbee 7y ago
Google and Mozilla are both major backers of LetsEncrypt which is tackling this problem from the other side (issuing short-lived certificates and putting in a system to automatically update them).

reaperhulk 7y ago

The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful. As for the other browsers, Google originally proposed SC22 (https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html https://cabforum.org/pipermail/servercert-wg/2019-August/000...) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it. So while Apple is acting “unilaterally” here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.

mamon 7y ago
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? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free 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). 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. Together those things make things less secure, not more. EDIT 2: Both types of Let's Encrypt challenges look like pushing down the responsibility to either web server owner or DNS service. Maybe that's a good thing, since at least there's one fewer party that can screw things up.
- 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.

michaelbuckbee 7y ago

Google and Mozilla are both major backers of LetsEncrypt which is tackling this problem from the other side (issuing short-lived certificates and putting in a system to automatically update them).