Selon nos mesures au sein du tableau de bord SSL Pulse, la configuration de plus de 40% des sites surveillés peut être considérée comme bonne. Cependant, seulement 3% de ces sites décrochent une note A+, niveau vers lequel ils devraient pourtant tous tendre. Notre objectif en matière de conception de critère de notation vise donc à augmenter le nombre de sites notés A+.

Cet article présente les modifications à court terme et décrit celles que nous effectuerons courant 2017 et au-delà. Comme indiqué dans la liste ci-dessous, c’est la notation de 3DES qui va changer en premier. D’autres changements suivront. Le but premier de cet article est de décrire notre feuille de route en termes d’évaluation afin que les entreprises puissent commencer à planifier des améliorations.

Pénalité pour l’utilisation du chiffrement 3DES avec des protocoles modernes (C)

Fin août 2016, des chercheurs en sécurité ont révélé une attaque contre des algorithmes de chiffrement utilisant des blocs de chiffrement 64 bits. Ce type d’attaque nécessite un très gros volume de trafic, cela doit alerter sur les algorithmes de chiffrement plus anciens et plus faibles qui ne doivent plus être utilisés. Concernant le protocole TLS, il implique d’éviter 3DES. Cependant, pour les sites qui doivent supporter une base ancienne d’utilisateurs, supprimer complètement 3DES peut s’avérer impossible (voir Windows XP), en revanche il n’y a aucune raison d’utiliser ce chiffrement avec des navigateurs modernes. C’est pourquoi nous allons modifier nos critères de notation afin de pénaliser les sites qui négocient 3DES avec TLS 1.1 et des protocoles plus récents. De tels sites verront leur évaluation plafonnée à C. Les sites qui continuent à supporter 3DES mais en maintenant cet algorithme à la dernière place sur leur liste de suites ne seront pas affectés.

La Confidentialité persistante requise pour obtenir un A

Inhérente à la communication sécurisée, la fonction de confidentialité persistante (Forward security) empêche que la compromission d’une clé privée de long terme affecte une conversation chiffrée. Avec TLS, il faut décider pour chaque déploiement de fournir ou non la fonctionnalité de confidentialité persistante. Le célèbre algorithme d’échange de clés RSA, par exemple, ne la prend pas en charge. Or, la confidentialité persistante est l’un des critères les plus importants et nous souhaitons mettre davantage l’accent sur ce point. Nous exigerons donc bientôt le déploiement de cette fonctionnalité pour obtenir la note A.
Nous estimons que cela concernera à peu près 7% des sites qui obtiennent actuellement la note A (environ 43% actuellement). Dans la mesure du possible, nous ne pénaliserons pas les sites qui utilisent des suites sans la fonction de confidentialité persistante à condition qu’ils ne négocient jamais avec des clients qui peuvent faire mieux.

Déploiement de suites AEAD pour obtenir un A+

Depuis les attaques Lucky 13, le consensus au sein de la communauté de la sécurité est que le chiffrement authentifié est supérieur aux suites CBC (telles que déployées dans TLS). TLS 1.3 ne prend en charge que les suites AEAD. Actuellement, SSL Labs ne récompense pas l’utilisation de suites AEAD et nous souhaitons corriger cette situation. Lors de la prochaine mise à jour de nos critères de notation, nous commencerons à exiger le déploiement de suites AEAD pour obtenir un A+. Plus tard, les suites AEAD seront exigées pour obtenir une note A.

Comme pour la confidentialité persistante, nous ne pénaliserons pas les sites qui continuent d’utiliser des suites non AEAD à condition que ces suites soient négociées avec les clients qui les supportent.

Défenses contre l’affaiblissement des protocoles

En avril 2015, la RFC 7507 introduisait une nouvelle défense contre les attaques par affaiblissement volontaire de protocoles, le nom complet de ce standard étant « TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks ». Dans la mesure où cette défense colmate une faille de sécurité sérieuse, SSL Labs exige des serveurs qu’ils prennent en charge la valeur de signalisation (TLS_FALLBACK_SCSV) pour obtenir une note A+. L’adoption a été plutôt encourageante car selon les résultats de l’observatoire SSL Pulse publiés en août dernier, 66% de l’ensemble des serveurs supportent désormais cette fonctionnalité.

Lorsque nous avons introduit cette modification de notre notation, notre but était de finir par rendre obligatoire le support de SCSV pour obtenir une note A. Entre-temps, POODLE est passé par là et les navigateurs modernes ont généralement supprimé tout comportement visant à affaiblir volontairement les protocoles. A l’heure actuelle, TLS_FALLBACK_SCSV n’a pas grande valeur de sécurité car les clients qui la supportent ne vont de toute façon pas procéder à un affaiblissement. En parallèle, IIS ne prend pas en charge RFC 7507, si bien que quiconque fait tourner son site sur ce type de serveur Web ne peut obtenir une note A+.
Étant donné la récente modification apportée à TLS 1.3, les futurs affaiblissements de protocoles seront évités et nous envisagerons de supprimer l’exigence de déployer TLS_FALLBACK_SCSV pour l’obtention d’une note A+.

Pénalité pour les serveurs intolérants aux versions plus récentes

A l’origine, notre intention était d’introduire une pénalité pour les serveurs intolérants aux futures versions du protocole TLS. Cependant, une modification apportée à TLS 1.3 au niveau de la négociation des versions de protocoles fait que les serveurs intolérants aux nouvelles versions ne pourront plus empêcher le déploiement de cette version du protocole. C’est pourquoi nous ne prévoyons pas actuellement d’introduire une pénalité pour ce problème.

Ajustement de la notation pour le chiffrement

Notre algorithme actuel pour attribuer une note aux systèmes de chiffrement ne donne pas les résultats escomptés si bien que nous prévoyons d’introduire ou deux règles explicites. Tout d’abord, tous les algorithmes de chiffrement plus faibles que 128 bits (sauf 3DES) obtiendront une note F. Ensuite, les serveurs qui continuent de prendre en charge RC4, même si cet algorithme n’est pas utilisé par les navigateurs modernes, obtiendront au maximum la note C.

Dépréciation de l’algorithme de hachage SHA1

Comme vous le savez déjà probablement, SHA1 a été déprécié concernant les signatures de certificats. En 2017, les navigateurs cesseront de faire confiance aux sites Web qui continuent d’utiliser cette fonction de hachage faible pour les signatures. Pour être en phase avec le marché, nous ferons de même pour ces sites.