Auteur Sujet: SSL LABS fait évoluer ses critères de notation pour 2017  (Lu 5699 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
SSL LABS fait évoluer ses critères de notation pour 2017
« le: 28 novembre 2016 à 13:19:12 »
SSL LABS fait évoluer ses critères de notation pour 2017

Les tests online gratuits de Qualys SSL Labs https://www.ssllabs.com/ sont largement utilisés pour auditer la qualité des certificats SSL des sites Web.
Ce test en ligne examine la chaîne de certification SSL d’un site Web pour vérifier qu’elle est de confiance et qu’elle participe activement à la sécurité des communications sur Internet, ainsi que des transactions en ligne.

Afin d’anticiper les nouveaux critères de notation rendus plus strictes, Qualys SSL LABS annonce sa feuille de route.
Les entreprises pourront ainsi prévoir les changements à opérer pour conserver une bonne note selon les nouveaux éléments requis.



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.
Préchargement pour HSTS requis pour la note A+

Suites AEAD exigées pour la note A
Mécanisme HSTS requis pour la note A

Note plafonnée à B ou C pour les sites utilisant l'algorithme 3DES
Pénalité plus sévère pour les sites continuant de supporter RC4

Protocole TLS 1.3 indispensable pour obtenir la note A+ (et pour A, ultérieurement, le moment venu)
L'agrafage OCSP (OCSP stapling), et dans une certaine mesure l'agrafage obligatoire must-staple, requis pour la note A+


Publié par Ivan Ristic , chercheur en sécurité et auteur de SSL Labs, traduit de l'Anglais par Véronique Loquet.

corrector

  • Invité
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #1 le: 11 décembre 2016 à 13:37:09 »
Petit rappel évident mais nécessaire :

Le configuration correction de la couche de chiffrement n'est que la première brique dans la sécurisation d'un site Web devant gérer des informations confidentielles. Il y a beaucoup plus à faire, et tout n'est pas automatiquement testable.

turold

  • Profil non complété
  • ******
  • Messages: 1 683
  • mp fermée (sauf admin et exceptions temporaires)
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #2 le: 18 décembre 2017 à 03:49:55 »
Salut,

Finalement, une partie de cette annonce n'a pas été appliquée... pour diverses raisons.

La réflexion sur les évolutions de grades pour 2018 avance très bien.
On y trouve notamment le RC4 toujours en grade B pour les serveurs qui l'ont toujours... mais fait utiliser plus sécurisé envers les navigateurs récents (cela devait être grade C durant 2017). Et toujours grade F pour les serveurs avec du RC4 en priorité (mouais, là, on ne peut pas faire plus bas de toute façon^^).

Lien direct de l'état d'avancement de la réflexion: https://docs.google.com/document/d/13o_iRZ5-Lv8VTDULUmpUu0XgHWCXDUbYia1vPagMBKE/edit

Lien vers l'article du blog (preview 3 ce mois-ci en fait, mais c'était en v1 au moment de l'article en juin): https://blog.qualys.com/ssllabs/2017/06/30/ssl-labs-grading-redesign-preview-1
« Modifié: 18 décembre 2017 à 05:01:31 par turold »

turold

  • Profil non complété
  • ******
  • Messages: 1 683
  • mp fermée (sauf admin et exceptions temporaires)
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #3 le: 21 décembre 2017 à 00:21:38 »
Pour rappel, le test ne s'effectue qu'à la racine, page d'accueil, du (sous-)domaine testé.

Donc cela ne concerna pas ce forum pour ce protocole de test, mais Qualys envisage en 2018 à mettre un grade C quand le test repère du contenu HTTP avec du HTTPS.... si ce contenu est passif. Sinon, ce sera grade F pour du contenu actif en HTTP avec du HTTPS.

Autre nouveauté de taille attendue: grade C si le HTTP ne redirige pas vers le HTTPS. Ce sera alors fini le grade A encore possible pour les sites avec aucune redirection entre HTTP et HTTPS (même si c'est juste pour tester le HTTPS)... ou même ceux qui redirigent le HTTPS vers le HTTP! Pour ces derniers, la communauté avait demandé un grade F ou T. Mais la 1ere sanction viendra des navigateurs, en fonction de l'importance de la sécurité vu par les utilisateurs (site de banque sans cadenas vert et en HTTP par exemple^^).

Encore en réflexion, mais très important, concernant le certificat TLS:
- le grade T doit-il se muer en grade F? Faire cette mutation en plusieurs étapes? Ou statu quo? Pour rappel, le grade T est inférieur au grade F, dans l'attribution des grades.
- Suite a l'affaire WoSign/StartCom, d'autres pourraient suivre... Et au vu de la durée de certains certificats côté site (jusqu'à 3 ans parfois, généralement 1 an quand même), faut-il mettre ses régressions de confiance en grade intermédiaire (grade T aujourd'hui pour ces cas)? Sous quelles conditions? Quelle grade? Ou statu quo avec la position binaire d'aujourd'hui sur la confiance? Et que penser d'un certificat auto-signé sur des sites fréquentés? etc.

Réponses très probable en janvier.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #4 le: 21 décembre 2017 à 06:31:52 »
Merci pour ce retour.

Je pense bannir à terme le contenu mixte sur le forum avec un Content Security Policy.

1ère étape : mettre un upgrade-insecure-requests => cela va chnager les URL http des images intégrées en https

Je vais pendant cette 1ère étape chercher toutes les images http et les héberger sur le forum
=> Écrire un message avec une photo ou copier/coller un traceroute

Une fois réalisé, je bloquerait l'utilisation des ressources http via Content Security Policy, ce qui devrait décourager l'utilisation d'hébergeur externe en http vu que l'image ne s'affichera pas.

Pour démarrer la 1ère étape, il faut que plus de 90% des sites qui hébergent habituellement des images soient en https, ce qui n'est pas encore le cas.

turold

  • Profil non complété
  • ******
  • Messages: 1 683
  • mp fermée (sauf admin et exceptions temporaires)
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #5 le: 21 décembre 2017 à 16:59:25 »
Rien qu'entre le site de Mozilla dev, et un site tiers regroupant ce genre d'info, je n'ai jamais la même info.
Mais une tendance s'en dégage. Cette fonctionnalité n'est pas dans IE (et donc ne le sera jamais), est en réflexion dans Edge, et c'est le flou pour Safari et le navigateur Android (mais ce dernier est de moins en moins utilisé pour du Chrome ou basé sur Chromium).

Je pense bannir à terme le contenu mixte sur le forum
Mes seules images en http datent avant mon https... et que je ne peux pas éditer (sujet verrouillé ou alors on me cite).
Il suffit de chercher ceci: http://alexou
Pour démarrer la 1ère étape, il faut que plus de 90% des sites qui hébergent habituellement des images soient en https, ce qui n'est pas encore le cas.
Tu comptes les hébergements comme le mien? Ou seulement ouvert au grand publique?
Attention, les non-HTTPS de 1ere abord ne sont pas tous pareils. Par exemple:
- pas de HTTPS pour casimages (pour le moment)
- Google m'envoie sur le HTTP de HostingPics. Mais le site, et depuis assez récemment les images hébergées, sont aussi disponibles en HTTPS

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
SSL LABS fait évoluer ses critères de notation pour 2017
« Réponse #6 le: 21 décembre 2017 à 19:45:35 »
Je viens de faire une règle pour que la nuit, les URL hébergées par HostingPics soient automatiquement transformées en https.

Si une personne as une liste d'hébergeur d'image gratuit, on pourrait faire le point régulièrement sur celles qui supportent https et celles qui ne supportent pas https.

Tu comptes les hébergements comme le mien? Ou seulement ouvert au grand publique?
Je pensais aux grand sites d'hébergement d'image et aux top 10 des médias d'information, car certains utilisent des images de ces sites.

Le site d'informations sont peu passé au https.

J'imagine que la difficulté technique n'explique pas tout. Je me demande si le https empêche le FAI d'insérer (à la demande du journal) un identifiant unique d'un visiteur sur mobile (ce qui permet donc de voir qu'une même sim a visité plus de 5 articles gratuitement dans le mois et qu'il faut bloquer ce client pour lui demander de prendre un abonnement). Sur le fixe, il suffit de passer en navigation privée pour consulter un journal en ligne au-delà du nombre d'article gratuit par mois.