Our main conclusion is that SSL certificate validation is completely broken in many critical software applications and libraries.
(emphasis original)
Vulnerable software includes Amazon’s EC2 Java library and all cloud clients based on it; Amazon’s and PayPal’s merchant SDKs… Chase mobile banking… any Android app that uses Pusher API to manage real-time messaging (for example, GitHub’s Gaug.es), clients of Apache ActiveMQ servers…
Instant messenger clients such as Trillian and AIM do not validate certificates correctly, either. A man-in-the-middle attack on Trillian yields login credentials for all Google (including Gmail), Yahoo!, and Windows Live services (including SkyDrive).
For the most part, the actual SSL libraries used in these programs are correct. Yet, regardless of which well-known library the software relies on—whether JSSE, OpenSSL, GnuTLS, or CryptoAPI, used directly or wrapped into a data-transport library such as Apache HttpClient or cURL—it often finds a way to end up with broken or disabled SSL certificate validation.
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, Vitaly Shmatikov, “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software,” Association for Computing Machinery Conference on Computer and Communications Security, October 2012.
For example, Amazon’s Flexible Payments Service PHP library attempts to enable hostname verification by setting cURL’s
CURLOPT_SSL_VERIFYHOSTparameter totrue. Unfortunately, the correct, default value of this parameter is 2 [ref – ed.]; setting it totruesilently changes it to 1 and disables certificate validation.
It’s patched*, but:
the state of adversarial testing appears to be exceptionally poor even for critical software such as mobile banking apps and merchant SDKs responsible for managing secure connections to payment processors.
More.
* The php binding; curl author Daniel Stenberg declined to inform four grad students and two professors that C doesn’t have true.