12 ms·

I think the author is confusing three things: * Let's Encrypt - the actual CA * certbot - probably the mentioned python software * ACME - the protocol, which

by lub 6y ago

I think the author is confusing three things: * Let's Encrypt - the actual CA * certbot - probably the mentioned python software * ACME - the protocol, which had a change in the supported challenges Also there are alternatives for all three points. There are other CAs implementing ACME, there are other ACME clients and there are still CAs supporting the old 'send an email and click a link' domain validation.

jacquesm 6y ago
If you run something that issues 100 million or more certificates per year then backwards compatibility is not something that you toss out just because you can. Forcing that many web properties to upgrade their software (regardless of which party produced what) is discounting the combined effort that will take on the part of the users/sysadmins of those systems for something that could have just as easily been avoided. You deprecate interfaces like these but you don't just shut them down, especially not when they are still seeing major use. Just imagine that tomorrow IPV4 would be shut down because we've all had enough time to switch by now.
- 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
- b3lvedere 6y ago
  >Just imagine that tomorrow IPV4 would be shut down because we've all had enough time to switch by now. Honestly? I would absolutely love to watch that shitshow.
  - jacquesm 6y ago
    Can you please wait until I'm past my 'best before' date when you pull that particular plug?
  - tialaramex 6y ago
    The anticipated order of events goes something like this: Firstly the islands of IPv6 grow until they begin to dwarf the supposed generally interoperable ocean of IPv4. Big home ISPs, major CDNs, bulk hosts, AWS, and so on. Somewhere around this time you'd start to see events reported where "the Internet" was down for lots of people but it was the IPv4 Internet, which they are increasingly not using so they didn't actually notice. "Your Internet was down" "No it wasn't, I was on Facebook all afternoon" "Right yeah, but other than Facebook" "I watched a movie on Netflix" "OK, other than Facebook and Netflix" "I got a mail from Jeremy on GMail" "OK, other than Facebook and Netflix and GMail" "Not much of an Internet". Happy Eyeballs, the algorithm that allowed IPv6 to be deployed in dual stack environment successfully, now allows IPv4 to ramp down imperceptibly. Now, with the "ocean" so small, increasingly medium sized operators ignore it entirely, opting just to maintain translators at the edge of the IPv4 Internet, maybe your ISP does this, and you can't get "real" IPv4 addresses, although many of you already don't so this wouldn't be a change. The last major steps taken by "the Internet" look like this: The tier one providers who by that point are also more or less the global telecommunications companies, begin to deprecate IPv4 service, seeing it as a niche product that can better be serviced by specialists in your locale. Increasingly the only practical route from one IPv4 address to another IPv4 address is via two translators and IPv6. The RIRs discontinue management of the namespace/ numberspace for IPv4 and so the allocation of IPv4 addresses ceases to be globally co-ordinated. The IPv4 Internet no longer formally exists, just many islands of legacy IPv4 in an IPv6 ocean which happen to have mostly discontiguous addressing.
tialaramex 6y ago
Historically the Certbot software was named "letsencrypt" which certainly didn't make this easier to understand. The not-for-profit is named ISRG (Internet Security Research Group) and so that's the entity trusted to actually run the Certificate Authority. Let's Encrypt is in some sense branding for this their main (only?) activity the same way you can still buy certificates with Thawte branding even though Thawte hasn't really existed for many years. ACME is an IETF standardized protocol and so one of the things which has changed at Let's Encrypt is they gradually migrated from the ACME prototype they'd built and shipped to something that's (more or less) compliant to the IETF standard. This is akin to how today Google's own web sites can talk Google's QUIC protocol (sometimes referred to as "gQUIC") but Google intends to rip that out once the IETF QUIC standard is published and have their sites just speak the standard QUIC instead (there may be a brief overlap where they speak both but it's likely to be very short because maintaining two protocols is far from free)
- jacquesm 6y ago
  > Historically the Certbot software was named "letsencrypt" which certainly didn't make this easier to understand. And to this day strongly promoted (recommended first option) right from the letsencrypt.org starter page: https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/
  - ryandrake 6y ago
    Huge stumbling block and source of confusion for me. During the steep learning curve setting it up, I'd often search online for help/tutorials and they'd all reference "certbot" which I couldn't find anywhere on my system. As a newbie, I frequently said "WTF is this certbot thing, I'm using letsencrypt!" Wasn't clear at all. At some point during my system updates, /usr/bin/letsencrypt became a symbolic link to /usr/bin/certbot and it became obvious.
    - marcan_42 6y ago
      Sounds like you were running a distro that didn't keep its packages updated. By the time everyone was calling it 'certbot', well, it was called certbot.
