HTTPS Woes: The Most Dangerous Code In the World (Validating SSL Certificates in Non-Browser Software)

Last week, I attended a talk from Professor Dan Boneh at Stanford University.  The talk was about our well-received, most common secure communication mechanism called SSL.  Recently he found that so many well-known IT companies have dangerous security vulnerabilities due to this common SSL mechanism.  This post will describe what are the problems, and how many (and, which) companies had such a problem on their software components.

Fig. 1. How SSL protocol works between Client and Server

You probably have experiences of getting "certificate warnings" when you're browsing some websites starting with "https://".  This tells you that there is a suspicious SSL certificate that does not look like a general, proper certificate from the website.  Usually, HTTPS connection is made based on SSL protocol, and the SSL requires a certificate issued by the website.  Let us assume that we have an attacker in the middle of web browser and the web server, so that the attacker intercepts both packets in the middle of you and the server by mimicking as a web server (when communicating with you), and a web browser (when communicating with the server).  In that case, validating SSL certificates can prevent such an attack called MITM (man-in-the-middle).  This is a reason why Google Chrome browser make a Big Red Screen warning page when it received a bad certificate.  So, you can just be free from such kinds of attacks.  Thus we're fine as far as we do browsing using a Google Chrome.

However (as you know, the main article starts here), many existing non-browser software components do not really care such a SSL's certificate validation process.  The researchers found that there are so many well-known IT companies who just had no idea how SSL works, and what they are skipping when using SSL protocol.  If you're a user of web-payment solutions, and/or online e-commerce platforms, you'll be say "No Way!!!" in 5 seconds when you read the next paragraph of this post.

Here were the companies who skipped the SSL certificates by accidents (or, mistakes): Amazon, Paypal, AIM, FilesAnywhere, Rackspace, TextSecure, Trillian, Lynx Browser, Tweepy, AdMob SDK, ZenCart, osCommerce, Ubercart, PrestaShop, and sort of Apache open-source projects.
- note that, most of them were fixed their code right before/after when Prof. Dan Boneh's published paper was presented at ACM CCS'12.

Fig. 2. Protocol stacks and their software libraries

The problem was, basically from the developer's misuse of the SSL related libraries (e.g., libcurl, urllib in C, Python).  That's because the developers are not so familiar with SSL (since they shouldn't need to know the details, but use simpler wrappers), and also mostly the library wrappers have the crazy programming interfaces and functionalities.  

Here is an example; if you are using a libcurl (cURL library), you should be able to turn-on the optional parameters for SSL certificate validation.  Here are two optional parameters and their setting values to validate SSL certificate:

• CURLOPT_SSL_VERIFYPEER = true 
  
• CURLOPT_SSL_VERIFYHOST = 2 
  (NOTE THAT, THIS IS AN INTEGER, NOT BOOLEAN.) 

Actually, libcurl has very bad documentations, but recent libcurl (7.10) made a 'Good' default settings, so that all the two parameters are set by default.  Thus, we shouldn't have any problems on validating SSL certificates.

However, there are still many software components using older libcurl (<7.10), and the developers usually make mistakes like PayPal did:

Fig. 3. PayPal's initial code on libcurl optional parameter setting for SSL certificate validation

Initially, PayPal used a "FALSE" for two settings.  What we can just expect is, they wanted to skip all the SSL certificate validation.  The most interesting thing is, they "fixed" their code to do some validation like this (in April 2012):

Fig. 4. PayPal's second mistake on optional parameter setting for SSL certificate validation

In Fig. 3, they still have a problem because the second parameter should be set as "2", not as "TRUE == 1".  When the second parameter is set as "1", libcurl verifies just existence of any SSL certificate, and skip the validation process of the existing SSL certificate.  It would be better to provide a "BOOLEAN" parameters not a mixture of boolean and integers.

Similarly, Python has really simple (but bad for security) implementation on the popular library called urllib.  Usually developers have lack of time to do coding, so they usually do not thoroughly (or, carefully) read the documentations.  But on the documentation of the urllib, there is a disclaimer (warning) for developers using this library: (READ THE WARNING ON THE PINK BOX)

Fig. 5. Warning message on the urllib library

Anyhow, there are so many misuses of SSL-related libraries, so that they can be exploited by attackers. If you have any projects with libcurl and/or urllib on Python for commercial purpose, you should double check whether if your software has the same problem as described above.

Since I had an experience of "theft of my credit card numbers in wired communication" when I was living in France in 2010.  During the time, I bought some goods via several web-sites, and I now suspect that there were the same or similar problems.
I also hope that there were no identity thefts from the Amazon and PayPal payment systems.

If you're interested in reading more specific information, please refer to this original article in HERE.

- written by ANTICONFIDENTIAL, at SF, in April 19, 2013