5 ms·

The reason the old interface was deprecated was that a security hole was found in the protocol. That is one of the few cases where it is reasonable to break bac

by ayende 6y ago

The reason the old interface was deprecated was that a security hole was found in the protocol. That is one of the few cases where it is reasonable to break backward compatability in this manner. Especially when dealing with certificates, where the security is one of the top reasons to want to go there.

jacquesm 6y ago
> that a security hole was found in the protocol Is there any supporting evidence for that because the only thing I have been able to find so far is that it was simply superseded by a newer version, mostly to support wildcard certs. What holes there were in V1 were closed within a day or two at most.
- lub 6y ago
  Why TLS-SNI-01 was disabled: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 https://community.letsencrypt.org/t/2018-01-09-issue-with-tl... Explanation that renewals will be disallowed after 1 year deprecation period: https://community.letsencrypt.org/t/march-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209 https://community.letsencrypt.org/t/march-13-2019-end-of-lif... And as you seem to be talking about ACMEv1/v2 instead of TLS-SNI-01 (which I originally thought); it will be supported as long as June 2021 in some cases: https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 https://community.letsencrypt.org/t/end-of-life-plan-for-acm... ACMEv2 was introduced, because it is much closer to the actual spec. Enforcing this ensures that there are actually ACME implementations out there, instead of proprietary "Let's Encypt ACME" implementations. https://tools.ietf.org/html/rfc8555 https://tools.ietf.org/html/rfc8555 https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md https://github.com/letsencrypt/boulder/blob/master/docs/acme... To me this seems like a sensible compromise between backwards compatibility and their mission for standardized automated renewals.
  - jacquesm 6y ago
    Yes, but that particular hole was fixed, wasn't it?
    - tialaramex 6y ago
      You can't "fix" the tls-sni-01 hole except by going back in a time machine to when Apache implements SNI and spraying all the involved developers with water. "No, bad developer, no biscuit. Do what the protocol specification actually says not whatever half-arsed nonsense you thought would work". If there were like six web servers in the whole world that got this wrong, we could say "Fix those servers, fools" and sleep soundly knowing that those six servers are all that's affected. But Apache makes the scope too big to do that reasonably. It's a judgement call, but in this case the call was very easy.
      - jacquesm 6y ago
        I don't see what that has to do with me because there is no Apache on that server (just Nginx).
        tialaramex 6y ago
        But Let's Encrypt is part of the Web PKI, and the Web PKI is for all names on the public Internet, not just any operated by Jacques Mattheij. You sought certificates from the Web PKI, probably because you wanted somebody else other than Jacques Mattheij to trust them. A large fraction of public Internet HTTPS servers run Apache, which means tls-sni-01 is unsafe for a non-trivial fraction of names, which means we need to tell Certificate Authorities not to use this method or those like it. Specifically 3.2.2.4.10. TLS Using a Random Number has to be approached differently if it's to be attempted. The tls-alpn-01 challenge implements 3.2.2.4.10 using ALPN instead of SNI and appears to be safe in practice.
        jacquesm 6y ago
        There was this joke when I was a fledgling programmer 35 years ago: If engineers would build bridges the way programmers build software the first woodpecker to come along would destroy civilization as we know it. I think your comment is a nice illustration of that. To me if a piece of software has a problem then it is that piece of software that should be fixed, not to push the burden onto everybody else as well. That's just so wrong. But that does not mean I don't follow your reasoning and understand why this decision was made, still, the amount of waste here is incredible.
- tialaramex 6y ago
  The article says "then the challenge protocol was changed" so that's why people are talking about the protocol. The only challenge which changed was tls-sni-01 which was removed and eventually replaced with tls-alpn-01 The tls-sni-01 challenge is safe unless there are bulk hosting sites whose web server for some crazy reason accepts SNI for names that are nonsensical, and then serves up answers chosen by an attacker who is also one of the customers on that server instead of from a victim on the same server. Unfortunately somebody actually did ship software which is crazy in that specific way, and it's named Apache HTTPD server. You might have heard of it. So that's a problem. So, Let's Encrypt deprecated this challenge and you can no longer use it. They did tell everybody affected, by email to the address they provided for contact. Since they are not psychic they don't have a way to reach out to people who felt they didn't need to be contacted. I suspect given you mention wildcards you're thinking of ACMEv2 which isn't a challenge protocol. But again there were plenty of email notifications about the ACMEv2 upgrade, and you've in fact encountered exactly the anticipated scenario, you decided to build out a new thing using the old service and it told you not to do that. Your old things are still working, for almost another year, after already two years notice that this was going away, it's just that new things can't be launched against this already deprecated service.
  - jacquesm 6y ago
    I did provide an email address, never got any mail (I did actually check that). > it's just that new things can't be launched against this already deprecated service. Yes, I noticed. So, I now have the entirely unforced option of re-imaging a machine that is working just fine besides this little detail, which is in fact just one very small thing of a whole pile of much bigger things that run on that particular box. Not to mention migrating twentynine years of email to a new mail server. I'm sure there is a lesson in there somewhere, but I'm not sure I'm overly receptive today, I had a lot of other stuff on my agenda.
    - sergiosgc 6y ago
      If you let a server lag in OS version, at some point in time you're going to hit this kind of problem. If not with Let's Encrypt, then with some other dependency. I know, I've been in the exact same spot. I just don't blame the dependency, and included server OS updates as part of a yearly maintenance cycle.

