3.2. TLS strict

Les recommandations suivantes sont fournies pour aider à prévenir le SSL Stripping (une attaque résumée dans la Section 2.1 de [RFC7457]):

• Dans les cas où un protocole applicatif permet aux implémentations ou aux déploiements de choisir entre une configuration TLS stricte et une mise à niveau dynamique du trafic non chiffré vers un trafic protégé par TLS (tel que STARTTLS), les clients et les serveurs DEVRAIENT préférer une configuration TLS stricte.

• Les protocoles applicatifs fournissent généralement un moyen pour le serveur d'offrir TLS lors d'un échange de protocole initial, et fournissent parfois aussi un moyen pour le serveur d'annoncer le support de TLS (par exemple, via un indicateur signalant que TLS est requis); malheureusement, ces indications sont envoyées avant que le canal de communication ne soit chiffré. Un client DEVRAIT tenter de négocier TLS même si ces indications ne sont pas communiquées par le serveur.

• Les implémentations de client et de serveur HTTP DOIVENT supporter l'en-tête HTTP Strict Transport Security (HSTS) [RFC6797], afin de permettre aux serveurs Web d'annoncer qu'ils sont disposés à accepter des clients TLS uniquement.

• Les serveurs Web DEVRAIENT utiliser HSTS pour indiquer qu'ils sont disposés à accepter des clients TLS uniquement, à moins qu'ils ne soient déployés d'une manière telle que l'utilisation de HSTS affaiblirait en fait la sécurité globale (par exemple, il peut être problématique d'utiliser HSTS avec des certificats auto-signés, comme décrit dans la Section 11.3 de [RFC6797]).

Justification: Combiner communication non protégée et communication protégée par TLS ouvre la voie au SSL Stripping et à des attaques similaires, puisqu'une partie initiale de la communication n'est pas protégée en intégrité et peut donc être manipulée par un attaquant dont l'objectif est de maintenir la communication en clair.