WebPKI and You
blog.brycekerley.net
blog.brycekerley.net
TLS is not The Web
Personally, I think we have a bigger problem on the PKI side, where Web PKI is very strong, but Internet PKI has been neglected. The recent move to remove client authentication is a good example.
> Now project that onto a TLS implementation that has to run on a Cortex M3 in some infrastructure device, little CPU, little RAM, no DNS, and the code gets updated when the hardware gets replaced after 10-20 years.
Also the OT world needs to accept that they can't have their cake and eat it too. If you need to be able to leave the same code running untouched for 10-20 years, you don't connect it to the internet. If you need it connected to the internet, you accept that it needs to be able to receive updates and potentially have those updates applied in a matter of days. Extremely strict external security controls can mitigate some of these situations but will never eliminate the need for there to be a rapid update process.
Also the OT world needs to accept that they can't have their cake and eat it too. If you need to be able to leave the same code running untouched for 10-20 years, you don't connect it to the internet
And before you say "even if the code is fine it's old crypto, it's insecure", when was the last time someone got pwned because they ran 25-year-old TLS 1.0?
I never said that's not possible, I said you can't design your systems to assume that it's one of those things. It is certainly possible that after 10-20 years a system might never have needed an update, but you didn't know that when it was built, purchased, or implemented and assuming that will be the case is undeniably irresponsible.
> And before you say "even if the code is fine it's old crypto, it's insecure", when was the last time someone got pwned because they ran 25-year-old TLS 1.0?
The correct answer there would be "none yet", and there's no guarantee it would ever happen, but there are known weaknesses so it's always a possibility. Again, not saying everything will need to be updated regularly, but it's not a good call to assume your thing will never need it.
Let's look at this from another angle. Presumably if you have a desire to expose a device to the internet as a whole it's because you either want it to be able to access external resources or you want external systems to be able to reach it, and the outside world has this tendency to move on over time if protocols are flawed, even if those flaws don't matter to your device. If there's a process for updating regularly, this is no big deal. If there isn't, your thing is going to get progressively more annoying to use wherever it needs to interact with systems outside of its control.
PKI as it stands is only a few steps from Google just deciding everyone must have a short-lived certificate from Google to be on the web.
If you don’t like a particular CA’s policies, you can choose a different one.
The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.
Here's a link to the minutes of the CABF meeting where the 25 certificate issuers and the 4 browser vendors—Apple, Google, Microsoft, Mozilla—agreed to reduce the validity period of TLS certificates unanimously [1].
> The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.
Actually, all of the browser vendors voted to reduce the validity period of TLS certificates from 825 days to 398 days at the September 2019 meeting. The ballot failed because a majority of the certificate issuers voted against it.
At the February 2020 CABF meeting, Apple announced it would unilaterally enforce the 398-day limit through its own root program policy. Starting September 1, 2020, any new TLS certificate with a validity period exceeding 398 days would simply not be trusted by Safari, macOS, or iOS.
This effectively made the 398-day limit a de facto standard — no CA would issue longer certificates if they’d be rejected by Apple devices [2].
|Date |Max Certificate Validity|SAN Data Reuse Period|
|-----------------|------------------------|---------------------|
|Before March 2026|398 days (current) |398 days |
|March 15, 2026 |200 days |200 days |
|March 15, 2027 |100 days |100 days |
|March 15, 2028 |47 days |10 days |
|March 15, 2029 |47 days |10 days (final) |
[2]: https://www.entrust.com/blog/2020/02/apple-announces-398-day...
The root programs who have their own CAs are also cloud providers, who arguably have a legitimate need for the CA. Or in Apple's case they have their own CA, but don't issue externally. They keep CA and root program separate.
You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be entirely automatic and zero configuration. The only additional service required is something like a STUN server so the public IP can be discovered and updated over time.
He is hosting his domain on a machine behind a reverse proxy over which he has no control (common enough); in this case the server will not know its own public IP as all resolves to (for example) `www.mydomain.com` will return the address of the proxy. To get the public IP he uses a STUN (or similar) public-facing service.
Not quite sure why he needs the public IP, though: from what I remember, the certs include the domain, not the IP.
What value is it when you are behind a proxy that can change IP? I mean, I'm going on the assumption that the proxy is not under his control, nor does it do the tls termination.
With a dynamic IP you can still detect a change, reissue a cert for the new IP and proceed automatically. There are self-hosting and machine-to-machine scenarios where this amount of autonomy could be welcome.