Back in 2002 I realized that having libcurl not do SSL server verification by default basically meant that everyone writing libcurl apps would inherit that flaw, simply because most people always just let the defaults remain unless they really have to read up on what something does and then modify them. If things work, things will just remain. So when we shipped libcurl 7.10 on the first of October that year, libcurl started verifying server certs by default.
Fast forward about ten years.
Surely SSL clients everywhere now do the right thing?
One day a couple of months ago, I was referred to this bug report for the pyssl module in Python which identifies that it doesn’t verify server certs by default! The default SSL handler in Python doesn’t verify the certificate properly. It makes all python programs that use this without special attention vulnerable for man in the middle attacks.
So let’s look at the state of another popular language: PHP. A plain standard PHP program opens a ssl:// or tls:// stream. Unless the author of said program knows and understands these things, it too runs without verifying server certs. If a program instead decides to use the PHP/CURL binding for HTTPS or similar, it will use libcurl’s default which verifies it (as I explained above).
But not everything is gloomy. Some parts of our community have decided to do the right thing:
I was told (and proven) that Ruby now does the right thing, but I don’t know how recent that is and thus how many older Ruby programs that suffer.
The same problem existed with perl’s major HTTPS using module, the LWP, for a very long time. The perl camp however already modified LWP to do verification by default with the release of libwww-perl 6.00, released in March 2011.
Side-note: in the curl project we make it easy for everyone on the Internet to use Firefox’s excellent CA cert bundle to verify server certs by providing the Firefox CA cert collection converted to PEM – the preferred format for OpenSSL, GnuTLS and others.
Conclusion:
Even today, lots and lots of applications and scripts will remain insecure – even though they probably think they’re fairly safe when they switch to a HTTPS or SSL using protocol – Â and might be subject for man-in-the-middle attacks without even being able to spot it. I think it is pretty sad.
One of the obstacles for using SSL verification, is that it is (was) often costly to get your certificate signed by a CA that is trusted by the majority of browsers; I believe some services used self-signed certificates simply because they were free.
The situation is improving though: I know that at least at startssl.com, you can get a basic certificate (that is trusted by major browsers) for free. Cacert.org is a good example of how the community can organize a CA; unfortunately, it is not included by default (except perhaps in Debian?).