Summary of HSTS Support in Modern Browsers

This a guest blog post by Mazin Ahmed, an external security expert who has helped test and audit ProtonMail. We hope it will educate our readers about web security.

HTTP Strict Transport Security (HSTS) is a web security policy that is made to protect secure HTTPS websites against downgrade attacks that is used to perform Man in the middle attacks. “Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers”[1].

The downgrade attack can occur when the user request a website in HTTP. When the user requested in HTTP:// URL, the server redirects the user to a secure HTTPS:// URL. Without HSTS, an attacker in the same network is able to stop the user from using the HTTPS version of the site and forcing the user to use the HTTP version, where the attacker is able to control user’s data and hijack the user’s session.

The HTTPS stripping attack that relates to the unuse of HSTS policy can be done via open-source tools, such as SSLStrip by Moxie Marlinspike. The tool has been publicly released on February 2009, and since then many browsers and websites have mitigated the issue.

Preventing the issue should be from two sides: the website, and the client. The website has that is already using HTTPS should apply HSTS policy to prevent the attack. The client has to use an updated version that supports HSTS policy.

The current advisory is tend to inform users that there is still modern browsers that do not support HSTS policy until today.

The following browsers supports HSTS policy (latest versions of browsers):

  • Google Chrome
  • Mozilla Firefox
  • Microsoft Edge
  • Safari for OSX
  • Opera
  • Ghostery
  • TOR Browser

The following browsers do not support HSTS policy:

  • Internet Explorer (all stable versions do not support HSTS. Only Microsoft Edge and Internet Explorer 10 Technical Preview support it)
  • Android Browser ( All versions upto 4.4.2 do not support HSTS policy. Newer versions might not be supporting it too)
  • Opera Mini (all versions, including Opera Mini 8)
  • Maxthon browser
  • UC browsers (including UC browser, UC mini, UC browser HD)
  • Opera for Android

Testing Browsers for MITM attacks due to Lack of HSTS policy:

You can follow the instructions in the following link to check if the browser supports HSTS policy.


  • Always use the latest version of browsers
  • If you are concerned about your security, do not use a browser that does not support HSTS policy.
  • If you are using a browser that is not listed above, you should test if it supports HSTS policy, and if it does not support it, you should stop using it.


  • Even if the website is using the maximum SSL encryption possible, if the client’s browser does not support HSTS, the client is vulnerable to man in the middle attacks.
  • If the client made an initial request to the website in HTTP, an attacker can manipulate the response to uninclude the HSTS header, and would be able to perform MITM attacks too. Therefore, if you are making an initial request to secured site, you should request it in HTTPS to avoid HTTPS stripping that leads to MITM attacks.

The list might be updated for newer information. If there is a mistake on the list, you can contact me to correct it.

References: [1]

About the Author

Mazin Ahmed is an information security specialist with experience in web-application security and mobile application security. Mazin is passionate about information security and has reported vulnerabilities which have been acknowledged by various companies, such as Facebook, Twitter, Linkedin, and Oracle to name a few. Mazin is part of ProtonMail’s security group, an independent panel of experts who audit ProtonMail releases on a voluntary basis. You can reach him via Twitter @mazen160, and read more about him by visiting his website.

About the Author


We are scientists, engineers, and developers drawn together by a shared vision of protecting civil liberties online. Ensuring online privacy and security are core values for the ProtonMail team, and we strive daily to protect your rights online.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

16 comments on “Summary of HSTS Support in Modern Browsers

  • I have a question for you ProtonMail:

    Google Chrome reports that the site is using “Weak Security Configuration” and “Obsolete Cryptography” and BitDefender reports “Outdated Security Settings”.

    Here’s a screenshot:

    Is this something being worked on or some kind of misunderstanding Chrome and BD are making?


      • Yes, it appears so. After disabling “Scan SSL” in BitDefender, it comes up fine. Maybe you need to clear it up with BD then, unless they’re just labeling your methods as obsolete by their opinion, haha.


        • Alex, it looks like your BitDefender is actually Man-in-the-Middle-Attacking your HTTPS connections, replaced the server certificate with its own (insecure), that prompts the warnings in the browsers.

          • It’s fixed immediately if you disable “Scan SSL” and clear out your temp files and everything.

            I don’t think it’s anything malicious.

          • Is not really a big deal. What BitDefender does is to inspect HTTP traffic (I guess looking for signatures) and try to detect malicious packets/connections. To do this is he needs to do mitm. If you want complete privacy, then disable it. If you want to be protected (not 100% guarantees of detection of course) also on ssl traffic, then you can keep it.

            Selfsigned does not mean that the certificate is insecure. It is simply not validated by a CA, for obvious reasons. The communication is still encrypted and the strength of the algorithm depends on the servers. If you add it as an exception in your browser, you solve the problem.

            I would personally go for the deactivation of it. 😛

  • Wouldn’t it be easier for SSL websites to just strictly 301 redirect all http requests on port 80 to their https counterparts on port 443? It needs to be done anyway to take advantage of SPDY in newer browsers.

    Such server configuration is trivial. Does this not eliminate the need for HSTS?

    Example Nginx configuration:

    server {
    listen 80;
    server_name *;
    return 301$request_uri;
    server {
    listen 443 default ssl spdy;
    ssl_certificate …

    • Actually, no. HSTS is supposed to prevent Man-in-the-middle attacks. One quick example to show why its not enough to block port 80.

      With HSTS: User visits Website -> Browser knows to not accept unencrypted connections -> Attacker tries to intefere but cant downgrade the victim, due to the SSL he wont be able to interrupt the connection.

      With Port 80 blocked: User visits Website -> Safe temporary connection -> Attacker downgrades the User to HTTP, eavesdrops / manipulates and forwards the traffic via HTTPS to not make the user suspicious

  • Few days ago i tested MITM attack against various browsers. I was able to capture credentials of my protonmail account on:

    Mozilla Firefox
    Google Chrome

    All lastest versions. All support HSTS. All with default configuration.

    Default configuration on ^ is like keeping the doors wide open.

    Fun part is, that just https-everywhere solved the problem.

    So my two cents:



    Are only few add-ons that can help, problem is that still not many knows that.

  • This mainly depends on how you tested it. HSTS only activates after the first visit and a fully working connection.

  • I have read about successful attacks against HSTS by Leonardo Nve and Jose Selvi on Blackhat based on DNS the first one and NTP the second one. So… Are this attacks still reliable? They broke HSTS or not.

  • I have a security question – if you use a PC that has a Keylogger would you not be exposing yourself to have your email hacked and given the changes you do in the settings that they can change the password and permanently lock you out?

    Would a two step verification approach be better – such as Authenticator, or SMS this would then total secure the system.

    Just a thought..

    • If there is a keylogger, your password will be exposed in the right moment you type it in. There is no protection if your machine is compromised. This is another reason why you should never use public PC to log in your accounts. 🙂

      To modify the password, they need also to have a malware able to do such a thing (inject data in your browser). However, I would not worry about this, the chances you would be targeted by a tailored malware are small. It is more likely that they are interested in your password. Therefore, a second-factor authentication is definitely a good option! I agree with you.

      With that, even though they have your password, it is not enough to login in your system, unless they infect the other device as well.

      A suggestion to protonmail: having some 2-factor authentication with Yubikey or some other products (that works offline) would be great!