6 ms·

So it's being pushed because it'll be easier for a few big players in industry. Everybody else suffers.

ignoramous 2y ago
Unless I misunderstood, GP mentions that the problem stems from WebPKI's central role in server identity management. Think of these cert lifetimes as forcefully being signed out after 47 days of being signed in. > easier for a few big players in industry Not necessarily. OP mentions, more certs would mean bigger CT logs. More frequent renewals mean more load. Like with everything else, this seems like a trade-off. Unfortunately, for you & I, as customers of cert authorities, 47 days is where the now the agreed cut-off is (not 42).
tptacek 2y ago
Or, equivalently, it's being pushed because customers of "big players", of which there are a great many, are exposed to security risk by the status quo that the change mitigates.
mcpherrinm 2y ago
It makes the system more reliable and more secure for everyone. I think that's a big win. The root reason is that revocation is broken, and we need to do better to get the security properties we demand of the Web PKI.
- fiddlerwoaroof 2y ago
  It makes systems more reliable and secure for system runners that can leverage automation for whatever reason. For the same reason, it adds a lot of barriers to things like embedded devices, learners, etc. who might not be able to automate TLS checks.
  - thayne 2y ago
    Putting a manually generated cert on an embedded device is inherently insecure, unless you have complete physical control over the device. And as mentioned in other comments, the revocation system doesn't really work, and reducing the validity time of certs reduces the risks there. Unfortunately, there isn't really a good solution for many embedded and local network cases. I think ideally there would be an easy way to add a CA that is trusted for a specific domain, or local ip address, then the device can generate its own certs from a local ca. And/or add trust for a self-signed cert with a longer lifetime.
    - fiddlerwoaroof 2y ago
      This is a bad definition of security, I think. But you could come up with variations here that would be good enough for most home network use cases. IMO, being able to control the certificate on the device is a crucial consumer right
    - throwaway2037 2y ago
      Real question: What is the correct way to handle certs on embedded devices? I never thought about it before I read this comment.
      - steve_gh 2y ago
        There are many embedded devices for which TLS is simply not feasible. For remote sensing, when you are relying on battery power and need to maximise device battery life, then the power budget is critical. Telemetry is the biggest drain on the power budget, so anything that means spending more time with the RF system powered up should be avoided. TLS falls into this category.
        dcow 2y ago
        Yes, but the question is about devices that can reasonably run TLS. The answer is local acme with your router issuing certs for your ULA prefix or “home zone” domain.
        thayne 2y ago
        > The answer is local acme with your router issuing certs for your ULA prefix or “home zone” domain. That would be nice. But most people don't have a router running an ACME server.
        dcow 2y ago
        It should become a thing
- zmmmmm 2y ago
  > It makes the system more reliable It might in theory but I suspect it's going to make things very very unreliable for quite a while before it (hopefully) gets better. I think probably already a double digit fraction of our infrastructure outages are due to expired certificates. And because of that it may well tip a whole class of uses back to completely insecure connections because TLS is just "too hard". So I am not sure if it will achieve the "more secure" bit either.
- dd82 2y ago
  And rather than fix the issues with revocation, its being shuffled off to the users. Good example of enshittification
da_chicken 2y ago
It's a decision by Certificate Authorities, the ones that sell TLS certificate services, and web browser vendors. One benefits from increased demand on their product, while the other benefits by increasing the overhead on the management of their software, which increases the minimum threshold to be competitive. There are security benefits, yes. But as someone that works in infrastructure management, including on 25 or 30 year old systems in some cases, it's very difficult to not find this frustrating. I need tools I will have in 10 years to still be able to manage systems that were implemented 15 years ago. That's reality. Doubtless people here have connected to their router's web interface using the gateway IP address and been annoyed that the web browser complains so much about either insecure HTTP or an unverified TLS certificate. The Internet is an important part of computer security, but it's not the only part of computer security. I wish technical groups would invest some time in real solutions for long-term, limited access systems which operate for decades at a time without 24/7 access to the Internet. Part of the reason infrastructure feels like running Java v1.3 on Windows 98 is because it's so widely ignored.
- tptacek 2y ago
  It is reasonable for the WebPKI of 2025 to assume that the Internet encompasses the entire scope of its problem.
- kcb 2y ago
  It astounds me that there's no non-invasive local solution to go to my router or whatever other appliances web page without my browser throwing warnings and calling it evil. Truly a fuck up(purposeful or not) by all involved in creating the standards. We need local TLS without the hoops.
  - fiddlerwoaroof 2y ago
    I wonder what this would look like: for things like routers, you could display a private root in something like a QR code in the documentation and then have some kind of protocol for only trusting that root when connecting to the router and have the router continuously rotate the keys it presents.
deleted 2y ago
[deleted]
yellowapple 2y ago
"Suffer" is a strong word for those of us who've been using things like Let's Encrypt for years now without issue.

