Mais alors des questions moins claires se posent, par exemple: la prise en charge de TLS_RSA_EXPORT_WITH_RC4_40_MD5 est-elle un "chapeau" complet ou juste un inconvénient? Et si cette suite de chiffrement des
De ce fait, une méthodologie de compilation d'index est née, qui permet d'évaluer formellement le degré de fiabilité d'une connexion HTTPS par 31 points, répartis en 5 groupes, de "ce n'est pas du tout HTTPS" à "continuez comme ça!"
Ce que l'index n'est certainement pas, c'est la «réponse russe» au NIST / HIPAA / PCI DSS, etc. pour deux raisons.
Premièrement, l'index ne considère que la fiabilité de la connexion HTTPS. Performances du serveur Web (NPN / ALPN / reprise de session), etc. l'index ne considère pas la matière, il n'a pas été inventé pour cela.
La seconde est que NIST.SP.800 et d'autres normes de l'industrie sont guidées par les courbes elliptiques du NIST, dans lesquelles il n'y a guère plus qu'aucune confiance, mais il y a des questions du point de vue de l'ECDLP / ECC (une remarque gaie sur un chapeau en aluminium peut être laissée dans les commentaires sans exception ).
Bien que qui sait, peut-être qu'avec le temps, un standard souverain avec
L'idée principale de l'indice: en 2020, seul TLS 1.2 et supérieur avec l'ensemble correspondant de suites de chiffrement et de courbes elliptiques peut être considéré comme du «vrai HTTPS». Il est temps pour les anciennes suites de chiffrement, même si elles n'ont pas de vulnérabilités connues, de tomber dans la poubelle de l'histoire. Les arguments sur la nécessité de prendre en charge les clients hérités sont en faveur des pauvres: Windows XP est toujours populaire, mais ses utilisateurs ne parcourent pas Internet aujourd'hui via Internet Explorer 8 avec son Schannel préhistorique, mais utilisent des navigateurs basés sur Chromium / Firefox qui utilisent NSS à cette fin ... Il en va de même pour les utilisateurs d'anciennes versions d'Android: ils ont soit installé un navigateur alternatif qui ne repose pas sur la bibliothèque de cryptage du système, soit ils ne peuvent pas utiliser la plupart des sites modernes, même via HTTP (sans prise en charge de CSS3 et d'autres accords de dénonciation modernes).
A partir de ces positions, il est proposé de critiquer le projet de méthodologie. Avez-vous tout pris en compte? Avez-vous serré les écrous trop fort? N'avez-vous rien mal interprété? Vous trouverez ci-dessous une liste de critères, et le lien est un texte plus détaillé, avec des notes et des commentaires .
1. Critères minimaux
1.1. La communication HTTP chiffrée (HTTPS) est prise en charge à l'aide du protocole cryptographique TLS. Une connexion HTTPS est établie avec l'identifiant de protocole (schéma URI) https sur le port TCP 443.
1.2. Le cryptage de la connexion est validé par un certificat de site TLS X.509 version 3 valide, non auto-signé et non vide émis par une autorité de certification faisant autorité (CA).
2. Critères supplémentaires
2.1. Le serveur n'est pas sensible aux vulnérabilités connues dans la mise en œuvre du support de connexion sécurisée (BEAST, POODLE, GOLDENDOODLE, etc.)
2.2. La compression TLS n'est pas prise en charge.
2.3. Seule la renégociation sécurisée initiée par le serveur est prise en charge; La renégociation initiée par le client n'est pas prise en charge.
3. Critères recommandés
3.1. La connexion HTTP bascule automatiquement (forcée) sur HTTPS.
3.2. La clé publique des certificats TLS du site a une longueur ≥2048 bits. Le certificat est signé numériquement à l'aide de l'algorithme ≥SHA256 avec cryptage RSA ou ECDSA.
3.3. Le protocole TLS version 1.2 est pris en charge.
3.4. Les versions SSL et TLS ≤1.1 ne sont pas prises en charge.
3.5. Les suites de chiffrement standard basées sur des algorithmes puissants sont prises en charge.
3.6. Les suites de chiffrement faibles, inappropriées et vulnérables ne sont pas prises en charge.
3.7. Les courbes elliptiques ECDLP / ECC sont prises en charge.
3.8. L'ordre de coordination des suites de chiffrement est défini.
3.9. Les paramètres robustes des algorithmes d'accord de clé Diffie-Hellman (DH) sont utilisés.
3.10. Les extensions TLS importantes sont prises en charge.
3.11. L'indication de nom de serveur (SNI) est prise en charge.
4. Critères
élargis 4.1. Une chaîne de certificats TLS complète et non redondante a été publiée avec leur séquence de chaînes correcte.
4.2. Le certificat TLS du site prend en charge la transparence des certificats.
4.3. Le certificat TLS du site prend en charge la liste de révocation des certificats (CRL) et le protocole OCSP (Online Certificate Status Protocol).
4.4. Les certificats TLS des chaînes alternatives sont conformes aux critères 1.2, 4.1.
4.5. Les courbes elliptiques non sécurisées ECDLP / ECC ne sont pas prises en charge.
4.6. L'ordre d'appariement des courbes elliptiques est défini.
4.7. Les en-têtes de réponse HTTP contiennent l'en-tête HTTP Strict Transport Security avec la directive includeSubDomains.
5. Critères de bonus
5.1. Le certificat TLS du site prend en charge l'agrafage OCSP.
5.2. Le certificat de site TLS est émis à l'aide de la vérification de l'organisation (OV) ou de la validation étendue (EV).
5.3. La version 1.3 du protocole TLS est prise en charge.
5.4. L'ordre d'accord des suites de chiffrement stables du plus résistant au moins stable (par des paramètres comparables) est défini.
5.5. Les enregistrements de ressources DNS pour le nom de domaine du site incluent un enregistrement CAA (Certification Authority Authorization).
5.6. Les enregistrements de ressources DNS pour le nom de domaine du site incluent les enregistrements DS et TLSA (DNSSEC et DANE sont pris en charge).
5.7. L'indication du nom de serveur chiffré (ESNI) est prise en charge.
5.8. Les en-têtes de réponse du serveur (en-têtes de réponse HTTP) contiennent un en-tête Content-Security-Policy avec la directive upgrade-insecure-requests.