nottorp 6y ago
Why should the author care? The point is the automated process isnt so automated. Incidentally, my imaps certificate isnt renewing automatically any more. Cant bring myself to debug it. Which just proves the TFAs point.
- notatoad 6y ago
  the author should care because he's writing an article about it, and taking the time to make sure you have the terminology correct is a good thing to do. but your main point is good: why should the average end user care. i've had the same frustrations with certbot - it tries to be too smart and too magic, and i want to better understand what it's doing. thankfully, the ansible letsencrypt module exists, and behaves in a much more understandable way to me, and that's why it's important to point out the distinction between letsencrypt and certbot - you don't have to use certbot, and everybody who uses letsencrypt should be aware of that. because the author is correct, certbot is kind of a turd, but letsencrypt is awesome and it would suck for people to stop using letsencrypt just because they don't like certbot.
  - nottorp 6y ago
    Ok what's ansible? :) Some script bunch that adds layers upon layers of VMs? My website is all static (and private use) so I don't really have a reason to run SSL on it. Make it hard, and I'll give up on the security theater.
    - chowells 6y ago
      Can we stop with this nonsense about static sites not needing https? It's not just there to protect secrecy. Integrity is vital with how many parties are happy to inject content into any unencrypted https connection these days. Browsers should be able to know that they're receiving the same bytes the server is sending.
      - nottorp 6y ago
        I don't know, maybe the solution is to get a pro consumer FCC in the US :)
twirlock 6y ago
Hi, there's this service called "letsencrypt" that everyone started using as a free CA -- because Google and Mozilla decided for everyone that you now have to deal with a CA to serve text over the internet, -- it's the reason everyone needs a bunch of extra ridiculous crap on their servers, and now all that extra ridiculous crap has a tendency to break.

by lub 6y ago

jacquesm 6y ago

If you run something that issues 100 million or more certificates per year then backwards compatibility is not something that you toss out just because you can. Forcing that many web properties to upgrade their software (regardless of which party produced what) is discounting the combined effort that will take on the part of the users/sysadmins of those systems for something that could have just as easily been avoided. You deprecate interfaces like these but you don't just shut them down, especially not when they are still seeing major use. Just imagine that tomorrow IPV4 would be shut down because we've all had enough time to switch by now.

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
b3lvedere 6y ago
>Just imagine that tomorrow IPV4 would be shut down because we've all had enough time to switch by now. Honestly? I would absolutely love to watch that shitshow.
- jacquesm 6y ago
  Can you please wait until I'm past my 'best before' date when you pull that particular plug?
- tialaramex 6y ago
  The anticipated order of events goes something like this: Firstly the islands of IPv6 grow until they begin to dwarf the supposed generally interoperable ocean of IPv4. Big home ISPs, major CDNs, bulk hosts, AWS, and so on. Somewhere around this time you'd start to see events reported where "the Internet" was down for lots of people but it was the IPv4 Internet, which they are increasingly not using so they didn't actually notice. "Your Internet was down" "No it wasn't, I was on Facebook all afternoon" "Right yeah, but other than Facebook" "I watched a movie on Netflix" "OK, other than Facebook and Netflix" "I got a mail from Jeremy on GMail" "OK, other than Facebook and Netflix and GMail" "Not much of an Internet". Happy Eyeballs, the algorithm that allowed IPv6 to be deployed in dual stack environment successfully, now allows IPv4 to ramp down imperceptibly. Now, with the "ocean" so small, increasingly medium sized operators ignore it entirely, opting just to maintain translators at the edge of the IPv4 Internet, maybe your ISP does this, and you can't get "real" IPv4 addresses, although many of you already don't so this wouldn't be a change. The last major steps taken by "the Internet" look like this: The tier one providers who by that point are also more or less the global telecommunications companies, begin to deprecate IPv4 service, seeing it as a niche product that can better be serviced by specialists in your locale. Increasingly the only practical route from one IPv4 address to another IPv4 address is via two translators and IPv6. The RIRs discontinue management of the namespace/ numberspace for IPv4 and so the allocation of IPv4 addresses ceases to be globally co-ordinated. The IPv4 Internet no longer formally exists, just many islands of legacy IPv4 in an IPv6 ocean which happen to have mostly discontiguous addressing.