Unless I misunderstood, GP mentions that the problem stems from WebPKI's central role in server identity management. Think of these cert lifetimes as forcefully being signed out after 47 days of being signed in. > easier for a few big players in industry Not necessarily. OP mentions, more certs would mean bigger CT logs. More frequent renewals mean more load. Like with everything else, this seems like a trade-off. Unfortunately, for you & I, as customers of cert authorities, 47 days is where the now the agreed cut-off is (not 42).

tptacek 2y ago

Or, equivalently, it's being pushed because customers of "big players", of which there are a great many, are exposed to security risk by the status quo that the change mitigates.

mcpherrinm 2y ago

It makes the system more reliable and more secure for everyone. I think that's a big win. The root reason is that revocation is broken, and we need to do better to get the security properties we demand of the Web PKI.

fiddlerwoaroof 2y ago
It makes systems more reliable and secure for system runners that can leverage automation for whatever reason. For the same reason, it adds a lot of barriers to things like embedded devices, learners, etc. who might not be able to automate TLS checks.
- thayne 2y ago
  Putting a manually generated cert on an embedded device is inherently insecure, unless you have complete physical control over the device. And as mentioned in other comments, the revocation system doesn't really work, and reducing the validity time of certs reduces the risks there. Unfortunately, there isn't really a good solution for many embedded and local network cases. I think ideally there would be an easy way to add a CA that is trusted for a specific domain, or local ip address, then the device can generate its own certs from a local ca. And/or add trust for a self-signed cert with a longer lifetime.
  - fiddlerwoaroof 2y ago
    This is a bad definition of security, I think. But you could come up with variations here that would be good enough for most home network use cases. IMO, being able to control the certificate on the device is a crucial consumer right
  - throwaway2037 2y ago
    Real question: What is the correct way to handle certs on embedded devices? I never thought about it before I read this comment.
    - steve_gh 2y ago
      There are many embedded devices for which TLS is simply not feasible. For remote sensing, when you are relying on battery power and need to maximise device battery life, then the power budget is critical. Telemetry is the biggest drain on the power budget, so anything that means spending more time with the RF system powered up should be avoided. TLS falls into this category.
      - dcow 2y ago
        Yes, but the question is about devices that can reasonably run TLS. The answer is local acme with your router issuing certs for your ULA prefix or “home zone” domain.
        thayne 2y ago
        > The answer is local acme with your router issuing certs for your ULA prefix or “home zone” domain. That would be nice. But most people don't have a router running an ACME server.
        dcow 2y ago
        It should become a thing
zmmmmm 2y ago
> It makes the system more reliable It might in theory but I suspect it's going to make things very very unreliable for quite a while before it (hopefully) gets better. I think probably already a double digit fraction of our infrastructure outages are due to expired certificates. And because of that it may well tip a whole class of uses back to completely insecure connections because TLS is just "too hard". So I am not sure if it will achieve the "more secure" bit either.
dd82 2y ago
And rather than fix the issues with revocation, its being shuffled off to the users. Good example of enshittification

da_chicken 2y ago

It's a decision by Certificate Authorities, the ones that sell TLS certificate services, and web browser vendors. One benefits from increased demand on their product, while the other benefits by increasing the overhead on the management of their software, which increases the minimum threshold to be competitive. There are security benefits, yes. But as someone that works in infrastructure management, including on 25 or 30 year old systems in some cases, it's very difficult to not find this frustrating. I need tools I will have in 10 years to still be able to manage systems that were implemented 15 years ago. That's reality. Doubtless people here have connected to their router's web interface using the gateway IP address and been annoyed that the web browser complains so much about either insecure HTTP or an unverified TLS certificate. The Internet is an important part of computer security, but it's not the only part of computer security. I wish technical groups would invest some time in real solutions for long-term, limited access systems which operate for decades at a time without 24/7 access to the Internet. Part of the reason infrastructure feels like running Java v1.3 on Windows 98 is because it's so widely ignored.

tptacek 2y ago
It is reasonable for the WebPKI of 2025 to assume that the Internet encompasses the entire scope of its problem.
kcb 2y ago
It astounds me that there's no non-invasive local solution to go to my router or whatever other appliances web page without my browser throwing warnings and calling it evil. Truly a fuck up(purposeful or not) by all involved in creating the standards. We need local TLS without the hoops.
- fiddlerwoaroof 2y ago
  I wonder what this would look like: for things like routers, you could display a private root in something like a QR code in the documentation and then have some kind of protocol for only trusting that root when connecting to the router and have the router continuously rotate the keys it presents.

deleted 2y ago

[deleted]

yellowapple 2y ago

"Suffer" is a strong word for those of us who've been using things like Let's Encrypt for years now without issue.