Hacker News Reader

Comment by kondbg | Hacker News Reader

This isn't a CA certificate -- it is missing the CA basic constraints as well as missing the "certificate sign" key usage from X509v3, so most TLS libraries will not validate a chain that is signed by this certificate.

View on HN

"most TLS libraries" is vague. Microsoft and Apple each include one with their OS. The Microsoft one definitely accepts total garbage as a valid CA root. I know because my employer pushed such a root to enable their MitM proxy and it worked fine... in Windows (and thus IE/ Edge). They had to replace it because Firefox and other systems threw a fit.

I'm happy to be proved wrong about this, but my experience tells me "most TLS libraries" is misleading even if technically true.

If you add a non-CA enabled certificate to the Trust store and a TLS library decides to trust it to sign a cert chain, that TLS library is horribly broken and needs a critical CVE. File a bug an earn a $10k bounty, but I’m guessing this is FUD and Blizzard did nothing wrong here and exposed exactly no one to any kind of risk.

In fact it appears they did exactly the right thing to get https working correctly in their mixed-mode (localhost + outside world) environment.

The fact you think this makes Microsoft's TLS library (SChannel) "horribly broken" doesn't magically mean I get a $10k bounty award. Microsoft considers that if you put a cert which lacks CA:TRUE into your local trust store you must know what you're doing and want to trust it as a CA anyway. They're entitled to whatever opinion they want, and don't have to pay third parties just because somebody on HN disagrees.

Now, if you want you can argue that Blizzard weren't to know this would happen. And that, depending on what else they've done this might be safe anyway, but I wasn't commenting on either of those, only pointing out that SChannel doesn't care about basic constraints on trusted roots.

Good catch.

Reply on news.ycombinator.com