The legislation requires the federal executive authorities' sites to provide encryption and protection of the transmitted information . How did the builders of the "sustainable Runet" cope with the protection of their own sites and compliance with the relevant requirements of the legal regulations?
Teaser: this is an additional material to the "Confidentiality" section of the report "Information Security of Websites of State Bodies of the Russian Federation: Abnormal Results . "
This year, we began to use a new methodology for assessing the implementation of support on the websites of government agencies of the HTTPS protocol within the framework of the "Monitor of State Sites" project , each criterion of which was formalized and described. For the first time we tested it in the study of the sites of state services , and now we have applied it in the annual study of the sites of state bodies of the Russian Federation. The criteria are divided into five groups:
Minimum (Group D):non-compliance with at least one of them means that the site cannot be considered supporting a secure connection. There are only two criteria in this group: the web server must respond with an HTTP status code of 200 or 301 when accessed with the HTTPS protocol identifier on port 443, and must transmit a valid TLS certificate to the client.
If everything turned out to be simple with the compliance with the first criterion - either yes or no, then with the second, "ternary logic" was activated - yes / no / maybe. “Maybe” here means that if the site is accessed by one host name, then “yes”, and if you add the www subdomain to the address, then
Thus, 4% of the sites studied did not master the basic rules of the HTTPS
Basic (Group B):non-compliance with at least one of them means that the site only formally supports a secure connection, which in fact may turn out to be unsecured. There are already six criteria in this group, united by the slogan "2021 is in the yard": the absence of serious vulnerabilities with the CVE identifier on the web server, disabling of TLS compression, support of de facto standard TLS extensions, etc. is required.
All sites coped with only two criteria - TLS certificate parameters and disabled TLS compression. From the diary of observing gossites: 100% use a TLS certificate signed using the RSA algorithm, and none using ECDSA.
The Ministry of Finance, Rosreestr and Rosstandart have not heard of the Fallback SCSV expansion. The Foreign Ministry, Rosreestr, Rosalkogolregulirovanie, Rosstandart and the Central Bank do not know that in 2021, reconciliation is only safe. The Ministry of Economic Development, Rosreestr, Roszdravnadzor, Rosnedra and FSS do not know what year it is - their sites are shining on the Internet with uncovered vulnerabilities almost ten years ago.
Sites of the Ministry of Economic Development and Roszdravnadzor offer visitors
Almost half (47%) of state site administrators have not heard of the Extended Master Secret extension, which received RFC status back in the distant (for the remaining 53%) 2015.
In total, another 52% of the studied state sites could not step over even the rather modest framework of group D.
Recommended (Group B):compliance with each of them is required in order to consider the support of a secure connection satisfactory. There are seven criteria and nothing extraordinary either: support only for HTTPS, TLS 1.2 and higher, AEAD cipher suites, stable DH protocol parameters, etc.
All coped with only support for TLS 1.2 and standard elliptic curves. 12% did not cope with the requirements for DH parameters ("proactive secrecy"), 15% did not find the strength to abandon HTTP support, 37% did not support AEAD cipher suites, 36% could not give them priority over weak cipher suites, and 15% had the same problem when setting the priority of standard elliptic curves over any sect283k1 or sect409r1 (to whom does Rosstandart suggest these curves for matching?)
At this stage, another 15% of state sites dropped out of the race.
Additional (Group A): Compliance with them will provide additional reliability of the secure connection. The criteria are mostly simple: the TLS certificate chain is transmitted correctly, Certificate Transparency, CRL / OCSP, HSTS are supported, and outdated versions of TLS, non-AEAD cipher suites, non-standard elliptic curves are not supported. A question of a couple of commands in the console, and a certificate without CT or OCSP today still go get it.
So no one received an "opaque" certificate - the certification authorities know their business, but when it came to working with the pens themselves and fixing the configs of web servers ...
35% of state sites were unable to transfer the correct chain of TLS certificates - they include an "anchor" in it, do not transfer intermediate certificates, etc. 69% did not master the HSTS header - they do not transmit it at all, they transmit it is incorrect or incomplete. The Ministry of Agriculture should be especially offended - if not for this, its site would have become the only one in group A.
18% of sites, along with standard elliptic curves, are ready to offer their visitors exotic, for example, brainpoolP512r1 or sect283k1. Dear nginx developers, please disable all default curves, otherwise the public sector itself cannot figure out how secp256r1 differs from brainpoolP256r1 or secp256k1, and just in case it leaves them all (for those who are not immersed in the topic, these are different curves, which only have a similar name).
57% of sites support non-AEAD cipher suites (although, as we showed earlier , this makes no practical sense today, as well as support for TLS versions below 1.2, let alone SSL). However, here it should be noted that we consider the support of only certain cipher suites, which are actually used today, as compliance with the criterion, so that the support of some ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 does not meet our criteria, since it's AEAD, but not really supported by anyone.
47% of sites cannot part with TLS 1.0 and 1.1 (and Rosreestr and the FSS - with SSL), even though the IETF has finally
Alas, no one has coped with the criteria of group A, and only 6 (7%) sites could be in group B, let's congratulate the winners: the Ministry of Agriculture, the Ministry of Internal Affairs, the Ministry of Emergency Situations, Rosarkhiv, the Ministry of Education and Science and the Federal Property Management Agency.
Extended , compliance with which is recommended to ensure maximum reliability and security of a secure connection, but may be undesirable or unattainable in some cases.
No site supports CAA and only safe elliptic curves. However, only Curve25519 and Curve448 meet the last criterion, both of them are supported only by modern versions of browsers, so this criterion is currently not recommended for reasons of site accessibility.
10% of sites support DNSSEC, 6% support OCSP stapling, but none of them require stapling a TLS certificate with a CA response about its status (OCSP must staple). 5% support TLS version 1.3, but none support Encrypted ClientHello (ECH). And only the websites of the Ministry of Transport and Rosstat transmit the Content Security Policy HTTP header with the upgrade-insecure-requests directive to their visitors.
In total, the websites of 22% of government bodies of the Russian Federation do not support HTTPS, although 15% are required tosupport, since they are the sites of federal executive authorities. Another 56% pretend to support HTTPS, but do so only formally. That is, less than a quarter of the sites through which information about the activities of state bodies is disseminated, documents are submitted to these bodies, personal data and other sensitive information are transmitted to their visitors, an acceptable level of connection protection is provided to their visitors.
I'm still skeptical about the possibility of building an analogue of the Great Firewall of China by these people, and you?