Introducing HTTPS Downgrade

[00:00:00]
>> Mike North: Let's say that, we get this certificate in place, right? We get this certificate in place, we're serving over HTTPS. What we want to see is, like now that we should distribute links that are HTTPS, we should encourage users to visit our new secure URL. But what can happen is a man in the middle can stage what is called a HTTPS downgrade attack.

[00:00:27]
So it's fantastic that everyone's moving to HTTPS, we're at 56%. We're moving more and more towards a fully-encrypted web. And what do you do about those plain HTTP connections is typically, you just want to redirect users from HTTP to HTTPS. This is our raising awareness marketing material to try to get people to bother to setup a certificate.

[00:00:57]
And to use a secure connection to their users, so this seems great. But you should still have plain HTTP links, right, they have bookmarks. Occasionally, people still spread these. Occasionally, they still pop in search results. And that initial request comes over HTTP, and this is what we do.

[00:01:16]
This is how we typically handle that. You ask for HTTP, I'm going to redirect you. A 301 redirect is a permanent redirect. So that basically tells the browser, I'm sending you here and remember for next time, I'm always going to send you here. You can in the future, just go straight there, don't bother to ask me for directions.

[00:01:39]
However, what if we get into the middle of this as an attacker. What we can do is stage this attack. This is called HTTPS Downgrading. There's a library that is basically, made for this called SSL Strip, or SSL Split is another one. But the idea is, we maintain an insecure session with the user.

[00:02:04]
And maintain a secure session with the server. So we're actually, the ones that are communicating securely with the server. And the server will think that it has an https connection to the client. It will say everything looks good. I'm encrypting everything. Someone's listening on the other side, but it's really the attacker.

[00:02:22]
And then, we're basically creating insecure proxy that downgrades that connection to an insecure one. And then, of course we can mend in the middle both ways. Because in this situation, we're holding that session key it was us who initiated that TLS handshake. It was us, the attacker who has created a means of securely communicating with the server.

[00:02:47]
And so, we can man in the middle this way as well as we ever could. So for people out there, for your users, you want to encourage them to try and not get into this situation.