Évolutions de la notation SSL Labs pour 2017

Publié par Ivan Ristic , chercheur en sécurité et auteur de SSL Labs

21 novembre 2016 - Environ une fois par an SSL Labs révise en profondeur ses critères de notation. Tandis que la sécurité de l'écosystème devient mature, notre objectif est de promouvoir et rendre les critères plus stricts pour l’obtention d’une bonne note. Ce processus d'amélioration permanente est pour nous vital à bien des égards.

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.

Orientations futures

Nous profitons de cet article pour décrire dans leurs grandes lignes les modifications à venir des critères de notation SSL Labs. Tous les changements énumérés ci-dessous seront effectifs à moyen terme.

Nous espérons que cette annonce anticipée permettra aux entreprises d'aviser dès à présent.

1. Préchargement pour HSTS requis pour la note A+
2. Suites AEAD exigées pour la note A
3. Mécanisme HSTS requis pour la note A
4. Note plafonnée à B ou C pour les sites utilisant l'algorithme 3DES
5. Pénalité plus sévère pour les sites continuant de supporter RC4
6. Protocole TLS 1.3 indispensable pour obtenir la note A+ (et pour A, ultérieurement, le moment venu)
7. L'agrafage OCSP (OCSP stapling), et dans une certaine mesure l'agrafage obligatoire must-staple, requis pour la note A+

A propos de Qualys, Inc.

Qualys Inc. (NASDAQ : QLYS), est le principal fournisseur de solutions de sécurité et de conformité dans le Cloud avec plus de 8 800 clients dans plus de 100 pays, dont une majorité des sociétés présentes aux classements Fortune 100 et Forbes Global 100.

Qualys Cloud Platform et sa suite de solutions intégrée aident les entreprises à simplifier leurs opérations de sécurité et à réduire le coût de la conformité. Cette plate-forme délivre un service à la demande de renseignement sur la sécurité. Elle automatise le spectre complet de l’audit, de la conformité et de la protection des systèmes d’information et des applications Web. Fondée en 1999, Qualys a signé des accords stratégiques avec des fournisseurs de services d’infogérance (« managed services ») et des cabinets de conseil de premier ordre comme, Accenture, BT, Cognizant Technology Solutions, Dell SecureWorks, Fujitsu, HCL Comnet, InfoSys, NTT, Optiv, Tata Communications, Verizon et Wipro. Qualys est également l’un des fondateurs de la Cloud Security Alliance (CSA) et du Conseil sur la cyber-sécurité.

Plus d’informations sur www.qualys.com

Qualys, le logo Qualys et QualysGuard sont des marques déposées de Qualys, Inc. Tous les autres produits ou marques sont la propriété de leurs détenteurs respectifs.