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

• Anonymous
  February 16, 2015
  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.

• Anonymous
  February 16, 2015
  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.

• Anonymous
  February 16, 2015
  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: chromium.googlesource.com/.../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.

• Anonymous
  February 16, 2015
  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 (blogs.msdn.com/.../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. connect.microsoft.com/.../949233
7. Any plans to support Public Key Pinning, based on either the HPKP header or a pre-load list?

• Anonymous
  February 16, 2015
  The comment has been removed

• Anonymous
  February 16, 2015
  The comment has been removed

• Anonymous
  February 16, 2015
  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?

• Anonymous
  February 16, 2015
  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.

• Anonymous
  February 17, 2015
  Read the following: blog.nvisium.com/.../is-your-site-hsts-enabled.html

• Anonymous
  February 18, 2015
  @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.

• Anonymous
  February 18, 2015
  The comment has been removed

• Anonymous
  February 18, 2015
  @EricLaw: Actually you can still detect whether users have visited the site by using www.ahstsdomain.com/.../img.jpg. If it succeeds then they have visited the site before.

• tsyrklevich.net/.../abusing-strict-transport-security

• code.google.com/.../detail

• Anonymous
  February 23, 2015
  @ EricLaw -

1. IE and Spartan are HSTS-enabled by default; plugins will need to opt in.
2. Yes, WinINet is HSTS aware.
3. 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.

• Anonymous
  February 24, 2015
  www.howtogeek.com/.../download.com-and-others-bundle-superfish-style-https-breaking-adware Thanks for being so useless when it comes to HTTPS & Windows root store security, MS.

• Anonymous
  February 25, 2015
  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?

• Anonymous
  February 26, 2015
  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>.

• Anonymous
  March 04, 2015
  @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.  

• Anonymous
  March 04, 2015
  Thanks Kyle for your response and for clearing this up!

• Anonymous
  March 30, 2015
  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. http://www.invokemoving.com

• Anonymous
  March 30, 2015
  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. invokemoving20@gmail.com

• Anonymous
  March 31, 2015
  please lett me conecte