La législation exige que les sites Web des autorités exécutives fédérales assurent le cryptage et la protection des informations transmises . Comment les constructeurs du « Runet durable » ont-ils géré la protection de leurs propres sites et le respect des exigences pertinentes des actes juridiques ?
Teaser : il s'agit d'un élément supplémentaire à la section « Confidentialité » du rapport « Sécurité de l'information des sites Web des organismes d'État de la Fédération de Russie : résultats anormaux . »
Cette année, nous avons commencé à utiliser une nouvelle méthodologie d'évaluation de la mise en œuvre sur les sites Internet des agences gouvernementales du protocole HTTPS dans le cadre du projet « Monitor of State Sites » , dont chaque critère a été formalisé et décrit. Pour la première fois, nous l'avons testé dans l' étude des sites des services de l'État , et maintenant nous l'avons appliqué dans l'étude annuelle des sites des organes de l'État de la Fédération de Russie. Les critères sont divisés en cinq groupes :
Minimum (Groupe D) :le non-respect d'au moins l'un d'entre eux signifie que le site ne peut être considéré comme supportant une connexion sécurisée. Il n'y a que deux critères dans ce groupe : le serveur Web doit répondre avec un code d'état HTTP de 200 ou 301 lorsqu'il est accédé avec l'identifiant de protocole HTTPS sur le port 443, et doit transmettre un certificat TLS valide au client. « Non », ou vice versa. À ce sujet, les sites Web du ministère de la Défense (le certificat a déjà été réémis plus tôt que prévu) et du Service pénitentiaire fédéral ont été remplis, et sur le site Web de Rostekhnadzor, il y avait simplement un certificat invalide (d'un autre hôte). Ainsi, 4% des sites étudiés ne maîtrisaient pas les standards de base du
Si tout s'est avéré simple avec le respect du premier critère - soit oui ou non, alors avec le second, la "logique ternaire" a été activée - oui / non / peut-être. "Peut-être" signifie ici que si le site est accessible par un seul nom d'hôte, alors "oui", et si vous ajoutez le sous-domaine www à l'adresse, alors
De base (Groupe B) :le non-respect d'au moins l'un d'entre eux signifie que le site ne supporte formellement qu'une connexion sécurisée, qui dans les faits peut s'avérer non sécurisée. Il y a déjà six critères dans ce groupe, réunis par le slogan « 2021 is in the yard » : l'absence de vulnérabilités sérieuses avec l'identifiant CVE sur le serveur web, la désactivation de la compression TLS, le support des extensions TLS standard de facto, etc. est requis.
Tous les sites ne répondaient qu'à deux critères : les paramètres de certificat TLS et la compression TLS désactivée. Du journal d'observation des potins : 100 % utilisent un certificat TLS signé à l'aide de l'algorithme RSA, et aucun à l'aide de l'ECDSA.
Le ministère des Finances, Rosreestr et Rosstandart n'ont pas entendu parler de l'extension Fallback SCSV. Le ministère des Affaires étrangères, Rosreestr, Rosalkogolregulirovanie, Rosstandart et la Banque centrale ne savent pas qu'en 2021, la réconciliation n'est que sûre. Le ministère du Développement économique, Rosreestr, Roszdravnadzor, Rosnedra et la FSS ne savent pas en quelle année nous sommes - leurs sites brillent sur Internet avec des vulnérabilités découvertes il y a près de dix ans.
Les sites du ministère du Développement économique et de Roszdravnadzor proposent aux visiteurs la
Près de la moitié (47%) des administrateurs de sites d'État n'ont pas entendu parler de l'extension Extended Master Secret, qui a reçu le statut RFC dans le lointain (pour les 53% restants) 2015.
Au total, 52% des sites d'état étudiés n'ont pas pu franchir même le cadre plutôt modeste du groupe D.
Recommandé (Groupe B) :le respect de chacun d'eux est requis pour considérer la prise en charge d'une connexion sécurisée satisfaisante. Il y a sept critères et rien d'extraordinaire non plus : prise en charge uniquement de HTTPS, TLS 1.2 et supérieur, suites de chiffrement AEAD, paramètres de protocole DH stables, etc.
Tous ont pris en charge uniquement la prise en charge de TLS 1.2 et des courbes elliptiques standard. 12% n'ont pas répondu aux exigences des paramètres DH ("secret proactif"), 15% n'ont pas trouvé la force d'abandonner le support HTTP, 37% ne supportent pas les suites de chiffrement AEAD, 36% n'ont pas pu leur donner la priorité sur les suites de chiffrement faibles , et 15 % ont eu le même problème lors de la définition de la priorité des courbes elliptiques standard sur n'importe quelle sect283k1 ou sect409r1 (à qui Rosstandart suggère-t-il ces courbes pour la correspondance ?)
À ce stade, 15 % supplémentaires des sites d'État ont abandonné la course.
Supplémentaire (Groupe A) : le respect de celles-ci fournira une fiabilité supplémentaire de la connexion sécurisée. Les critères sont pour la plupart simples : la chaîne de certificats TLS est correctement transmise, la transparence des certificats, CRL / OCSP, HSTS sont pris en charge et les versions obsolètes de TLS, les suites de chiffrement non AEAD, les courbes elliptiques non standard ne sont pas prises en charge. Une question de quelques commandes dans la console, et un certificat sans CT ou OCSP aujourd'hui encore aller le chercher.
Donc, personne n'a reçu de certificat "opaque" - les autorités de certification connaissent leur métier, mais quand il s'agissait de travailler avec les stylos eux-mêmes et de réparer les configs des serveurs Web ...
35% des sites d'État n'ont pas pu transférer la chaîne correcte de certificats TLS - ils y incluent une "ancre", ne transfèrent pas les certificats intermédiaires, etc. 69% ne maîtrisent pas l'en-tête HSTS - ils ne le transmettent pas du tout, ils le transmettent de manière incorrecte ou incomplète. Le ministère de l'Agriculture devrait être particulièrement offensé - sinon, son site serait devenu le seul du groupe A.
18% des sites, avec des courbes elliptiques standard, sont prêts à offrir à leurs visiteurs des exotiques, par exemple, brainpoolP512r1 ou sect283k1. Chers développeurs nginx, veuillez désactiver toutes les courbes par défaut, sinon le secteur public lui-même ne peut pas comprendre en quoi secp256r1 diffère de brainpoolP256r1 ou secp256k1, et juste au cas où il les laisserait toutes (pour ceux qui ne sont pas immergés dans le sujet, ce sont des courbes différentes, qui n'ont qu'un nom similaire).
57% des sites prennent en charge les suites de chiffrement non AEAD (bien que, comme nous l'avons montré précédemment , cela n'ait aucun sens pratique aujourd'hui, ainsi que la prise en charge des versions TLS inférieures à 1.2, sans parler de SSL). Cependant, il convient de noter ici que nous considérons le support de certaines suites de chiffrement seulement, qui sont réellement utilisées aujourd'hui, comme conforme au critère, de sorte que le support de certains ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 ne répond pas à nos critères, puisque c'est AEAD, mais pas vraiment soutenu par personne.
47% des sites ne peuvent pas se séparer de TLS 1.0 et 1.1 (et Rosreestr et FSS - avec SSL), même en dépit du fait que l'IETF les a finalement
Hélas, personne n'a fait face aux critères du groupe A, et seuls 6 (7%) sites pourraient être dans le groupe B, félicitons les lauréats : le Ministère de l'Agriculture, le Ministère de l'Intérieur, le Ministère des Situations d'Urgence, Rosarchiv , le ministère de l'Éducation et des Sciences et l'Agence fédérale de gestion immobilière.
Extended , dont le respect est recommandé pour assurer une fiabilité et une sécurité maximales d'une connexion sécurisée, mais qui peut être indésirable ou inaccessible dans certains cas.
Aucun site ne prend en charge la CAA et uniquement les courbes elliptiques sûres. Cependant, seuls Curve25519 et Curve448 répondent au dernier critère, tous deux ne sont pris en charge que par les versions modernes des navigateurs, ce critère n'est donc actuellement pas recommandé pour des raisons d'accessibilité du site.
10 % des sites prennent en charge DNSSEC, 6 % prennent en charge l'agrafage OCSP, mais aucun d'entre eux ne nécessite l'agrafage d'un certificat TLS avec une réponse CA sur son statut (OCSP doit agrafer). 5% prennent en charge TLS version 1.3, mais aucun ne prend en charge Encrypted ClientHello (ECH). Et seuls les sites Web du ministère des Transports et de Rosstat transmettent à leurs visiteurs l'en-tête HTTP Content Security Policy avec la directive upgrade-insecure-requests.
Au total, les sites Web de 22 % des organismes gouvernementaux de la Fédération de Russie ne prennent pas en charge HTTPS, bien que 15 % soient tenus desoutien, puisqu'ils sont les sites des autorités exécutives fédérales. 56% d'entre eux prétendent prendre en charge HTTPS, mais ne le font que de manière formelle. C'est-à-dire que moins d'un quart des sites par lesquels des informations sur les activités des organes de l'État sont diffusées, des documents sont soumis à ces organes, des données personnelles et d'autres informations sensibles sont transférées à leurs visiteurs, un niveau de protection de connexion acceptable est fourni à leurs visiteurs.
Je suis toujours sceptique quant à la possibilité que ces gens construisent un analogue du Grand Firewall de Chine, et vous ?