Bad Certificate

[00:00:00]
>> Mike North: So, let's say we go through those steps, and we're using HTTPS. What we can do, though, is, we can even try to create a slightly broken HTTPS connection here. So the users now, they've got this plugin, they clicked their bookmark that was already HTTPS. So we can't really downgrade them quite as easily.

[00:00:23]
But what we can do is forge a certificate. And we're gonna take advantage of the fact that there is something called server name indication. I've been mispronouncing that for a while. Server name indication, and basically, that means that when you begin TLS handshake, you announce the domain that you're attempting to talk to.

[00:00:45]
And this is an important part of how we can have multi-tenancy and things like Cloudflare, which is like, they do a great job at providing some, especially DDOS protection for sites. But if you look at a certificate for something that is operating through Cloudflare, you'll see that the bottom of the certificate, it's about a list of 100 different domains that that same certificate is used for, right?

[00:01:10]
It will work across all of those domains. And in order to disambiguate between which one are you talking about, you have to basically announce your intention to talk to that particular domain. We can use that for evil by basically saying, so the user asks attacker, like, I'm looking to talk to the newyorktimes.com.

[00:01:33]
Are you the newyorktimes.com? And then it very quickly creates the certificate and says, yes, of course I am. Now this is a broken certificate. You're gonna get a warning here. But you can create one where the name matches. It'll just say, this wasn't created by a trusted root.

[00:01:48]
But if you were to click on it, it can say nytimes.com, it can have the address in there of the New York Times headquarters. It can look very official, except for the fact that something's wrong with it in a way that most users would not be able to understand.

[00:02:03]
It's not signed by a trusted route, but it looks complete, there's no misspellings, it looks fine. So yeah, even if you don't see anything else about that initial HTTPS request, cuz you won't be able to see, for example, which path they're trying to visit or the payload that they're trying to send or query params.

[00:02:29]
How much would you really suspect just getting kicked back to the root of o domain. Like you clicked on a bookmark, and it kicked me out, and I'm at the homepage of the app, that is not suspicious behavior. So we don't really need that in order to do this.

[00:02:43]
This is the message that users will be presented with. Google has done a lot of research, and I'm sure other browser teams have done research too. But Google has worked with universities and experts in this field to try to make this as effective a warning as possible. And you see that it's red, and we've got two buttons that say Proceed anyway and Back to safety.

[00:03:10]
>> Mike North: But we have a problem here in that we don't maintain certificates very well as developers. So a lot of domains have problems with certificates. And effectively, if you've ever heard the story of the boy who cried wolf, we have trained users through false alerts and false warnings.

[00:03:32]
We've trained them to just click through this stuff. And as a result,
>> Mike North: Chrome has been able to, through its vast improvements, reduce the number of people who are wiling to click through this kind of thing from 70% down to 42. So just less than half of users are kinda just gonna proceed anyway, right?

[00:03:56]
If you catch them when they're in a rush, say it's build some social engineering around it. There's this sweepstakes prize, but in the next 30 seconds after receiving this email, you have to go through and you have to click this link. And then you throw that warning in front of them.

[00:04:15]
If you've really managed to convince someone that the time is running out, they're absolutely gonna choose convenience with risk. That is the choice people typically make. But that's a much higher number than most people would imagine. 42% of people click through that kind of thing. And then even those who click through, half of them don't really understand the risk that they're taking on, right?

[00:04:41]
What could happen by way of installing something on my machine, versus visiting a site where there's an error, versus visiting something with plain HTTP, versus public Wi-Fi? Your users do not understand the risk exposure and how it varies with all those different things.