Researchers Expose SSL Vulnerabilities in Libraries and Their Usage in Popular Non-Browser Services

Research students at The University of Texas at Austin and Stanford University published the results of their research that expose critical vulnerabilities in the usage of SSL libraries in non-browser applications that we expect to be highly secure. Highly secure and critical services include banking services and merchant SDKs for eCommerce and relatively less critical software include services such as cloud storage services and messaging services. The paper places the blame on the poor state of adversarial testing, unsafe SSL libraries, unsafe programmatic usage of safe SSL libraries, the complexity in troubleshooting vulnerabilities hidden deep in the stack and the pervasive but unsafe practice of disabling certificate validation by developers.

The threat model used by the team is an active,man-in-the-middle attack. The simulated man-in-the-middle attacks used three certificates: (1) a self-signed certificate with the same common name as the host the client is attempting to connect to, (2) a self-signed certificate with an incorrect common name, and (3) a valid certificate issued by a trusted certificate authority to a domain called AllYourSSLAreBelongTo.us. The man-in-the-middle attacks focuses on chain of trust verification and hostname verification but does not test for certificate revocation and X.509 extensions. The code for the threat model simulation can be downloaded here.

The paper shares relevant implementation details for developers that utilize SSL libraries: OpenSSL and JSSE and data transport libraries: Apache HttpClient, Weberknecht, cURL, PHP's fsockopen method and cURL binding and Python's urllib, urllib2 and httplib. Most of the SSL libraries perform certificate verification but leave some options open around hostname verification to the client which is ignored by most developers. For example, the JSSE low level API, SSLSocketFactory class automatically turns off hostname verification, if the algorithm field is null. Most clients in turn do not implement their own hostname verification scheme including Apache HttpClient which introduces security risks. The following snippet from the certificate verification method in SSLSocketFactory points out to this fact:

Such vulnerabilities percolate up the stack for any non-browser application using these libraries. For specific advice around correct implementation of clients utilizing SSL and data transport libraries refer to the FAQ provided by the authors of the paper.

DO use fuzzing (black-box, if necessary) and adversarial testing to see how the application behaves when presented with abnormal SSL certificates. Even when the vulnerabilities are subtle, the symptoms usually are not. In many of our case studies, it is obvious that the software in question has never been tested with any certificates other than those of the intended server. When presented with a certificate issued to AllYourSSLAreBelongTo.us instead of the expected Amazon or PayPal or Chase certificate, these programs eagerly establish SSL connections and spill out their secrets.These vulnerabilities should have manifested during testing.
DON’T modify application code and disable certificate validation for testing with self-signed and/or untrusted certificates. We found in our case studies that developers forget to reverse these modifications even for the production version of the software. Instead, create a temporary keystore with the untrusted CA’s public key in it. While testing your code with self-signed or untrusted certificates, use that keystore as your trusted keystore.
DON’T depend on the library’s defaults to set up the SSL connection securely. Default settings can and do change between different libraries or even different versions of the same library—for example, cURL prior to version 7.10 did not validate certificates by default, but version 7.10 and later do. Always explicitly set the options necessary for secure connection establishment.

and for SSL library developers:

DO make SSL librariesmore explicit about the semantics of their APIs. In many cases, it is obvious that application developers do not understand the meaning of various options and parameters. For example, the PHP libraries for Amazon Flexible Payments Services and PayPal Payments Standard attempt to enable hostname verification in cURL, but instead accidentally override the correct default value and end up disabling it (Sections 7.1 and 7.2). This shows that even safe defaults may be insufficient. Lynx attempts to check for self-signed certificates, but misinterprets the meaning of return values of GnuTLS’s certificate validation function and the check is never executed (Section 7.4). Formalizing the precise semantics of SSL library API and rigorously verifying the “contracts” between the application and the library is an interesting topic for future research and may call for programming language support.
DON’T delegate the responsibility for managing SSL connections to the applications. Existing SSL libraries expose many options to higher-level software. This is fraught with peril. Application developers may not realize that they must explicitly choose certain options in order to enable certificate validation. Therefore,libraries should use safe defaults as much as possible. Furthermore, they should not silently skip important functionality such as hostname verification as JSSE does when the algorithm field is NULL or an empty string (see Section 4.1). Instead, they should raise a runtime exception or inform the application in some other way.
DO design a clean and consistent error reporting interface. Libraries such as OpenSSL and GnuTLS report some errors via return values of functions, while other errors from the same function are reported through a flag passed as an argument. Inconsistent interfaces confuse developers who then mistakenly omit some errorchecks in their applications.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.