Hacker News Reader

Comment by durkie | Hacker News Reader

> Embedded devices that are pinned to certificates issued by a Symantec public root to communicate to resources over the Internet or Intranet. Replacing these certificates would result in immediate failures and the need to recode and reimage the firmware for these devices.

> Mobile applications that have pinned certificates. Replacing server certificates would require these applications to be recoded, recompiled and redistributed.

Are either of these relevant? Isn't google's proposal to eventually have Chrome stop trusting the Symantec CA system? That change seems like it would have no effect on 1) embedded devices that aren't running Chrome 2) things that already are in place that trust the CA.

View on HN

Imagine the embedded device or mobile app connects to a https://api.example.com/... and so does their web app. They need to use a new certificate for api.example.com, signed by a different CA root, because when Chrome tries to run the web app it won't trust the old certificate, nor a new cert signed by the old root. So they get a new cert signed by a different root so Chrome works, but then the embedded or mobile apps stop working.

In this case the story is more complicated - I think new certificates signed by existing Symantec CA roots would be trusted if their duration is 90 days or less. Historically, most CAs offered one, two, or three year duration. Presumably, the "big customers" would not accept the need to rotate their certificates for this purpose in less than 90 days, they need their 3 years because it takes over 90 days to get something through their bureaucracy. And presumably there are other things they can't do in 90 days, like update an embedded device configuration or firmware, or a mobile app.

Of course it depends on the particulars, but of course these "big customers" can't figure any particulars out in 90 days. But that's why Google proposed a slow sliding scale that would gradually reduce the max duration allowed over the course of a year, so random unknown stuff breaks more gradually throughout the year, not in one huge event like Symantec's blog post suggests.

An easier way around this sort of issue is to change their web app to use a different domain, and only put the new certificate from a different CA on that domain. It's not necessary to update every device.

Embedded devices => https://api.example.com (Symantec cert)

Browsers => https://new-api.example.com (New trusted cert)

Another approach is that if the devices are old enough they're probably using a deprecated version of TLS, so the existing https://api.example.com server could choose which certificate to issue based on the version of TLS offered by the client.

You have to have planned for this (or be lucky) though. Some people just put their api on www.example.com; assuming you have clients in the field which have pinned BIG CA, and you've got HSTS preloaded (because you're forward thinking). Unless you can detect Chrome N+1 from your existing clients during the TLS handshake, you have to pick between browsers or existing clients.

If Chrome ships this at the same time as re-enabling TLS 1.3 support, that would be a decent way to target, since presumably very few of your distributed clients are using TLS 1.3.

I know it's not going to help companies which pinned Symantec, but that's exactly why every serious guide to HPKP will have you pin two separate CAs.

True, but you know how it is ... the management of these companies would prefer to do nothing if it is possible. They'll put most of their efforts into that strategy.

I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.

Iirc you can have certs signed by multiple roots though, right? In which case these sites can just get their cert signed by the pinned symantec root and a real still-valid root. Nobody's stopping symantec from signing new certs, they just won't work in Chrome (and likely other browsers)

Or maybe I've misunderstood the situation.

Unfortunately, you can't keep multiple chains in a single X.509 certificate. While you can have a given key signed by multiple CAs, AIUI, this just lets you switch easily, not tell a client about both, and just work if they trust either CA.

Huh, okay. Surprised that's not possible. IIRC letsencrypt did something like this to bootstrap but I guess you can have a root sign a root, but not have two roots sign something and have both in the same cert.

I've always been of the opinion that the rogue/careless CA problem can be solved by mandating N root sigs and recommending M>N. In a system with multiple independent LetsEncrypt like entities this is doable. If a CA needs to be revoked you can do it in a much easier way here, since it's still ok to transitively allow sites with N-1 certs and one now-disallowed cert signed by that CA. Doesn't fix all the problems but it certainly removes the inertia behind kicking out bad CAs.

Looks like we'd need a x509 extension to do this then. :/

If the embedded devices are accessed over the net by Chrome, or access services that also need to be accessed by Chrome, then there is an issue.

But I don't think Google is going to be swayed by "you can't distrust us if we do wrong because too much depends on us" because if they do, it encourages laxness at big CAs.

It was either a bizarre misunderstanding on what will happen on Symantec's side, or "pinned" was used not in the technical meaning.

I could see someone translating "these devices use Symantec's server certs and serve web traffic" to "these devices are pinned to certs issued by Symantec". But if that's the case, they should pay more attention in announcements like this one...

Reply on news.ycombinator.com