User:Mavarog/Taller

HTTP Strict Transport Security (HSTS) is a proposed web security policy mechanism where a web server declares that complying user agents (such as a web browser) are to interact with it using secure connections only (such as HTTPS). The policy is communicated by the server to the user agent via a HTTP response header field named "Strict-Transport-Security". The policy specifies a period of time during which the user agent shall access the server in only secure fashion.

Specification history
The HSTS specification is presently an IETF Internet-Draft. The authors submitted it as an Internet-Draft on 17 June 2010, and it has undergone at least two revisions since then. It was with the conversion to an Internet-Draft that the specification name was altered to "HTTP Strict Transport Security" from "Strict Transport Security". The reason for this name change was given as being due to the specification being specific to HTTP. (Note: the HTTP response header field defined in the HSTS specification remains named "Strict-Transport-Security").

The latest community version of the then-named STS specification was published on 18 December 2009, with revisions based on community feedback.

The original draft specification by Jeff Hodges from PayPal, Collin Jackson and Adam Barth was published on 18 September 2009.

The specification is based on original work by Jackson and Barth as described in their paper “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks”.

Overview
When the HSTS policy is active for a website, a complying user agent does the following:


 * 1) Automatically turn any insecure links to the website into secure links. (For instance,  http://www.example.com/some/page/  will be modified to  https://www.example.com/some/page/  before accessing the server.)
 * 2) If the security of the connection cannot be ensured (e.g. the server's TLS certificate is self-signed), show an error message and do not allow the user to access the site despite the error.

The HSTS policy helps protect website users against some passive (eavesdropping) and active network attacks. A man-in-the-middle attacker will not be able to intercept any request to a website while the user's browser has HSTS active for that site.

Limitations
The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel. The same applies to the first request after the activity period specified in the advertised HSTS policy expires. Google Chrome addresses this limitation by implementing a "STS preloaded list".

Support
Websites:
 * PayPal sets the Strict-Transport-Security header on their https-only website.
 * DEF CON website
 * https://www.acdet.com/
 * https://squareup.com/
 * https://www.ssllabs.com/
 * https://voipscanner.com/
 * https://www.strongspace.com/
 * https://www.elanex.biz/
 * https://jottit.com/
 * https://sunshinepress.org/
 * https://www.noisebridge.net/
 * https://neg9.org/
 * https://riseup.net/
 * https://factor.cc/
 * https://(support,members,id,lists).mayfirst.org/

Naturally, this is not a complete list of websites which support STS.

Browsers:
 * Google Chrome supports HSTS as of version 4.0.211.0.
 * HSTS landed in the Firefox nightlies as of 25 Aug 2010
 * The NoScript extension for Firefox enforces HSTS as of version 1.9.8.9.
 * The HTTPS Everywhere extension for Firefox, derived from NoScript, generalises the concept of HSTS, to include subsets of the paths on some domains, and rewriting of insecure http:// URIs on one domain to secure https:// ones on another (for instance, from http://en.wikipedia.org to https://secure.wikimedia.org).
 * Internet SSL Survey 2010 v1.6
 * Strict Transport Security - The Chromium Projects

Implementation
Strict-Transport-Security headers should be sent via HTTPS responses. Client implementations should not respect STS headers sent over non-HTTPS responses, or over HTTPS responses which are not using properly configured, trusted certificates. The following server configuration snippets should be within the context of an SSL site configuration block, and the code examples should be within the context of HTTPS responses only.

Note that the max-age is provided in seconds. The 500 seconds in the examples below can be changed to a much larger value depending on how long the web server operator is willing to commit to using HTTPS.

Implementation in Apache.

Implementation in nginx.

Implementation in PHP.

Implementation in Perl.

Implementation in Ruby on Rails.

Implementation in ASP.

Implementation in ColdFusion Markup Language (CFML).

Implementation in JavaServer Pages (JSP).

Implementation in Visual Basic .NET.

Implementation as Struts 2 interceptor in Java.