An invitation to discuss the methodology for compiling an index of HTTPS security of sites

We have already published several reviews of HTTPS support on the websites of Russian authorities and are faced with the inevitable need to more clearly formalize the criteria by which it is assessed. It is clear that if the server "confirms" the security of the connection with someone else's TLS certificate, then this is a "hat" and the corresponding site will not take a high place in the "rating".



But then less unambiguous questions arise, for example: is support for TLS_RSA_EXPORT_WITH_RC4_40_MD5 a complete "hat" or just a drawback? And if this cipher suite from the 60s and 90s is the first to be offered to the client for agreement? And if everyone else is not much better? And what is “much better”? Let's say TLS_PSK_DHE_WITH_AES_128_CCM_8 is better or not?



As a result, a methodology for compiling an index was born, which allows formally assessing the degree of reliability of an HTTPS connection by 31 points, broken down into 5 groups, from "this is not HTTPS at all" to "keep it up!"



What the index is definitely not, is the "Russian response" to NIST / HIPAA / PCI DSS, etc. for two reasons.



First, the index only considers the reliability of the HTTPS connection. Web server performance (NPN / ALPN / session resumption), etc. matter index does not consider, not for that it was invented.



The second is that NIST.SP.800 and other industry standards are guided by the NIST elliptic curves, in which there is little more than no confidence, but there are questions from the point of view of ECDLP / ECC (a perky remark about a foil hat can be left in the comments without exception ).



Although who knows, maybe over time a sovereign standard with spirituality and "Grasshopper" and "Magma" braces will grow from the index (but not before the IETF recognizes them as part of the standard cipher suites for TLS).



The main idea of ​​the index: in 2020, only TLS 1.2 and higher with the corresponding set of cipher suites and elliptic curves can be considered "real HTTPS". It's time for old cipher suites, even if they don't have known vulnerabilities, to the dustbin of history. Arguments about the need to support legacy clients are in favor of the poor: Windows XP is still popular, but its users do not roam the Internet today through Internet Explorer 8 with its prehistoric Schannel, but use Chromium / Firefox-based browsers that use NSS for this purpose ... The same applies to users of older versions of Android - they either installed an alternative browser that does not rely on the system crypto library, or they cannot use most modern sites even via HTTP (without CSS3 support and other modern whistle-blowing deals).



From these positions it is proposed to criticize the draft methodology. Have you taken everything into account? Did you tighten the nuts too hard? Didn't you misrepresent anything? Below is a list of criteria, and the link is a more detailed text, with notes and comments .



1. Minimum criteria



1.1. Encrypted HTTP (HTTPS) communication is supported using the cryptographic TLS protocol. An HTTPS connection is established with the protocol identifier (URI scheme) https over TCP port 443.



1.2. The encryption of the connection is validated by a valid, non-self-signed, and non-empty X.509 version 3 TLS site certificate issued by an authoritative certification authority (CA).



2. Additional criteria



2.1. The server is not susceptible to known vulnerabilities in the implementation of secure connection support (BEAST, POODLE, GOLDENDOODLE, etc.)



2.2. TLS compression is not supported.



2.3. Only server-initiated secure renegotiation is supported; client-initiated renegotiation is not supported.



3. Recommended criteria



3.1. The HTTP connection is automatically (forced) to switch to HTTPS.



3.2. The public key of the site's TLS certificates are ≥2048 bits long. The certificate is digitally signed using the ≥SHA256 algorithm with RSA or ECDSA encryption.



3.3. TLS protocol version 1.2 is supported.



3.4. SSL and TLS version ≤1.1 are not supported.



3.5. Standard cipher suites based on strong algorithms are supported.



3.6. Weak, unsuitable, and vulnerable cipher suites are not supported.



3.7. ECDLP / ECC-safe elliptic curves are supported.



3.8. The order of coordination of cipher suites is set.



3.9. The robust parameters of Diffie-Hellman (DH) key agreement algorithms are used.



3.10. Important TLS extensions are supported.



3.11. Server Name Indication (SNI) is supported.



4. Extended criteria



4.1. A complete and non-redundant TLS certificate chain has been published with their correct chain sequence.



4.2. The site's TLS certificate supports Certificate Transparency.



4.3. The site's TLS certificate supports Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).



4.4. TLS certificates in alternate chains comply with Criteria 1.2, 4.1.



4.5. ECDLP / ECC unsafe elliptic curves are not supported.



4.6. The order of matching of elliptic curves is set.



4.7. Server response headers contain the HTTP Strict Transport Security header with the includeSubDomains directive.



5. Bonus criteria



5.1. The site's TLS certificate supports OCSP Stapling.



5.2. The TLS site certificate is issued using an Organization Verification (OV) or Extended Validation (EV) procedure.



5.3. TLS protocol version 1.3 is supported.



5.4. The order of coordination of stable cipher suites from more resistant to less stable (by comparable parameters) is set.



5.5. The DNS resource records for the site domain name include a CAA (Certification Authority Authorization) record.



5.6. The DNS resource records for the site domain name include DS and TLSA records (DNSSEC and DANE are supported).



5.7. Encrypted Server Name Indication (ESNI) is supported.



5.8. Server response headers (HTTP response headers) contain a Content-Security-Policy header with the upgrade-insecure-requests directive.