# HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu'il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l'agent utilisateur par le serveur via la réponse HTTP, dans le champ d'en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l'agent utilisateur doit accéder au serveur informatique uniquement de façon sécurisée.

## Généralités

Lorsque la politique HSTS est active pour un site web, l'agent utilisateur compatible opère comme suit :
* Il remplace automatiquement tous les liens non sécurisés par des liens sécurisés. Par exemple, http://www.exemple.com/une/page/ est automatiquement remplacé par https://www.exemple.com/une/page/ avant d'accéder au serveur.
* Si la sécurité de la connexion ne peut être assurée (par exemple, le certificat TLS est autosigné), celui-ci affiche un message d'erreur et interdit à l'utilisateur l'accès au site à cause de cette erreur.
La politique HSTS aide à protéger les utilisateurs de sites web contre quelques attaques réseau passives (écoute clandestine) et actives. Une attaque du type man-in-the-middle ne peut pas intercepter de requête tant que le HSTS est actif pour ce site.

## Syntaxe

Activer HSTS pour un an :
L'activer aussi pour les sous-domaines :
Autoriser aussi l'ajout du site dans les listes préchargées :

## Bonnes pratiques

* HSTS doit être déclaré sur le domaine. Par exemple, https://sub.example.com doit aussi utiliser HSTS sur https://example.com.
* Les pages de https://www.example.com devraient inclure une requête vers une ressource sur https://example.com pour s'assurer que le domaine principal est protégé. Avec la directive includeSubDomains, cela permet de protéger l'intégralité des sous-domaines.

## Liste préchargée

HSTS ne protège qu'après la première connexion. Afin de corriger ce défaut, les navigateurs proposent un mécanisme de préchargement : les sites peuvent s'enregistrer sur le site web hstspreload pour demander leur inclusion dans cette liste. La présence du paramètre preload permet de s'assurer de leur consentement.

## Support
### Navigateurs supportant HSTS

* Google Chrome et Chromium supportent HSTS depuis la version 4.0.211.0.
* Le support de HSTS est activé dans les sources de Firefox depuis le 25 août 2010, il est disponible depuis Firefox 4.0$^,$. La version 17 du navigateur possède, en interne, une liste prédéfinie de sites web dont la connexion devra se faire en HSTS, ceci afin d'éviter un détournement lors de la première connexion où le navigateur ignore si le site demandera HSTS ou pas.
* L'extension pour Firefox « NoScript » impose HSTS depuis la version 1.9.8.9.
* L'extension pour Chrome/Firefox/Opera « HTTPS Everywhere », dérivée de NoScript, généralise le concept de HSTS en incluant des sous-ensembles de chemins pour certains domaines, et réécrit les URI non sécurisées http:// d'un domaine en URI https:// d'un domaine relatif (par exemple, de http://en.wikipedia.org à https://en.wikipedia.org).
* Opera 12.
* Internet Explorer 11.

## Implémentation

Les en-têtes Strict-Transport-Security doivent être envoyés via des réponses HTTPS. L'implémentation du côté client ne doit pas respecter les en-têtes HSTS qui ne sont pas envoyées via des réponses HTTPS, ou par le biais de réponses HTTPS qui ne sont pas configurées proprement, et sans certificat de confiance. Les bribes de configuration de serveur suivantes doivent être effectuées dans un contexte de bloc de configuration d'un site TLS et les exemples de codes ne doivent être effectués que dans un contexte de réponses HTTPS.
Le temps maximum (max-age) est donné en secondes. Les 31 536 000 secondes (soit 365 jours) dans les exemples ci-dessous peuvent être remplacées par des valeurs plus grandes ou petites en fonction des besoins du gestionnaire du serveur web.

### Implémentation Lighttpd

Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation Nginx

Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.
Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation Varnish

Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation IIS

L'en-tête peut être ajouté en modifiant le fichier web.config.
Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation ColdFusion Markup Language (CFML)

Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation Visual Basic .NET

Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation F5 BIG-IP LTM

Créer une iRule et l'appliquer à votre Virtual Server HTTPS.
Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.

### Implémentation HAProxy

Ajouter cette ligne dans la partie frontend HTTPS du fichier de configuration.
Cette implémentation du protocole est partielle et ne propose pas la redirection à partir d'un environnement non sécurisé.