The Most Dangerous Code in the World:

Validating SSL Certificates in Non-Browser Software

by M. Georgiev, S. Iyengar, S. Jana, R. Anubhai,

D. Boneh and V. Shmatikov

Frequently Asked Questions

Last update: November 2, 2012

We found that many popular applications and middleware frameworks that use SSL/TLS break or disable certificate validation.  As a result, their SSL and TLS connections are vulnerable to a man-in-the-middle attacker.   These findings are presented in our paper “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software” published in the proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS).  This page provides answers to frequently asked questions about this work.

Q: Why should I care about SSL certificate validation?

A: SSL/TLS is the de facto standard for secure Internet communications. Security of SSL and TLS connections against an active, man-in-the-middle network attacker depends on correctly validating public-key certificates presented when the connection is established. This validation is the only authentication mechanism in SSL and TLS.  

If certificate validation is broken or disabled, an SSL- or TLS-protected connection is completely insecure against a man-in-the-middle attacker. Unless other security protections are used in addition to SSL/TLS, the attacker can read and/or modify any data transmitted over this connection. Depending on the application, vulnerable data may include login credentials to online services, financial account numbers and credentials, information about transactions and purchases including full credit card numbers and expiration dates, and other very sensitive data.

Man-in-the-middle vulnerabilities can be effectively exploited using rogue Wi-Fi access points at public locations such as Internet cafes and hotels. An attacker need only set up a rogue access point and wait for people to connect.  It is then straightforward for the attacker to tamper with traffic as it passes through the access point. Improperly validating server certificates - for example, not checking whether the name in the certificate matches the hostname of the destination or accepting self-signed certificates - renders SSL and TLS clients vulnerable to such man-in-the-middle attacks.

Q: Are SSL and TLS protocols secure?

A: As far as we know, the SSL 3.0 protocol (described in RFC 6101) and the TLS protocol (described in RFC 2246, RFC 4346, and RFC 5246) are secure.

 

Q: Is my favorite SSL/TLS library (OpenSSL, JSSE, GnuTLS, CryptoAPI, etc.) secure?

A: As far as we know, popular SSL/TLS implementations are secure with respect to the vulnerabilities we found.

Q: Is HTTPS in my favorite Web browser secure?

A: As far as we know, popular Web browsers (with the exception of Lynx prior to version 2.8.8) are secure with respect to the vulnerabilities we found.

Q: What is the problem, then?

A: Many popular applications, HTTP(S) and WebSocket transport libraries, and SOAP and REST Web-services middleware use SSL/TLS libraries incorrectly, breaking or disabling certificate validation.  Their SSL and TLS connections are not authenticated, thus they - and any software using them - are completely insecure against a man-in-the-middle attacker.

 

Q: What is the difference between an “SSL library,” “transport library,” and “Web-services middleware”?

A: An SSL library is an implementation of the SSL and TLS protocols.  Examples of SSL libraries include OpenSSL, GnuTLS, JSSE, and CryptoAPI.  

A transport library is an implementation of a data-transport protocol such as HTTP(S) or WebSocket. Typically, a transport library uses an SSL library internally. Examples of transport libraries include cURL and Apache HttpClient.

Web-services middleware is an implementation of a Web-services model such as SOAP or REST. Typically, Web-services middleware uses a transport library internally. Examples of Web-services middleware include Pusher and Apache Axis.

The following figure from our paper gives a high-level overview of the software stack:

Q: What is a “merchant SDK” or “payments SDK”?

A: This is the software that runs on an e-commerce website and transmits customers’ payment details to a payment processor such as PayPal or Amazon Flexible Payments Service. It is typically integrated with the site’s shopping-cart software.

Q: If an e-commerce website redirects my Web browser to Amazon or PayPal for payment, am I affected by the SSL vulnerabilities you found?

A: No.

Q: If an e-commerce website directly collects my payment information, am I affected by the SSL vulnerabilities you found?

A: You might be, if the site is using vulnerable shopping-cart or payment-processing software. Many popular open-source shopping carts, including osCommerce, Zen Cart, Ubercart, and PrestaShop, are insecure. Even if the shopping cart is secure, much of the payment-processing software provided to site operators by Amazon and PayPal was insecure prior to the updates released in July-October 2012 in response to our work (see the list below for the current status of bug fixes and updates).

Update from AWS: Amazon has released updated Amazon payments SDKs and notified all potentially impacted developers/merchants. Please see Amazon’s security bulletin.

