Ericsson said last week that "an initial root cause analysis" had indicated that the "main issue was an expired certificate in the software versions installed with these customers".
I suspect I'll never know, but I would be really interested to know what sort of certificate. Was this part of some larger public system or was it a purely internal PKI? If internal, did the certificates _do_ anything of value or did they purely make the system more fragile because somebody thought it ought to have certificates?
One of the arguments in favour of abusing the Web PKI to do other things is that tooling for the Web PKI is in a relatively good place. And a lot of other things that you might ideally hope exist actually DO exist for the Web PKI. There's independent oversight, somebody is actually reading those yawn-making audit reports, it isn't perfect but it's not just make believe either.
But on the other hand, the Web PKI is ours, and so if it suits us to change it we don't really care that this is annoying for your payment card systems, jet aeroplanes, nuclear submarines or whatever else you've duct-taped the Web PKI into. This was fun to watch with SHA-1 for example and is currently causing some fallout for names with underscores in (DNS can handle a name with an underscore in it but they're prohibited for hostnames. Lots of people ignored that, but that's their problem, not ours and they are not happy about that).
Ericsson have both their own PKI infrastructure[0], at least for software integrity checking (however that certificate is valid since March this year, and the CRL[1] it refers to is empty), in addition to using other certificate authorities for everything such as the hosting of websites to internal infrastructure[2]. I suspect it wasn't any of the above - rather it is the PKI that is used in running the IPSec networking done between carrier's RANs and other parts of core network[3], which is probably Ericsson's own internal CA.
Further expanding. GPRS Tunneling Protocol (GTP)[1] is what gets used to connected to the provider's data/voice network. This could be over any medium (wifi, GSM, UMTS, or LTE). It's likely this was the cert protecting GTP-C's ipsec tunnel[2] as without the ability to signal, pretty much everything on the network goes down.
Mmm, rather than the behaviour being "removed from browsers" the important thing is that Certificate Authorities were told that issuing such certificates could cause them to be distrusted as a whole by browsers.
Part of the reason to do this is that if CAs issue the certificates then their customers buy them, and create pressure to accept them. If none of the CAs are willing to issue this never comes up.
Another is "unknown unknowns". Security systems don't play well with undefined behaviour, if we explicitly forbid everything we don't want to exist that minimises the risk of such undefined behaviour anywhere in the certificate handling code getting exploited. It's a defence in depth.
One of the arguments in favour of abusing the Web PKI to do other things is that tooling for the Web PKI is in a relatively good place. And a lot of other things that you might ideally hope exist actually DO exist for the Web PKI. There's independent oversight, somebody is actually reading those yawn-making audit reports, it isn't perfect but it's not just make believe either.
But on the other hand, the Web PKI is ours, and so if it suits us to change it we don't really care that this is annoying for your payment card systems, jet aeroplanes, nuclear submarines or whatever else you've duct-taped the Web PKI into. This was fun to watch with SHA-1 for example and is currently causing some fallout for names with underscores in (DNS can handle a name with an underscore in it but they're prohibited for hostnames. Lots of people ignored that, but that's their problem, not ours and they are not happy about that).