by ayende 6y ago

jacquesm 6y ago

> that a security hole was found in the protocol Is there any supporting evidence for that because the only thing I have been able to find so far is that it was simply superseded by a newer version, mostly to support wildcard certs. What holes there were in V1 were closed within a day or two at most.

lub 6y ago
Why TLS-SNI-01 was disabled: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 https://community.letsencrypt.org/t/2018-01-09-issue-with-tl... Explanation that renewals will be disallowed after 1 year deprecation period: https://community.letsencrypt.org/t/march-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209 https://community.letsencrypt.org/t/march-13-2019-end-of-lif... And as you seem to be talking about ACMEv1/v2 instead of TLS-SNI-01 (which I originally thought); it will be supported as long as June 2021 in some cases: https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 https://community.letsencrypt.org/t/end-of-life-plan-for-acm... ACMEv2 was introduced, because it is much closer to the actual spec. Enforcing this ensures that there are actually ACME implementations out there, instead of proprietary "Let's Encypt ACME" implementations. https://tools.ietf.org/html/rfc8555 https://tools.ietf.org/html/rfc8555 https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md https://github.com/letsencrypt/boulder/blob/master/docs/acme... To me this seems like a sensible compromise between backwards compatibility and their mission for standardized automated renewals.
- jacquesm 6y ago
  Yes, but that particular hole was fixed, wasn't it?
  - tialaramex 6y ago
    You can't "fix" the tls-sni-01 hole except by going back in a time machine to when Apache implements SNI and spraying all the involved developers with water. "No, bad developer, no biscuit. Do what the protocol specification actually says not whatever half-arsed nonsense you thought would work". If there were like six web servers in the whole world that got this wrong, we could say "Fix those servers, fools" and sleep soundly knowing that those six servers are all that's affected. But Apache makes the scope too big to do that reasonably. It's a judgement call, but in this case the call was very easy.
    - jacquesm 6y ago
      I don't see what that has to do with me because there is no Apache on that server (just Nginx).
      - tialaramex 6y ago
        But Let's Encrypt is part of the Web PKI, and the Web PKI is for all names on the public Internet, not just any operated by Jacques Mattheij. You sought certificates from the Web PKI, probably because you wanted somebody else other than Jacques Mattheij to trust them. A large fraction of public Internet HTTPS servers run Apache, which means tls-sni-01 is unsafe for a non-trivial fraction of names, which means we need to tell Certificate Authorities not to use this method or those like it. Specifically 3.2.2.4.10. TLS Using a Random Number has to be approached differently if it's to be attempted. The tls-alpn-01 challenge implements 3.2.2.4.10 using ALPN instead of SNI and appears to be safe in practice.
        jacquesm 6y ago
        There was this joke when I was a fledgling programmer 35 years ago: If engineers would build bridges the way programmers build software the first woodpecker to come along would destroy civilization as we know it. I think your comment is a nice illustration of that. To me if a piece of software has a problem then it is that piece of software that should be fixed, not to push the burden onto everybody else as well. That's just so wrong. But that does not mean I don't follow your reasoning and understand why this decision was made, still, the amount of waste here is incredible.
tialaramex 6y ago
The article says "then the challenge protocol was changed" so that's why people are talking about the protocol. The only challenge which changed was tls-sni-01 which was removed and eventually replaced with tls-alpn-01 The tls-sni-01 challenge is safe unless there are bulk hosting sites whose web server for some crazy reason accepts SNI for names that are nonsensical, and then serves up answers chosen by an attacker who is also one of the customers on that server instead of from a victim on the same server. Unfortunately somebody actually did ship software which is crazy in that specific way, and it's named Apache HTTPD server. You might have heard of it. So that's a problem. So, Let's Encrypt deprecated this challenge and you can no longer use it. They did tell everybody affected, by email to the address they provided for contact. Since they are not psychic they don't have a way to reach out to people who felt they didn't need to be contacted. I suspect given you mention wildcards you're thinking of ACMEv2 which isn't a challenge protocol. But again there were plenty of email notifications about the ACMEv2 upgrade, and you've in fact encountered exactly the anticipated scenario, you decided to build out a new thing using the old service and it told you not to do that. Your old things are still working, for almost another year, after already two years notice that this was going away, it's just that new things can't be launched against this already deprecated service.
- jacquesm 6y ago
  I did provide an email address, never got any mail (I did actually check that). > it's just that new things can't be launched against this already deprecated service. Yes, I noticed. So, I now have the entirely unforced option of re-imaging a machine that is working just fine besides this little detail, which is in fact just one very small thing of a whole pile of much bigger things that run on that particular box. Not to mention migrating twentynine years of email to a new mail server. I'm sure there is a lesson in there somewhere, but I'm not sure I'm overly receptive today, I had a lot of other stuff on my agenda.
  - sergiosgc 6y ago
    If you let a server lag in OS version, at some point in time you're going to hit this kind of problem. If not with Let's Encrypt, then with some other dependency. I know, I've been in the exact same spot. I just don't blame the dependency, and included server OS updates as part of a yearly maintenance cycle.