TLS cipher distribution in 2026: a 600-host measurement

On 27 August 2026 we opened a TLS connection to 600 hosts (150 per zone) and recorded what the two sides agreed on. 501 hosts answered over TLS:

The last column is what matters. Not a single connection over TLS 1.0 or 1.1 in any zone. Talk of "legacy protocols still enabled" lost its subject by 2026: browsers switched them off and servers followed.

And on TLS 1.3 the .ru zone runs level with the international ones — 81% against 75–84%. This is a case where the Russian segment does not trail at all.

Caveats: these are domains somebody brought to our tools, not a slice of a zone. Non-responders are excluded from the denominator.

Among connections where a cipher could be determined:

Differences between zones sit within a few percentage points — that is, the cipher is essentially the same everywhere. Which is expected: TLS 1.3 cut the suite list to five, and the choice among them is made by a library default rather than by an administrator.

ChaCha20 appeared 3 to 6 times per zone. It is preferable on devices without hardware AES acceleration, but modern processors have it, so servers usually pick AES.

On 3 to 8 hosts per zone a connection established without a determinable cipher; those are excluded from the denominator.

The practical conclusion here is a reassuring one: hand-picking a cipher list in 2026 serves no purpose. Modern OpenSSL and nginx defaults produce exactly what is needed, while a hand-written list more often breaks compatibility than improves anything.

This is the one substantial difference between zones:

Elliptic-curve certificates are twice as rare in the .ru zone. The difference is not cosmetic: an ECDSA key is shorter at equivalent strength, so the handshake costs less computation and fewer bytes on the wire. On a mobile connection that shows most.

The cause is most likely the same as in our other measurements — not an administrator’s choice but the default of whoever issues the certificate. A hosting panel or a certificate authority integration issues RSA by default, and nobody switches.

It fits the wider pattern: on CAA records and on DNSSEC the Russian web trails by an order of magnitude, while on what is configured on your own server — HSTS and the TLS version — it barely trails at all. Certificate key type falls squarely into the first category.

1. Confirm TLS 1.3 is enabled. If your server negotiates 1.2, the cause is either an old OpenSSL or an explicit protocol list in the configuration that was never updated.
2. Do not specify a cipher list by hand. The defaults give the same result everyone else in our measurement gets, and they do not go stale along with your configuration.
3. Look at what certificate you have. If it is RSA and your authority supports ECDSA, the switch is free and yields a faster handshake. For compatibility with old clients you can serve both certificates at once.
4. Do not spend time disabling TLS 1.0 and 1.1. By our data they are already gone; if your configuration still permits them the harm is negligible, because no modern client will offer them.

To check your own configuration, use the SSL and TLS checker.