Halloween special

Since the Haloween is the time of scary stories, let me share with you some preliminary results of the new cipherscan results.

I’ve extended the tool to check different grades of TLS ClientHello intolerance, like TLS version, size of client hello and the results are scary indeed.

Over 3% of servers just in Alexa top 2000 sites are not RFC compliant (can’t process big ClientHello, ClientHello with extensions they don’t understand, ClientHello with high protocol version, like for TLSv1.2 or with cipher suites they don’t know).

Two servers in this set are strictly TLSv1.2 intolerant, that means they use TLS implementations that can’t handle new protocol version 6 years after its release!

Those are the servers which force web browsers to use the fallback mechanism or limit their cipher suite set.

47% have SSLv3 still enabled, making them possibly vulnerable to POODLE (if they support ciphers besides RC4 in SSLv3).


The new section added to statistics is “Required fallbacks”. It reports what kind of client connection attempts are problematic to servers the scan was still able to connect to.

The set of “big” hellos (big-SSLv3, big-TLSv1.0, big-TLSv1.1, big-TLSv1.2) are “Christmas tree packet” like connection attempts – where every option, extension and cipher suite supported by the OpenSSL tool was enabled.

In case the big-TLSv1.2 test was unsuccessful, the tool runs additional tests: “no-npn-alpn-status” where it queries the server again with a TLSv1.2 packet, but drops the NPN, ALPN and certificate status request (OCSP staple) extensions. “small-TLSv1.2” and “small-TLSv1.0” are reduced size packets, that still include SNI, elliptic curves (albeit limited to the P-256, P-384 and P-521 curves) and signature algorithms, but offer only limited set of ciphers, modelled after Firefox ClientHello. All those are from connections that were tolerant to at least one of the “big-” hello’s.

Then there are “inconclusive ” results, which show servers which the tool was able to connect to only using at least one of the “no-” or “small-” fallbacks but not using the “big-“. Such servers are not included in the general stats, but they do exclude servers which didn’t provide valid certificates.

SSL/TLS survey of 1693 websites from Alexa's top 2 thousand
Stats only from connections that did provide valid certificates
(or anonymous DH from servers that do also have valid certificate installed)

Supported Protocols       Count     Percent
SSL2                      44        2.5989
SSL2 Only                 4         0.2363
SSL3                      801       47.3125
SSL3 Only                 26        1.5357
SSL3 or TLS1 Only         295       17.4247
TLS1                      1663      98.228
TLS1 Only                 74        4.3709
TLS1.1                    1265      74.7194
TLS1.2                    1325      78.2634
TLS1.2, 1.0 but not 1.1   89        5.2569

Required fallbacks                       Count     Percent
big-SSLv3 Only tolerant                  22        1.2995
big-SSLv3 intolerant                     892       52.6875
big-SSLv3 tolerant                       801       47.3125
big-TLSv1.0 intolerant                   26        1.5357
big-TLSv1.0 or big-SSLv3 Only tolerant   2         0.1181
big-TLSv1.0 tolerant                     1667      98.4643
big-TLSv1.1 intolerant                   29        1.7129
big-TLSv1.1 tolerant                     1664      98.2871
big-TLSv1.2 intolerant                   49        2.8943
big-TLSv1.2 tolerant                     1644      97.1057
inconclusive small-TLSv1.0               7         0.4135
inconclusive small-TLSv1.2               7         0.4135
no-npn-alpn-status intolerant            49        2.8943
small-TLSv1.0 tolerant                   49        2.8943
small-TLSv1.2 intolerant                 2         0.1181
small-TLSv1.2 tolerant                   47        2.7761


  1. For what’s it worth: big-TLSv1.2 intolerant seems to be related with certain Cisco equipment. After lots of testing I noticed that some Cisco equipment can’t handle -tls1_2 only ClientHello requests when the number of ciphers is >128
    A case has been opened.
    Please let me know if you’re interested in a small Bash script which I use to fingerprint/test this Cisco equipment with.

    1. Yes, that would be interesting.

      The current mechanism for sending fallbacks is very preliminary and just more to get a relative feel for the amount of non-RFC compliant servers rather than to detect actual bugs (for one I can’t send TLS 1.0 client hello without any extensions using openssl CLI tool). I’d like to change it to a set of tests that try to detect specific bugs.

    2. Looks nice, but I probably won’t be able to add it to cipherscan – it’s under GPL while cipherscan is under MPL. Anyway, I’d probably add a test that verifies that the issue is not caused by the newly added cipher (that just happens to be on the 128th position).

    3. yes, I know that you can redistribute MPLed code under GPL, my point was that you can’t relicense GPL code under MPL so that the “larger Work” is still under MPL.

      Though I’m just second guessing Julien here, maybe he will be fine with that…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s