The Internet Engineering Task Force (IETF) published RFC 6797, declaring the HTTP Strict Transport Security (HSTS) security mechanism for HTTPS as an Internet Standard.
HSTS allow (HTTP) servers to ensure any services offered can only get access via secure connections encrypted using mechanisms such as Transport Layer Security (TLS).
From a client perspective, HSTS forces applications (User Agents) to only use encrypted connections when communicating with web sites. Sites such as the Open Web Application Security Project’s describe how to implement the use of HSTS in web servers such as Apache, Nginx and Lighttpd.
The primary aim of HSTS is to counteract the attacks on SSL-encrypted web sites described by security researcher Moxie Marlinspike back in 2009. These attacks don’t directly attempt to crack SSL connections. Instead, they take advantage of the fact users don’t generally use https:// to access a page but rather tend to visit the unencrypted URL and then trust they will undergo redirection to the HTTPS version in due course. Marlinspike’s attacks prevent this redirection – without triggering, for example, browser messages that would alert the affected user.
When a browser first requests contact, HSTS-compliant web servers use an HTTP header field to inform the browser all connections to the requested web site must undergo encryption via SSL/TLS. While this header can filter out during a man-in-the-middle attack, browsers such as Chrome or Chromium and Firefox include a list of HSTS-compliant web sites and will be immune against such attacks.
The HSTS draft comes via the work of PayPal employee Jeff Hodges, Collin Jackson from Carnegie Mellon University, and Adam Barth from Google, who also co-authored RFC 6797. The Electronic Frontier Foundation’s (EFF) HTTPS Everywhere plugin for Chrome and Firefox also performs HSTS-like tasks such as the secure redirection of users to a web site’s HTTPS version.