There's also a Czech version of this talk.
HTTPS is great, until it's stripped.
Datum a akce
- HTTP Strict Transport Security
HTTP Strict Transport Security (HSTS) provides secure transport of data, by removing the possibility of HTTPS stripping. (These slides include added speaker notes. Pictured above is a Czech police car from the communist era.)
When writing this talk, I've stumbled on this Czech website. It has a lot of info about a data inbox which is used by citizens for official communication with various Czech government departments. The note on the top was a bit of a surprise for me. It's repeated on the next slide.
- To access your data inbox, manually enter https://www.mojedatovaschranka.cz into the address bar of your browser
It says „to access your data inbox, manually enter the following HTTPS address into the address bar of your browser“. I think this is how HTML version Zero looked like, that's HTML sans HT.
So I tried and entered the address into my browser. Just like any other regular user, I forgot to type the
https://scheme at the beginning.
Luckily the browser did it for me. It put just
http://in and not
https://but that's fine, I'll eventually end up there. I'll be redirected, hopefully.
I guess I was not redirected. Now what? Oh, wait, let's see what does it say.
„Because of security, the data inbox portal is accessible only by using an encrypted connection.“
„You should create a bookmark leading directly to the secure login page at https://www.mojedatovaschranka.“
Huh, no link?
„You'll be redirected to secure login page in 10 seconds. If you weren't click here.“
Ok, finally, here's a link.
- Do Not Perform Redirects from Non-TLS Page to TLS Login Page
Seems this update your bookmarks thing comes from this obsolete OWASP recommendation which says that you should not perform redirects from HTTP to HTTPS login page.
- This recommendation has been removed.
Yeah, it was. Already on 2011–10–16. Now it's completely gone from the Transport Layer Protection Cheat Sheet.
- You'll be redirected to secure login page in 10 seconds
„You'll be redirected to secure login page in 10 seconds. If you weren't click here.“ Before the recommendation was removed, it said that you should not perform redirects. But the system will eventually redirect the user.
As an extra bonus, the message which says „You'll be redirected to secure login page in 10 seconds“ contains a grammatical mistake. I won't go into details, free Czech lesson is not included in this slide deck, I'm sorry.
- SSL Strip
The reason for the bookmark recommendation is this. It's called the SSL Strip attack and it's a Man-in-the-Middle type of an attack. The user wants to load a website, so she types
https://schema into the address bar of her browser. The browser sends unencrypted request to the server, which responds with a redirection to
https://www.example.com. This initial HTTP request can be intercepted by a bad guy who re-sends it to the server and so the server will send the redirection response to the bad guy. He won't relay the response but instead sends the HTTPS request himself. Server accepts the HTTPS request and will now happily send the encrypted page back to the bad guy. He decrypts the page, changes all the links and form actions from
http://and eventually sends it back to the original user. She sees a page she wanted to see, the domain is correct, too. She won't notice that the page was not loaded over an encrypted connection, the chances are that she doesn't even know whether the page should be loaded over HTTPS. So she puts in her username and password and submits the form over HTTP. The bad guy will sniff the data and now has her credentials.
„but sslstrip has changed that to HTTP“: https://youtu.be/KKNKKbn2Tm0 in Czech with English subtitles
The idea to create a bookmark to the secure site, or not to perform redirects is foolish. There is a better way to do it now, just use HTTP Strict Transport Security (HSTS). HSTS is supported in Firefox and Chrome, in both since version 4, in Microsoft Superman/Spartan/Edge, and IE 11 on Win7 and higher since June 2015. It's also supported in some other browsers.
- Status Code: 307 Internal Redirect
With HSTS, the browser won't ever send the request to the website over HTTP. Instead, it will perform internal redirection, and then will send the request over HTTPS. This is how it looks like in Chrome DevTools. The 307 status code comes from the browser internally, not from the server. As a user, you won't see much difference between an HSTS-enabled site and a regular HTTPS site, though the loading might be a bit faster because the HTTP request is not sent to the server.
Strict-Transport-Security: max-age=31536000; includeSubDomains
HSTS is an HTTP header issued by the server. After receiving an HSTS header, the browser will perform internal redirects (no requests to server) from
https://for the next
includeSubdomainsdirective tells the browser to apply HSTS policy for all the subdomains, too. Don't forget to set the header for
example.com, not just for
www.example.com. Also verify that all subdomains work over HTTPS. A
max-age=0will make the browser (Firefox-only feature) forget the HSTS policy for the host.
- TOFU – Trust-On-First-Use
The HSTS header can be sent from the server only over trusted HTTPS, the browser must ignore the header if received over HTTP or untrusted connection. We have to trust the network with the first HTTP request and believe that nobody will strip the HTTP-to-HTTPS redirection. Such model is called Trust-On-First-Use.
The TOFU model leaves the user open to a bootstrap MITM vulnerability when the user manually enters or follows an HTTP link to an unknown HSTS host. To protect against such vulnerability, browsers offer a so-called preload list. Once a site is preloaded into the browser, even the very first HTTP request will be internally redirected to HTTPS because the browser knows the HSTS policy for the host right since the installation.
Strict-Transport-Security: max-age=…; includeSubDomains; preload
To make it to the preload list you need to add a preload directive to the HSTS header issued by your server and then submit your site manually for inclusion in the preload list. Various versions of the list are used by Chrome, Firefox, IE/Edge, and Tor Browser. Once preloaded there's no easy way out. You can email the list maintainer and ask for removal but it takes a while.
So for testing, set your
max-agelow, just few minutes, and don't use
preload. Really, I mean it, otherwise somebody will submit the site for your. Verify that the site is accessible and increase
max-ageto a day, then a week, then a month etc.
- ~3400 domains, 68 .cz domén
Right now, on 2015–10–14, there's 68 Czech domains, including some major e-commerce sites, out of roughly 3400 domains in total in the preload list. I have no idea what happens once the list grows but right now it's tiny and will still be tiny for few more years. The list had roughly 2000 domains 6 months ago. Once your site is included in the preload list, it will be preloaded in the browser in one of the upcoming versions.
- No Czech Bank
There's no Czech bank in the preload list as of 2015–10–14. In the Czech Republic, there are 60 banks, savings banks, and credit unions, 13 use HSTS in the online banking web app, 7 on corporate website. None of them in the preload list.
- Bank-grade encryption, tell me more about it
A lot of companies will tell you they provide, or use bank-grade encryption, while their HTTPS is actually set up better than what most banks have. Forget about bank-grade and just do HTTPS properly. That is, better than the majority of banks.
- NTP Man-in-the-Middle tool
There's actually a way to circumvent the HSTS policy. The browser uses system time to decide whether it should perform internal redirect or not. An attacker can attack the NTP time synchronisation and adjust the system time forward one year. All HSTS policies with max-age less than a year will then expire and it will be possible to strip the HTTP-to-HTTPS redirection again. Regular Windows allows maximum 15 hours drift and synces once per week so it'd take some time. More in Jose Selvi's DEF CON 23 talk Breaking SSL using time synchronisation attacks (slides, video).
- Forever. Nope, just 10 weeks!
In Chrome, the preloaded entries are valid only for 10 weeks since the build time, not forever. Google says it's to effectively actually remove entries when needed.
- Your connection is not private
HSTS serves one more important feature. If there's an issue with a certificate when connecting to an known HSTS-enabled host, the user cannot just click through the warning. The two sites above have spoofed self-signed certificates. The site on the right uses HSTS, so user is not allowed to visit it as there's no Proceed button.
- HTTPS Everywhere
BTW, you can use this browser extension to enforce local HSTS. It has it's own, more extensive list of sites with HTTPS support and you can even manually add your own favorite sites, for example your bank. Follow me on Twitter for all things HTTPS and HSTS.