I know that until a few years ago, someone could set up a fake wireless AP, and use something like SSLStrip to lure the victims into connecting to insecure versions of the major websites, such as Gmail, Facebook, etc. Although, they had HSTS this was still possible. But, now as I see this is no longer possible for the major websites. What has changed since before few years. How does HSTS now prevent these type of MitM attacks?

  • Just to make sure I read your question right - are you saying that SSLStrip was possible even for sites using HSTS earlier?
    – Anders
    May 26, 2016 at 12:38
  • 3
    "Although, they had HSTS this was still possible" - [citation needed]. If you want us to explain the discrepancy, the first step is for you to provide sources for your claims, and make sure you're correctly characterizing what those sources say.
    – D.W.
    May 26, 2016 at 19:55

2 Answers 2


The HSTS header stops MitM attacks by instructing the browser to always send HTTPS (as opposed to HTTP) request to the domain until the policy expires. So a browser that respects the header would send a request to https://example.com even if the user clicked a link to http://example.com.

The logic behind HSTS has not changed since it was defined in an RFC in 2012. What has changed is that today almost all browsers implement it. Remember that it is the browser that enforce this policy! Can I Use reports browsers supporting it from the following versions:

  • Internet Explorer 11 (2015)
  • Firefox 4 (2011)
  • Chrome 3 (2010, possibly also supported earlier)
  • Safari 7 (2013)

(How Firefox and Chrome managed to support HSTS before the RFC was out is a mystery to me.)

So people using browsers older than that will not be protected even if the header is set. That might account for why you have the impression that setting the HSTS header did not use to help against SSLStrip earlier.

Another reason for HSTS not helping can be that the user has never visit the page before the attack. If the browser has never seen the header it can not enforce it. This can be solved with preloading.

  • 12
    "How Firefox and Chrome managed to support HSTS before the RFC was out is a mystery to me." – I just skimmed the authors list and references section: one of the authors works for Google (which could explain how Chrome got an early implementation). Also, the three authors collaborated on a predecessor called ForceHTTPS in 2008, which was implemented server-side at PayPal (one of the authors works there) and client-side in a Firefox extension, NoScript, and Chrome as early as 2009. May 26, 2016 at 16:25
  • 4
    The Mozilla issue tracker for implementing HSTS confirms it: bugzilla.mozilla.org/show_bug.cgi?id=495115 The bug dates all the way back to 2009 and shows how the name changed through ForceTLS to finally Strict Transport Security. May 26, 2016 at 16:29
  • 6
    RFCs often do not standardize new technologies, but standardize techniques that are used in the wild to encourage the use of only one design, one that is thoroughly analyzed and well thought out. May 26, 2016 at 18:48
  • 4
    @JordanMelo, actually, RFCs never standardize new technologies, because having two implementations is a requirement for admitting an RFC to the standards track. The RFC might, and usually is, published as “draft” before that. So Firefox and Chrome implementing it was a prerequisite for finalizing the RFC.
    – Jan Hudec
    May 27, 2016 at 7:05

SSLStrip worked rewriting https requests to plain http, removing the protection and allowing both eavesdropping and modification.

A server with HSTS protection will set a header on a HTTPS request asking the browser to only contact that server using HTTPS:

Strict-Transport-Security: max-age=31536000

In this case, for one year the browser will only connect to the server on HTTPS, and rewrite all links to be HTTPS (an inverted SSLStrip).

But there's a caveat: the client must have accessed the server using HTTPS at least once. If the client only connects via HTTP, MiTM still can occur, all requests can be altered and any HTTPS link or redirection can be changed back to HTTP. But as soon as the client access the server using HTTPS, the HSTS cookie is set and SSLStrip MiTM attacks are not possible anymore.

  • 10
    To be clear, sslstrip rewrites HTTPS links or redirects received in HTTP responses, if the protocol is already HTTPS then it can do nothing. The client does not need to have accessed the server in the case where the target domain is already in the HSTS preloaded list and a supported browser is used. May 26, 2016 at 13:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .