Certificate Authority Compromise

[00:00:00]
>> Mike North: So the last little couple topics I want to talk about, we don't have an exercise for them, but I just want to close out about like topics that go beyond what we've done so far. The first is a Certificate Authority Compromise. We trust certificate authorities to identify the servers that we're talking to.

[00:00:21]
But occasionally they do get compromised. This really does happen. A little while back, this was in 2015, just two years ago, a certificate authority was compromised by a government and it was found that the form that this took was the government got ahold of the private key of a certificate root.

[00:00:46]
And so they could issue whatever certificates they want, if they wanted. Among the things that ended up happening were a wild card Google certificate was generated and it was found for sale on the dark web. So star.google.com, that's pretty bad. Another one was that a huge DDoS attack was directed at GitHub where basically the certificate was used to inject scripts into ad trackers, these little like doubleclick.net, these things that are ever-present on all of our pages.

[00:01:21]
Imagine if with your doubleclick.net you also got like, by the way every half a second please send a request to GitHub.com. And multiply that by a billion people or so, it starts to become very serious. When you trust a certificate authority, when you add a trust root to your operating system, you basically add anything that this assigns to the list of things that you trust.

[00:01:51]
That is the point of being an authority. You sign others' certificates and you're basically vouching for them, so you have to be careful about whose vouches you listen to. So the one thing that save Google in this case something called http public key pinning. And the idea behind this is, again it's another header that you add to response.

[00:02:13]
But the idea is rather than saying, for me to trust a certificate you must be signed by an authority who I trust. And you must have a name that aligns with the name of your domain. We basically say, okay that's a minimum requirement. But also here is a hash of my public key.

[00:02:34]
Remember this for a long time, and if you ever see a certificate that otherwise would seem valid but it's fingerprint does not match mine, do not trust it. You're not allowed to use it. So that's this pin value that we have in the public key pin's header. We add what is called the public key fingerprint to this.

[00:02:54]
And essentially, that means, no longer do we simply need that to be a valid certificate, but it has to be the very certificate that I have and I am holding. At that point, you know that you're not gonna have some malicious party who maybe has momentary control over your domain going out and requesting a bunch of other certificates.

[00:03:17]
And allowing users to basically emulating you or man-in-the-middling with the certificate and able to interfere with what's going on, it's only yours. So the problem here is almost nobody uses this standard. This survey here, and I had to dig down and research that raw data a little bit more cuz it's it seems like suspect cuz it's so dramatic.

[00:03:48]
375 domains in the top 1 million Alexa sites use public key pinning, 75 more are in report only mode where they don't enforce, they just sort of ping URL, whatever the detector problem. So it is a good idea to use this, but again make sure that you're ready to make the transition.

[00:04:08]
Same with HSTS, because now you've got this certificate and you can't use another one. So if something happened to that or if your private key were disclosed, now you're in a real bind because you can't use another's certificate. You've got a bunch of users that expect this one, right?

[00:04:29]
And so if it gets compromised, it becomes very difficult to revoke because now you've said browsers only trust the one that I have. And sometimes we need to generate new certificates ourselves. So finally I want to mention that we should treat certificates with extreme care as developers. I want to just tell a quick little story and I'm not trying to be criticizing or harping on anyone.

[00:04:55]
Vulnerabilities pop up everywhere. But this was one that was a collaboration between a lot of really smart developers, and just something slipped through the cracks. So if you use Webpack dev server specifically, Preact-CLI, or create react app, there was a vulnerability that just this summer, where there was just some private key mishandling that happened.

[00:05:19]
And it ended up prompting a bunch of users to trust a route where the private key was checked into GitHub. And so ultimately what that means is if you went to a Preact conference or something. You could man in the in the middle a large swath of people across any domain.

[00:05:38]
Totally undetected because you have the private key. We're needing to as UI developers get more and more into dealing with security issues like these. And it is important to sort of move any responsible speed and to make sure we do things the right way. These teams did a fantastic job of patching things and now what we get is an automatic certificate generation on a per-machine basis where there's a hidden certificate authority.

[00:06:10]
And then each application has its own leaf level certification that has a very short lifetime. It's a great solution and these teams showed how much they care about their users by addressing it so promptly. But this was the mistake where, basically, a self-signed certificate, by default, is a root, right?

[00:06:28]
It is a certificate root. So you can call it local host, but this can be used to sign other certificates. And so it's not really a one-off and trusting this has the effect of basically making it so that you trust anything at signs as well. And once the private key's exposed, anyone can create something signed by this.

[00:06:49]
So you would think that public key pinning would help us here because this is the same as a certificate authority compromise. But unfortunately, there in the spec is a loophole that's says, basically we ignore public key pending violations, if you've added this trust route to your machine deliberately.

[00:07:09]
Which in this case you would've done. So recognize that we as developers are pretty terrible about security. We are actually worse then the general public in terms of being vigilant about passwords and protecting SSH keys and secrets and things, reviewing all of the code we incorporate into our apps.

[00:07:30]
So recognize that we have a responsibility to our users to be a little bit more vigilant. And when things arise to respond in a prompt way that demonstrates that we take this kinda stuff seriously like those two teams did.