Extension:HSTS

The HSTS extension implements the HTTP Strict Transport Security feature (RFC 6797) as an opt-in (or opt-out) preference for each user, in order to be always redirected to the HTTPS version of the website, if the user agent (client browser) understands the HSTS functionality. The server administrator is also given the possibility to force the anonymous and/or logged-in users to have a STS header and thus stay on HTTPS.

This extension can be used either:
 * to let users the choice to deactivate HSTS/HTTPS if they prefer (frequent travellers, residents of countries where HTTPS is forbidden, etc.),
 * to let advanced users to choice to activate HSTS/HTTPS,
 * as a "beta" feature before a widespread deployment.

Usage
If the system administrator has made this possible, the (logged-in) users can modify their preferences for activation of the HSTS in the page "Special:Preferences", tab "User profile", section "Basic information". It must be noted that, due to the nature of the HSTS specification, the user will absolutely have no access to the unencrypted HTTP version of the wiki, even in case of problem due to TLS/HTTPS (either a client or server problem); so any misconfiguration can be fatal for the remaining time HSTS is active.

Configuration
HSTS has five configuration variables which can be modified in.

Note that in this second case the header is dynamical, so you may want to configure accordingly your cache servers for a consistent user experience, particularly given the authoritative HSTS header is the last sent, even if shorter.
 * : max-age parameter for HSTS; can be either:
 * a number: (e.g. 3600) fixed number of seconds before expiration of HSTS (note that 0 will deactivate HSTS the next time the user visit the website), or
 * a date: (e.g. "2014-09-24T00:00:00Z") when HSTS will expire (e.g. just before certificate expiration); MediaWiki must understand the date (see the manual).
 * : (boolean) whether to include the "includeSubDomains" keyword in the STS header.
 * : (boolean) whether to give the STS header to anonymous users.
 * : (boolean) whether to force the STS header for logged-in users; if true, the users do no more have their preference available since it became unuseful due to the server adminstrator’s decision.
 * = opt-out or  = opt-in)

Examples:
 * STS header fixed to 30 days before expiration:
 * The STS security will expire midday UTC on 18 August 2013:

If you are cautious about the effects of HSTS, you can try it in the early tests with small values as 1 minute or a near expiration date.

Testing
The versions 0.2 and 1.0 have been tested by extension author Seb35 on a local test wiki and all works as expected: the STS header is present if and only if (iff) we are on HTTPS and the wgHSTSForAnons/Users is true or (the preference is activated and wgHSTSForUsers is false); the includeSubDomains is present iff the parameter is activated; the fixed duration-before-expiration stays correctly; the decreasing duration-before-expiration for a fixed date decreases; and the STS header is no more present after expiration.

Warnings

 * The STS header is not present on some specific pages (e.g. low-level error pages), although it is present on every reasonably-formed page. If the HSTS period is not expired, the user agent should still consider the HSTS as active and redirect to the HTTPS version, see section 8.6 in RFC 6797.
 * HSTS works only on some user agents, and users could experience differences in activation of the HSTS if they change their user agent (although the STS header is always present).
 * There is a small possible attack against the activation of this feature: in the case of an opt-out preference, a man-in-the-middle could avoid the user to activate the HSTS preference, if the user only use an HTTP session. To circumvent this attack, the user should activate this preference during a HTTPS session.

Bugs and improvements

 * The preference should be available only during a HTTPS session: if HSTS is about to be activated, an HTTPS session ensures the HTTPS works and drastically lower the probability a man-in-the-middle is present; if HSTS is about to be deactivated, an HTTPS session ensures it is the real user who is deactivating the preference and not a man-in-the-middle.
 * It could be added a feature to immediately deactivate HSTS, although this could be used to facilitate hacking of a user. A similar idea is to let the user choose her/his HSTS expiration time.
 * The user preference could become a Beta Feature, although this extension should also continue to be autonomous if the sysadmin wants it: $wg variable to activate as a beta feature or a classical user preference.