Q: I am running an e-commerce website that accepts Amazon and/or PayPal payments. How is my site affected by the SSL vulnerabilities you found?

A: If your site is using vulnerable shopping-cart or payment-processing software, you can be defrauded by a fake Instant Payment Notification. You should immediately (1) switch to secure shopping-cart software that correctly validates SSL certificates, and (2) update to the latest versions of Amazon and PayPal payments SDKs (see the list below for the current status of bug fixes and updates).

Update from AWS: Amazon has released updated Amazon payments SDKs and notified all potentially impacted developers/merchants. Please see Amazon’s security bulletin.

Q: How can I tell if a particular website is using vulnerable shopping-cart or payment-processing software?

A: Ask the site’s operator.

Q: Is my favorite instant messenger secure?

A: Trillian and AIM Windows clients are not secure. If you use them to log into any online service - including Google, Yahoo, Microsoft/Windows Live, Facebook, etc. - your login information can be stolen by a man-in-the-middle attacker.

Update from Cerulean Studios: SSL certificate validation, including hostname verification, added in Trillian version 5.3 beta.

Q: Is my favorite cloud management or cloud storage software secure?

A: Maybe, maybe not. There is a wide variety of cloud clients, libraries, and SDKs which use different technologies and cloud APIs.

Q: Is my favorite HTTP(S) or WebSocket library secure?

A: This depends on whether your favorite HTTP(S) or WebSocket library uses the underlying SSL/TLS library correctly. Many SSL libraries, including OpenSSL and JSSE’s SSLSocketFactory, by default do not check whether the name in the certificate presented by the server matches the hostname to which the client is connecting.  Any software that uses these SSL/TLS libraries and does not do its own hostname verification is insecure! Notable examples of vulnerable HTTP(S) and WebSocket libraries include Apache HttpClient version 3.* and Weberknecht in Java, and urllib, urllib2, and httplib in Python. Read the paper for more details about SSL usage in transport libraries.

Q: Is my favorite SOAP or REST middleware secure?

A: This depends on whether your favorite SOAP or REST middleware is based on a secure transport library. If the middleware is using Apache HttpClient version 3.* or Weberknecht, it is insecure. Vulnerable middleware platforms include Pusher for Android, Codehaus XFire, and Apache Axis and Axis 2. All applications based on insecure middleware are automatically insecure! Read the paper for more details about SSL usage in Web-services middleware.

 

Q: Have these vulnerabilities been fixed?

A: We have reported all vulnerabilities to the vendors and/or developers of the affected software.  See the list below for the current status.

Q: How do I use cURL securely?  

A: CURLOPT_SSL_VERIFYPEER must be set to TRUE, CURLOPT_SSL_VERIFYHOST must be left to its default value or set to 2. Anything else, such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.

Q: How do I use Python HTTP(S) libraries securely?  

A: urllib, urllib2, and httplib are all insecure against a man-in-the-middle attacker. Your code should use the ssl module and explicitly call match_hostname for hostname verification.

Q: How do I use JSSE securely?  

A: Use HttpsClient or HttpsURLConnection.  If you must use SSLSocketFactory, keep in mind that it does not check whether the name of the host to which your program is connecting matches the name in the SSL certificate, and is thus insecure against a man-in-the-middle attacker.  Any code based on SSLSocketFactory must do its own hostname verification.

Q: How do I use OpenSSL securely?  

A: Read Chapter 10 of “Secure Programming Cookbook for C and C++” by Viega and Messier.

Q: How can I check whether an application I am using or developing contains an SSL certificate validation vulnerability?

A: You can download the code of our experimental man-in-the-middle server and use it for black-box testing of your applications. Note, however, that if our server fails to find an attack, this is by no means a proof or guarantee of security. There are many possible SSL certificate validation vulnerabilities which manifest in different ways; our server checks only for a few sample vulnerabilities.

In addition, iSEC put together three tools to help developers test their code.

Bug fixes in specific systems

Below we list the current status of bug fixes as reported to us by the providers of the affected software. Note that we have not verified whether these fixes close the vulnerabilities we discovered.

        US: https://payments.amazon.com/sdui/sdui/about?nodeId=201033780

        UK: https://payments.amazon.co.uk/help?nodeId=201033780

        DE: https://payments.amazon.de/help?nodeId=201033780

https://www.x.com/developers/paypal/documentation-tools/paypal-sdk-index