Last August, we wrote about the number of HTTPS requests and the share of TLS 1.3. We look at the current situation and changes in this post.
Always stay in the loop!
Subscribe to our RSS/Atom feed.
During last week, we observed the following numbers on our website:
- The share of TLS 1.3 requests was 81.5%. This is a small increase by 4.5% compared with August 2020. The remaining 18.5% are requests via TLS 1.2 with TLS cipher suites that are considered secure.
- 99.5% of these requests used AES instead of ChaCha20. Of course, this number may change, depending on the clients readers use.
- Most of the remaining TLS 1.2 requests came from Go-NEB (a Matrix bot), Python feedparser, OkHttp (an Android HTTP client), and Nextcloud.
Amazingly, many online assessment tools still don’t support TLS 1.3 or don’t recommend TLS 1.3 only:
- hardenize.com: It says, “This server doesn’t support TLS 1.2, which may be necessary to support a wide range of clients, including the ones that don’t yet support TLS 1.3.” It also fails to check for the Certificate Transparency compliance and support for DHE cipher suites if TLS 1.3 only is enabled on the web server.
- observatory.mozilla.org: The TLS Observatory doesn’t support TLS 1.3 at all. You won’t see any TLS cipher suites with TLS 1.3 only enabled.
- ssllabs.com: They mark missing TLS 1.2 support in yellow. There are no additional warnings but the overall score is downgraded from A+ to A in our case.
- tls.imirhil.fr: It reports that TLS isn’t supported by the web server. This is wrong and the result of missing support for TLS 1.3 by this website.
- immuniweb.com/ssl/: The check for OCSP stapling fails if TLS 1.3 only is enabled. Due to this, the scanner incorrectly shows issues with OCSP stapling.
Our brief check shows numerous issues with online assessment tools as soon as we enable TLS 1.3 only on our web server. The result highlights the pros and cons of these tools again. Never trust such scanners blindly. Always verify the output of tools.