tialaramex 6y ago

Historically the Certbot software was named "letsencrypt" which certainly didn't make this easier to understand. The not-for-profit is named ISRG (Internet Security Research Group) and so that's the entity trusted to actually run the Certificate Authority. Let's Encrypt is in some sense branding for this their main (only?) activity the same way you can still buy certificates with Thawte branding even though Thawte hasn't really existed for many years. ACME is an IETF standardized protocol and so one of the things which has changed at Let's Encrypt is they gradually migrated from the ACME prototype they'd built and shipped to something that's (more or less) compliant to the IETF standard. This is akin to how today Google's own web sites can talk Google's QUIC protocol (sometimes referred to as "gQUIC") but Google intends to rip that out once the IETF QUIC standard is published and have their sites just speak the standard QUIC instead (there may be a brief overlap where they speak both but it's likely to be very short because maintaining two protocols is far from free)

jacquesm 6y ago
> Historically the Certbot software was named "letsencrypt" which certainly didn't make this easier to understand. And to this day strongly promoted (recommended first option) right from the letsencrypt.org starter page: https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/
- ryandrake 6y ago
  Huge stumbling block and source of confusion for me. During the steep learning curve setting it up, I'd often search online for help/tutorials and they'd all reference "certbot" which I couldn't find anywhere on my system. As a newbie, I frequently said "WTF is this certbot thing, I'm using letsencrypt!" Wasn't clear at all. At some point during my system updates, /usr/bin/letsencrypt became a symbolic link to /usr/bin/certbot and it became obvious.
  - marcan_42 6y ago
    Sounds like you were running a distro that didn't keep its packages updated. By the time everyone was calling it 'certbot', well, it was called certbot.

nottorp 6y ago

Why should the author care? The point is the automated process isnt so automated. Incidentally, my imaps certificate isnt renewing automatically any more. Cant bring myself to debug it. Which just proves the TFAs point.

notatoad 6y ago
the author should care because he's writing an article about it, and taking the time to make sure you have the terminology correct is a good thing to do. but your main point is good: why should the average end user care. i've had the same frustrations with certbot - it tries to be too smart and too magic, and i want to better understand what it's doing. thankfully, the ansible letsencrypt module exists, and behaves in a much more understandable way to me, and that's why it's important to point out the distinction between letsencrypt and certbot - you don't have to use certbot, and everybody who uses letsencrypt should be aware of that. because the author is correct, certbot is kind of a turd, but letsencrypt is awesome and it would suck for people to stop using letsencrypt just because they don't like certbot.
- nottorp 6y ago
  Ok what's ansible? :) Some script bunch that adds layers upon layers of VMs? My website is all static (and private use) so I don't really have a reason to run SSL on it. Make it hard, and I'll give up on the security theater.
  - chowells 6y ago
    Can we stop with this nonsense about static sites not needing https? It's not just there to protect secrecy. Integrity is vital with how many parties are happy to inject content into any unencrypted https connection these days. Browsers should be able to know that they're receiving the same bytes the server is sending.
    - nottorp 6y ago
      I don't know, maybe the solution is to get a pro consumer FCC in the US :)

twirlock 6y ago

Hi, there's this service called "letsencrypt" that everyone started using as a free CA -- because Google and Mozilla decided for everyone that you now have to deal with a CA to serve text over the internet, -- it's the reason everyone needs a bunch of extra ridiculous crap on their servers, and now all that extra ridiculous crap has a tendency to break.