The Impending Doom of Expiring Root CAs and Legacy Clients

My last TV worked great for about 12 years. No way Panasonic would've kept supporting it that long.

Honestly, the thing I hate most about smart TVs, especially budget-conscious ones like the one I bought, is they have terribly slow processors so just to turn on the TV takes like 12 seconds. My old TV had a picture up within 3 seconds of turning it on.

Does any manufacturer make a good TV, or are they all smart now?

Servers, as Scott explains, are supposed to present a "chain" of certificates, in practice it's one leaf and then just anything else that might be useful for clients to assemble a trust path. If you do this everything works.

But lots of servers are misconfigured and present only the leaf certificate, not least because a lot of older software makes configuring the chain needlessly confusing/ complicated and it often "seems" to work anyway in some client software.

Given just a leaf, and a set of roots it trusts, a client can't make a useful trust decision, there's a gap. One option in this circumstance is to just give up and just tell the client's user this isn't secure. That's a poor UX.

Another idea is called AIA Chasing, many popular web browsers do this. When it can't get from the presented certificates to a trusted root the browser inspects the Authority Information Access field of a certificate to find a URL, hopefully this URL points to an intermediate certificate that plugs the gap. A problem with AIA chasing is that it reveals information about your browsing to the CA who otherwise have no reason to know. This privacy concern led Mozilla to reject AIA Chasing.

Yet another idea is to cache intermediate certificates for some period of time, then use that cache to fill any "gap" when making a trust path for other servers you connect to. This causes hard-to-predict errors for users, maybe the funny cat video site you enjoy works fine... unless you try to visit it first thing after turning on the PC. It can potentially represent a privacy risk within a session.

So ultimately Mozilla's workaround in current Firefox is to give Firefox a fairly complete set of intermediates, just as if it had cached them already. Essentially that right hand "embedded in browser" part of the diagram extends left to the intermediates too.

It made that happen through two means: Firstly m.d.s.policy required all root CAs to tell it about all unconstrained intermediates they had ever created, which was itself a revealing process because there sure are a lot of (mostly older) garbage intermediates that clearly are untrustworthy and shouldn't exist. More recently Certificate Transparency means any intermediates still in use must be in the CT logs because otherwise the leaf certificates won't be accepted by those logs, so Mozilla can "just" fetch that data.

The ecosystem needs to become a lot more robust and user friendly in general. Unfortunately, I’m just a user of certificates not a cryptographer, so I’m not really qualified to design security critical aspects of the system, but here are some rough features that I’m looking for:

- certificate warning date: a time period defined like expiry date that indicates that clients should warn of impending expiration but still click though

- Make it easier for people to acquire and renew certs. Let’s encrypt is an amazing start here, but it’s not a universal solution yet

- Formalize a way to solve the key distribution problem described in the article. Again, I’m not a security expert, but perhaps embedding a “replaces” concept into a certificate would work.

Any Internet-connected device is, in fact, a server, and must be seen and managed as one. This means strict control of installed services and, first and foremost, regular updates of all its software components (including firmware). If you acquire and install such a server which either can’t be updated or one which you know, realistically, won’t get any updates six months after installation, that’s asking to lose.

1. https://news.ycombinator.com/item?id=18019343

But coming back to TLS again: even if the old devices have an up-to-date root store, they typically have an outdated TLS stack which does not support TLS 1.2 ¯\_(ツ)_/¯ and this one is probably even harder to update. And since most of the companies want to drop TLS 1.1- support on their servers soon, this should also doom those outdated devices apart from the root stores issues.

Of course in some cases like domains it's necessary since the domain can be transferred, but this is solvable by DNSSEC+DANE.

For embedded devices - it's not just smart TVs but all IoT devices! - I think that the solution is a legal requirement: a condition of a device being able to be sold on the EU / US market must be the commit of the whole source tree and build chain including any and all key material for signing firmwares to the national library or other government-run secure escrow, to be released to the public once the manufacturer discontinues the product support. Similar to like you can't sell a product without adhering to the CE and electrical safety standards, manufacturers should not be able to sell products without having them certified for IT safety and e-waste/"planned obsolescence" issues!

Report URI should lead with this (it's not even mentioned on the front page)! It's super useful for every site, I can't think why anyone wouldn't want this. CSP monitoring on the other hand, which seems to be their focus, is a much harder sell, a pain to setup and maintain, and a bit questionable value in my opinion.

[1] https://report-uri.com/products/network_error_logging

This fits the prevailing narrative, and for all I know it's true, but Scott does not in fact illustrate it.

The "similar data" to a table of all Android API versions versus popularity turns out to be a chart of recent iOS versions in which everything that isn't current is just grouped as "Other" at 16.28%

Maybe if we ungrouped "Other" it would prove Scott's point, maybe not, we shan't find out answers in his article. If those "Other" iOS users are all running 10.3 it's a very different story than if they're on iOS 6...

Devices from 10 years ago are _already_ useless online.

Not only are the root certificates completely expired, but let's see which protocols does an openssl 0.9.8 build from a decade ago have in common with, say, current Gmail's IMAPS server: NONE.

Of course, we still have people working on our stuff. If it were some abandoned hardware product I could see this being a disaster.

I'm pretty good with TLS, but could use more hands-on time with openssl and PKI, especially a deeper understanding of certificate chaining issues. Would be interesting to know if the training is targeted at "total beginner" or "intermediate looking to be advanced"

I'll just mention glassfish here in case someone in the near future wonders why this or that application is failing: it has it's own cert store (different from the JVM one), and it is a bit out of date. Yes, I just ran into a github project whose last commit was 3 months ago (march 2020) and that wouldn't work with LE certificates, all because deep down the docker matrioshka, there was a glassfish with outdated certs.

Maybe root certs need to expire more often so implementors have to do OTA updates.

When are people going to learn that centralized cert authorities are just for commerce and only hurt the non-commercial web?