HTTP Strict Transport Security comes to Internet Explorer

As part of our ongoing commitment to help build an interoperable, secure web that “just works,” we're excited to announce support for HTTP Strict Transport Security (HSTS) in Internet Explorer. This change can be previewed using Internet Explorer in the Windows 10 Technical Preview, and will come to Project Spartan in a later update.

The HSTS policy protects against variants of man-in-the-middle attacks that can strip TLS out of communications with a server, leaving the user vulnerable. For example, a user may initially connect to a non-encrypted version of a website before being redirected to a secure connection. An attacker exploiting the non-encrypted connection could redirect the user to a malicious site. HSTS mitigates this attack vector by allowing sites to specify that the browser should always use a secure connection to the server. HSTS provides two methods for sites to secure their connections:

  • Registering for a preload list: websites can register to be hardcoded by IE and other browsers to redirect HTTP traffic to HTTPS. Communications with these websites from the initial connection are automatically upgraded to be secure. Like other browsers which have implemented this feature, Internet Explorer's preload list is based on the Chromium HSTS preload list.
  • Serving a HSTS header: Sites not on the preload list can enable HSTS via the Strict-Transport-Security HTTP header. After an initial HTTPS connection from the client containing the HSTS header, any subsequent HTTP connections are redirected by the browser to be secured via HTTPS.

There are two important changes that impact users on sites using HSTS. First, when there is a certification error with a HSTS server, the user will not be able to click through and ignore the certificate error; they must abort their connection. Second, mixed content is not supported on servers supporting HSTS; all the content must be secure.

These changes are available for preview in the January updates to the Windows 10 Technical Preview. Join the Windows Insider Program to see HSTS in action in IE and let us know if you have feedback @IEDevChat or on Connect.

— Mike Bell, Program Manager, Storage, Network, and Print
— David Walp, Program Manager, Internet Explorer

