Web Security

Web Security Defending Against Bad Certificates

Topics:
Check out a free preview of the full Web Security course:
The "Defending Against Bad Certificates" Lesson is part of the full, Web Security course featured in this preview video. Here's what you'd learn in this lesson:

To defend against an attack using bad certificates, Mike discusses setting the HTTP Strict-Transport-Security (HSTS) response header that tells browsers to only accept access through HTTPS.

Get Unlimited Access Now

Transcript from the "Defending Against Bad Certificates" Lesson

[00:00:00]
>> Mike North: So in terms of how we defend against this. We add another HTTP response header, and that is called strict transport security. What you're telling modern browsers here is that once you get the message, once you hear that we want to use strict transport security for this domain, you are not permitted to make a plain HTTP connection to that domain.

[00:00:22] And all subdomains, if you add this, includes subdomains option here. You're just not allowed to talk to anything there on that domain without encryption, you can't do it. You do wanna use includeSubDomains because you can still write to cookies. You can write to cookies from a subdomain onto the parent domain.

[00:00:44] And that exposes you to a variety of cookie-based attacks where you could still downgrade a user to plain HTTP and put some JavaScript in place that would mess with cookies, or just manipulate it directly. Yes?
>> Speaker 2: What's the significance of that number?
>> Mike North: The significance of that number is how long the instructions to forbid plain HTTP connections stand.

[00:01:08]
>> Speaker 2: No, right, but why that number?
>> Mike North: I think that's a year in seconds, looks like it. Someone Google 31 million seconds in years, should be 0.9 something. [LAUGH]
>> Mike North: So you want this to stand for a long time. You want this to stand for a long time.

[00:01:32] And this is great, this means that we can save users from themselves. But they have to get the message. They have to get that first response back from us. If they're a new user it's difficult for, there's no way for a developer to follow those instructions. There's no way for a browser to follow those instructions cuz they haven't received them yet.

[00:01:58] There is a fix for that. And what you do is you go to hstspreload.org, add your domain to a list. And all of these browsers, they take that giant list which is now tens of thousands of domains, and they include it in the source code for the browser itself.

[00:02:14] So on the right is a screenshot of some names near the top of the list. You see PayPal on there relatively recently, I'm sorry, relatively early. They've been on there for a while, not recently. Last Pass, I'm glad to see they're pretty high up. They were on the bandwagon early but basically now the next version of the browser that ships, like the next upgrade, that will include your domain.

[00:02:38] Now it comes pre-loaded with instructions to never talk to your domain over a plain HTTP connection, so it's a good idea to do this. Here is the game changer. The warning here does not have a proceed anyway button. The user does not have the option to take the risk, they are flat stopped.

[00:03:04] So as you may suspect, you want to make sure all of your ducks are in a row before you take the step and make this a permanent thing. Just because once you go there, plain HTTP is forbidden and you just need to make sure that there's no vital end point that you must communicate with or vital page that's on some strange subdomain that you would be potentially locking users out of.