in Non-Browser Software Martin Georgiev The University of Texas at Austin Subodh Iyengar Stanford University Suman Jana The University of Texas at Austin Rishita Anubhai Stanford University Dan Boneh Stanford University Vitaly Shmatikov The University of Texas at Austin ABSTRACT SSL (Secure Sockets Layer) is the de facto standard for secure In- ternet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established. We demonstrate that SSL certificate validation is completely bro- ken in many security-critical applications and libraries. Vulnerable software includes Amazon’s EC2 Java library and all cloud clients based on it; Amazon’s and PayPal’s merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware—including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android—and all applica- tions employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack. The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present devel- opers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations. Categories and Subject Descriptors C.2.0 [Computer-Communication Networks]: General—Secu- rity and protection; K.4.4 [Computers and Society]: Electronic Commerce—Security cations. The main purpose of SSL is to provide end-to-end security against an active, man-in-the-middle attacker. Even if the network is completely compromised—DNS is poisoned, access points and routers are controlled by the adversary, etc.—SSL is intended to guarantee confidentiality, authenticity, and integrity for communi- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- tablishment.1 This authentication takes place during the SSL hand- shake, when the server presents its public-key certificate. In order for the SSL connection to be secure, the client must carefully verify that the certificate has been issued by a valid certificate authority, has not expired (or been revoked), the name(s) listed in the certifi- cate match(es) the name of the domain that the client is connecting to, and perform several other checks [14, 15]. SSL implementations in Web browsers are constantly evolving through “penetrate-and-patch” testing, and many SSL-related vul- nerabilities in browsers have been repaired over the years. SSL, however, is also widely used in non-browser software whenever secure Internet connections are needed. For example, SSL is used for (1) remotely administering cloud-based virtual infrastructure and sending local data to cloud-based storage, (2) transmitting cus- tomers’ payment details from e-commerce servers to payment pro- cessors such as PayPal and Amazon, (3) logging instant messenger clients into online services, and (4) authenticating servers to mobile applications on Android and iOS. These programs usually do not implement SSL themselves. In- stead, they rely on SSL libraries such as OpenSSL, GnuTLS, JSSE, CryptoAPI, etc., as well as higher-level data-transport libraries, such as cURL, Apache HttpClient, and urllib, that act as wrappers around SSL libraries. In software based on Web services, there is an additional layer of abstraction introduced by Web-services mid-