3.1. Versions de protocole

3.1.1. Versions du protocole SSL/TLS

Il est important à la fois de cesser d'utiliser les anciennes versions moins sécurisées de SSL/TLS et de commencer à utiliser des versions modernes plus sécurisées; par conséquent, voici les recommandations concernant les versions du protocole TLS/SSL:

Les implémentations NE DOIVENT PAS négocier SSL version 2.

Justification: Aujourd'hui, SSLv2 est considéré comme non sécurisé [RFC6176].
Les implémentations NE DOIVENT PAS négocier SSL version 3.

Justification: SSLv3 [RFC6101] était une amélioration par rapport à SSLv2 et a comblé certaines failles de sécurité importantes mais ne supportait pas de suites de chiffrement robustes. SSLv3 ne supporte pas les extensions TLS, dont certaines (par exemple, renegotiation_info [RFC5746]) sont critiques pour la sécurité. De plus, avec l'émergence de l'attaque POODLE [POODLE], SSLv3 est maintenant largement reconnu comme fondamentalement non sécurisé. Voir [DEP-SSLv3] pour plus de détails.
Les implémentations NE DEVRAIENT PAS négocier TLS version 1.0 [RFC2246]; la seule exception est lorsqu'aucune version supérieure n'est disponible dans la négociation.

Justification: TLS 1.0 (publié en 1999) ne supporte pas de nombreuses suites de chiffrement modernes et robustes. De plus, TLS 1.0 manque d'un vecteur d'initialisation (IV) par enregistrement pour les suites de chiffrement basées sur CBC et ne met pas en garde contre les erreurs de bourrage courantes.
Les implémentations NE DEVRAIENT PAS négocier TLS version 1.1 [RFC4346]; la seule exception est lorsqu'aucune version supérieure n'est disponible dans la négociation.

Justification: TLS 1.1 (publié en 2006) est une amélioration de sécurité par rapport à TLS 1.0 mais ne supporte toujours pas certaines suites de chiffrement plus robustes.
Les implémentations DOIVENT supporter TLS 1.2 [RFC5246] et DOIVENT préférer négocier TLS version 1.2 par rapport aux versions antérieures de TLS.

Justification: Plusieurs suites de chiffrement plus robustes ne sont disponibles qu'avec TLS 1.2 (publié en 2008). En fait, les suites de chiffrement recommandées par ce document (Section 4.2 ci-dessous) ne sont disponibles que dans TLS 1.2.

Ce BCP s'applique à TLS 1.2 ainsi qu'aux versions antérieures. Il n'est pas prudent pour les lecteurs de supposer que les recommandations de ce BCP s'appliquent à toute version future de TLS.

3.1.2. Versions du protocole DTLS

DTLS, une adaptation de TLS pour les datagrammes UDP, a été introduit lorsque TLS 1.1 a été publié. Voici les recommandations concernant DTLS:

Les implémentations NE DEVRAIENT PAS négocier DTLS version 1.0 [RFC4347].

La version 1.0 de DTLS correspond à la version 1.1 de TLS (voir ci-dessus).
Les implémentations DOIVENT supporter et DOIVENT préférer négocier DTLS version 1.2 [RFC6347].

La version 1.2 de DTLS correspond à la version 1.2 de TLS (voir ci-dessus). (Il n'existe pas de version 1.1 de DTLS.)

3.1.3. Repli vers des versions inférieures

Les clients qui "se replient" vers des versions inférieures du protocole après que le serveur ait rejeté des versions supérieures du protocole NE DOIVENT PAS se replier vers SSLv3 ou antérieur.

Justification: Certaines implémentations clientes reviennent à des versions inférieures de TLS ou même à SSLv3 si le serveur a rejeté des versions supérieures du protocole. Ce repli peut être forcé par un attaquant homme-du-milieu (MITM). TLS 1.0 et SSLv3 sont significativement moins sécurisés que TLS 1.2, la version recommandée par ce document. Bien que les serveurs TLS 1.0 uniquement soient encore assez courants, les analyses IP montrent que les serveurs SSLv3 uniquement ne représentent qu'environ 3% de la population actuelle de serveurs Web. (Au moment de la rédaction, une méthode explicite pour prévenir les attaques de rétrogradation a été définie récemment dans [RFC7507].)