SSLFail


Tyler and Marcin started the site SSLFail.com, which inspired me to do some digging of my own. The results are shocking!

A few words about the methodology: I took the top 1 000 000 sites list from Alexa (love them or hate them for their toolbars, but it is very nice of them to provide this list freely and without any registration or stuff – I admit that I went to their site with the intent to scrape it and was very pleasantly surprised). I feed the list to a simple multi-threaded Perl script which tried to download the https://$site/ URL (with cURL – BTW you can hear an interview with the creator of curl on FLOSS weekly) and recorded the error code. It managed to go over 358947 entries before the power went out, so here are the partial results 🙂

cURL error message cURL error code Number of sites Percent of sites
Couldn’t resolve host

6

228828

63.75

Failed to connect to the host

7

56985

15.88

The remote SSL certificate wasn’t ok

51

28971

8.07

SSL connect error

35

19427

5.41

Problem with CA cert

60

19367

5.4

No error

0

3577

1

Operation timeout

28

1791

0.5

The server didn’t reply anything

52

1

0

  Total

358947

 

Even if I ignore the errors associated with my network connection (the two largest categories “Couldn’t resolve host”, “Failed to connect to the host” and “Operation timeout”), and the one which seems to be a statistical fluke (“The server didn’t reply anything”), the sites which have their SSL certificates in order come in dead last (!) with 5%. How can we instruct people to look for proper SSL encryption when the sites themselves fail to provide such?

The biggest percent is made out of the “The remote SSL certificate wasn’t ok” case which seems to caused mostly by sites that reuse SSL certificates issued for other domains (for example google.it use the certificate for www.google.com).

The second biggest problem in case of SSL sites was “SSL connect error” (including on yahoo.com). These servers seems to keep port 443 server open, but don’t respond with anything. Are they tarpiting the connection? Why would they do that?

The last error (which still outnumbers the no-error cases by a factor of 5!) was “Problem with CA cert”. A cursory check seems to indicate that these are mostly self-signed certificates. While such certificates do provide some guarantees, it would be much better for them to use proper ones (they are not that expensive).

My (sad) conclusion: SSL == fail.

PS. The terminal23 blog contains further bad news. I thought that at least EV certificates (although way too expensive), at least they provide some guarantee that proper checks have been done. It seems not…

, , ,

One response to “SSLFail”

Leave a Reply

Your email address will not be published. Required fields are marked *