Comments (21)
  1. Brian LePore says:

    Very happy to see this feature added to IE.

    And thank you for the comment about the preload list. I can't believe I never heard about that little bit. Just registered our site.

  2. Santosh S says:

    While this is a great security feature, it awkward to see the hard coded list as such.

    How would this list scale beyond a hundred?

    How the update will happen without the browser itself?

    It will be stupid to just follow what chromium did.

  3. geofft says:

    IE team: This is fantastic to hear, thanks.

    Santosh: Why is it stupid? The Chromium list has close to 2000 entries in a JSON file at the moment, and seems to be doing fine. And I can't think of any reason why this list needs to be updated than your browser should be getting updated anyway. Here's the current location of the list in Chromium's source tree:…/transport_security_state_static.json

    It'd be good to hear engineering arguments for changing from this (proven) approach, more than just an assertion that it's awkward.

  4. Super-exciting, thanks for the post!

    A few questions:

    0. Is this protection available for applications hosting the Web Browser control? The Web View?

    1. Windows has several major HTTP stacks (WinINET, WinHTTP, and System.NET are the most common) and because IE extensions do not rely upon IE itself for networking, they could unknowingly circumvent HSTS protections unless HSTS state is shared across all of the relevant HTTP stacks. Is it shared (even optionally?).

    2. When you say "All the content must be secure" does that include audio/video (that are presently allowed by default?)

    3.  If the DOM includes an insecure reference to a site using HSTS, should that DOM reference itself be changed, or should the secure version of the URL silently be used?

    4. How should the “virtual redirection” be handled by Resource Timing and other specifications?

    5. How does this feature interact with IE's InPrivate Mode? The answer has privacy implications (…/hsts-strict-transport-security-attacks-mitigations-deployment-https.aspx)

    6. Will IE do work to ensure the user's clock is correct to prevent creating a DoS condition? 20% of Chrome HSTS errors are caused by a bad client clock.…/949233

    7. Any plans to support Public Key Pinning, based on either the HPKP header or a pre-load list?

  5. No name says:







  6. Madhu Rakhal Magar says:

    Now I see Micosoft is within the Race. Keep it up.

  7. Paul says:

    What is wrong with requiring any redirect from http to https to be within the same domain? Or at least, warning the user if they are redirected off-site?

  8. @Paul says:

    Best practice is to apply HSTS to the entire domain to prevent the possibility of credentials leaking anywhere.  For instance if the cookies weren't secure then there is still the possibility of MITM on the http site in the domain.  I'm sure there are other vectors of attack because there isn't the same level of protection within a domain.  Since normally the entire domain would be covered by HSTS the browser wouldn't make an initial request to an http site on the domain.

  9. @EricLaw – Thanks for the great questions! Here are some thoughts from the team:

    Our initial approach to supporting HSTS is to focus on scenarios where user are most commonly exposed to, which in this case is IE and Spartan clients. Adding HSTS support to WinHTTP and System.NET is something we’ll be evaluating in the future.

    Mixed content – We do allow audio/video in the mixed mode scenario as it applies to HSTS.

    DOM – The DOM reference should be changed.  IE catches the mixed content issue before WinINet can upgrade the protocol to be secure.

    HSTS in IE InPrivate mode – In the initial release, HSTS will be turned off when a user is in InPrivate mode. However, we have plans to address the scenario.

    Client-server clock offset – We are aware of this issue and it is our roadmap to be addressed.

    Public Key Pinning – This is currently not supported but is something we're looking at.

  10. Thanks for getting back to me. Naturally, I have followup questions. 🙂

    1. What happens when an ActiveX control or plugin like Flash uses WinINET within IE or Spartan. Will HSTS apply or not?

    2. If the DOM reference changes, there are privacy implications (a la Visited Links, I can detect whether you've visited the site before by whether my URL magically became secure).

    3. Does WinINET have awareness of HSTS? Or do you have the hook on redirects such that URLMon can intercept them and apply the correct policy?

    4. When you say "HSTS will be turned off" while InPrivate does that also apply to the built-in preload list? That would be confusingly suboptimal.

    Thanks again!

  11. Tim says:

    @EricLaw: Actually you can still detect whether users have visited the site by using…/img.jpg. If it succeeds then they have visited the site before.



  12. @ EricLaw –

    1. IE and Spartan are HSTS-enabled by default; plugins will need to opt in.

    3. Yes, WinINet is HSTS aware.

    4. As mentioned above, we have plans to address this scenario later. That said, HSTS and the preload list will be off while in InPrivate in preview builds as well as at launch.

  13. HTTPS says:…/

    Thanks for being so useless when it comes to HTTPS & Windows root store security, MS.

  14. SSL VPNs and other non-browser products? says:

    I've been looking for a way to enforce certificate pinning on an SSL VPN product (which uses windows APIs and the windows certificate store for connections).

    Would this help?

    Or, can EMET be configured to drop connection which fail certifcate pinning rules instead of popping up a useless warning that would be ignored by users?

  15. tanvi says:

    Hello!  Glad to see that IE is implementing HSTS.  I'm a bit confused by this statement "mixed content is not supported on servers supporting HSTS".  Does it mean that mixed active (blockable) content will be blocked on HSTS pages without a way for the user to override it?  Or does it mean that all mixed content (active/blockable and passiveoptionally-blockable) will be blocked by default on HSTS pages with a user override option?

    Mixed passive (optionally-blockable) content includes images, <video>, and <audio>.

  16. @tanvi

    Sorry for the confusion – it means that mixed active (blockable) content will be blocked on HSTS pages without a way for the user to override it.  

  17. tamvi says:

    Thanks Kyle for your response and for clearing this up!

  18. Michael jame says:

    Invoke Moving Services is a family-owned moving company operated in Texas. Our Fort Worth Movers do all types of local and long distance moving services.

  19. Micheal Jame says:

    Invoke Moving Services is a family-owned moving company operated in Texas. Our Fort Worth Movers do all types of local and long distance moving services.

  20. abeid islam says:

    please lett me conecte

Comments are closed.

Skip to main content