Not all TLS scanners are the same

Getting an A+ rating for your managed web server settings from one of the popular TLS scanners can make you feel euphoric, and for no reason at all.

For example,

this web server

the two most popular TLS scanners are rated A+, although

All

the cipher suites it supports are weak or vulnerable, and a static DH key is used to create the session key, and that’s not counting the minor quibbles.

Simply put, today a properly configured browser should refuse to establish a secure connection with this server so as not to mislead its user about its level of “security”, but SSL Server Test by Qualys sees only “certain shortcomings”A according to ImmuniWeb SSL Security Test, only TLS 1.3 support is missing from the ideal. It’s all about their evaluation methods.

SSL Server Test by Qualys evaluates scan results according to its own methodology – SSL Server Rating Guide, the last changes to which, judging by the changelog, were made at the beginning of 2020. It cannot be said that because of this the methodology has become irrelevant today: it was so from the very beginning because of the standards on which it relies.

Firstly, these are nameless, but obviously antique “FIPS requirements” eight years ago, secondly, NIST SP 800-57 Part 3 in the 2009 edition, which was declared obsolete back in 2015, and finally – PCI DSS in revision 3 .“be afraid of Diffie-Hellman.”1 (3.5 new editions have been released since then).

As a result, although the Qualys test marks the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA as weak, assigns the highest (according to its methodology) reliability rating to the web server that supports it. Moreover, such a rating is received by a web server that does not support any strong (AEAD) cipher suite at all. (As an advertisement: our methodology does not allow such a web server to get a rating higher than B).

Finally, the SSL Server Test does not check whether the web server supports the Extended Master Secret extension, without which the TLS connection to the server is vulnerable to a three-way handshake attack.

Against this background, ImmuniWeb SSL Security Test looks advantageous, which relies to the obsolete but still non-fossil edition of PCI DSS – 3.2.1, HIPAA (adopted in 1996, but does not establish its own requirements for TLS settings) and NIST SP 800-52 (in an unknown edition, but we assume that in the current one – second).

Alas, this scanner only looks advantageous, as it marks the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA as “good configuration” and also gives the web server that supports it an A+ rating.

For those who have not been interested in ~~news~~ bayans of cryptography: 3 out of 4 cryptographic algorithms used in this cipher suite ~~Today~~ For several years now, RSA (for key agreement), CBC and SHA (not to be confused with SHA256 and SHA384) have been recognized as weak, insufficiently reliable or simply “leaky”.

Let me remind you that we are considering the situation as of 2023 in the universe where in 2005 the NSA published Suite B Cryptographyand in 2009 the Internet Engineering Council – RFC 5430 Suite B Profile for Transport Layer Securitywho even then demanded from those who respect ~~myself~~ their visitors to web servers supporting TLS 1.2 with AEAD cipher suites, and which, in turn, have been replaced by more relevant (read – strict) standards for more than a year.

Of course, the “market” is not limited to these two scanners, but … but Mozilla Observatory And Online Domain Tools cannot process “two-legged” TLS certificates and therefore consider Let’s Encrypt certificates to be invalid. Internet.nl And Wormly show only the basic settings of the server (and the devil, as you know, lies in the details). Reputed to be a picky (in a good way) Hardenize sees no problem in support of the same cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (perhaps because he himself supports it). At the same time, Hardenize notes the problems of our experimental server with forward secrecy (forward secrecy), but does not explain what they are.

With import substitution in the area under consideration, too, did not work. “Open service for auditing the security and correctness of the settings of Internet nodes” from TCI is in a permanent state of “beta” (although it is not inferior to some finished products in terms of capabilities), and “Free online check of TLS/SSL server and website” in fact, only a “wrapper” to the notorious testssl.shand even then it regularly bugs or does not work at all.

Who is guilty?

Standards, or rather their absence. None of the above standards is a web server security standard. HIPAA establishes general requirements for the processing of medical information, incl. in “paper” form, and does not say anything specific about setting up web servers. PCI DSS is a data security standard for the payment card industry that sets standards incl. for ATMs manufactured in the last century, which no one will change until they crumble to dust, and

~~shoot yourself in the foot~~

the developers of the standard are not ready to declare them unsafe because

~~pure and disinterested humanism~~

an understandable desire not to be sent away with a standard that no one can meet.

And even NIST SP 800-52, even in the latest revision 2 for today, is a standard not for web servers, especially public ones, but for all US government information systems in general, which applies to both new tablets and mainframes, which still under Reagan, they simulated a nuclear war with the USSR, and which have every chance of being finalized before it starts. All this infrastructure must somehow (at least relatively) safely communicate with each other, for example, by protecting the connection with a cipher suite TLS_DH_RSA_WITH_AES_128_CBC_SHAwhich NIST SP 800-52r2 considers normal for 2023 subject to the above.

Not surprisingly, NIST SP 800-52r2 “permits” the use of the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHAbut with the proviso that this is undesirable and allowed only in cases where there is no choice. In the case of a secure connection “public web server – browser” the choice has long been, however, Qualys and ImmuniWeb missed the NIST caveat when developing their methods.

What to do?

1. Look not at the rating assigned to the web server by the TLS scanner, but at the “raw” scan results. Supporting only AEAD cipher suites on a public web server is a good thing, even if its final rating is low (which no doubt signals some other shortcomings).

2. Check your server with several TLS scanners, since not a single (known to me) public scanner shows the whole picture. The most complete data on the TLS settings of the web server is shown by the already mentioned testssl.sh, but it will have to be raised on the local machine (Kali Linux to help).

3. To conduct additional checks on the security of the connection between the web server and its visitors, you should also pay attention to the following online tests:

Any additions to this list? Share in the comments. Personally, I would like to know about web services or utilities run from a local Windows PC that allow you to check for Encrypted Client Hello (ECH) support on a web server and Subresource Integrity (SRI) on a site.