Authors: Martin Georgiev, Subodh Iyengar, Suman
Jana, Rishita Anubhai, Dan Boneh, Vitaly Shmatikov
By Jeremiah O’Connor
Background
 Focus specifically non-browser software
 SSL validation is defective in many applications and libraries
where security is essential:
 List of vulnerable software:
 Amazon’s EC2 Java library (&& related cloud clients)
 Amazon’s and PayPal’s merchant SDKs
 Integrated shopping carts
 Android apps and libraries (Big surprise here)
 Java Web-services middleware
 Codehaus XFire, and Pusher library for Android
(&& all applications employing this middleware)
 All of the above vulnerable to MiM
 Problem: poorly designed APIs of SSL implementations (ex. JSSE,
OpenSSL, GnuTLS) and data-transport libraries (ex. cURL)
 Analyze shortcomings of SSL certificate validation in software
based on these APIs, make own suggestions
Introduction
 SSL is widely used in non-browser software whenever a secure
Internet connection is needed
 Examples:
 (1) sending local data to cloud-based storage
 (2) sending customers’ payment details from E-Commerce servers to
payment processors (ex. PayPal and Amazon)
 (3) logging IM clients into online services
 (4) authenticating servers to mobile applications on Android and iOS.
 These programs do not implement SSL themselves, rather they
rely outside libraries
 Authenticating Server important part of SSL connection
 Authentication occurs during SSL handshake, when server hands
over public key certificate. For SSL connection to be secure, client
must verify the certificate has been issued by a valid CA

Verifications for certificate:
 Not expired/ revoked
 Name in certificate matches name of domain
client is connecting to, perform several other checks
Authors’ Contributions
 Authors conduct an in-depth study of SSL
connection authentication in non-browser
software, focusing on how different
applications and libraries on Linux, Windows,
Android, and iOS validate SSL server
certificate
 Black-Hat && White-Hat techniques
 Primary conclusion of article is that SSL
certificate validation is defective in important
software applications and libraries.
 Vulnerabilities exploited are errors in logic in
Client SSL certificate validation
 Main problem is poor design of APIs to the
SSL libraries
 API libraries are confusing, developers often
misuse, and in some cases introduce new
vulnerabilities themselves
Outline of Study Results
 Study uncovered an array of SSL Certificate Validation bugs
 Certificate validation bugs run rampant in merchant
software development kits, that run on E-Commerce
servers (ex. online stores) and responsible for sending
customers’ financial information to payment processing
gateways.
 Scary Surprise: Devastating bugs in Chase Mobile Banking
App for Android
 SSL connections that are established in this paper are
vulnerable to authors’ active MiM attack (Threat Model)
Causes
 Generally, the SSL libraries in
these programs are used
correctly. However, often in
the final product SSL
certificate validation is
defective/ disabled. Why?
 Primary cause: developer’s
misunderstanding of the
numerous options,
parameters, and return values
of SSL libraries
 Developers often
misinterpret security
guarantees provided by SSL
libraries.
 Other bugs include using
incorrect regular expressions
for hostname matching, not
checking the results of
certificate validation
correctly, accidentally or
intentionally disabling
certificate validation
Lessons
 1. Study uncovered poor vulnerability testing even for important software
such as mobile banking apps and merchant SDKs (responsible for
managing secure connections to payment processors)
2. SSL libraries unsafe by default, need better software to correctly set
options, provide hostname verification functions, and interpret return
values
 3. Default Safe libraries, ex. cURL’s wrapper around OpenSSL often
misused by developers
 Easily misinterpret the meaning of various parameters
 Better documentation and annotation of API semantics
 High-level vs. low-level
 4. SSL bugs hidden inside many layers of middleware
 Hard to locate and fix for developer
 5. Disabling certificate validation by
developers
 Tell users SSL is supported on
high level, but failure to disclose there
is no protection against active attacks
Authors’ Threat Model
 Assumptions: Man-in-the-Middle attacker
 May control network routers or switches, Wi-Fi access
points, and/or DNS.
 May control one or more servers and have valid SSL
certificates for servers
 Attacker
 (1) No access to private keys of
valid servers
 (2) No control of any certificate
authorities
 (3) Cannot forge certificates
Authors SSL Certificate Validation Model
 SSL connection starts with handshake between client and
server (Figure 1)
 Authors specifically focus on the client’s validation of the server
certificate.


Tests used X.509 certificates
Chain of Trust Verification
 Each X.509 certificate has an “issuer” field which has name of
certificate authority (CA) that issued the certificate.
 Every SSL client is set up with a list of certificates for trusted CAs.
 Hostname Verification.
 After chain of trust is established, client must verify server’s
identity.
 If client finds an exact match in the list of server identifiers,
verification is done by string comparison.
 Certificate revocation and X.509 extensions.
 Authors focus on verifying the server’s identity, but full certificate
validation involves many more checks.
 Checks are essential for security, but handled poorly or not at all
by non-browser software
SSL Libraries
 OpenSSL
 Hostname verification must be managed by the
application itself, or by data-transport wrapper (ex.
cURL)
 JSSE (Java Secure Socket Extension)
 Uses insecure low-level API SSLSocketFactory

Depending on implementation of SSL client, this API may or
may not perform hostname verification

Data
Transport
Libraries
Apache HttpClient:
 Uses JSSE’s insecure SSLSocketFactory
 Weberknecht: Java implementation of WebSockets protocol
 Uses insecure SSLSocketFactory, but does not perform own hostname
verification.
 Vulnerable to MiM attack
 cURL: a library allows you to make HTTP requests in PHP
 connect and communicate to many different types of servers with many
different types of protocols.
 In updated version, cURL validates SSL certificates by default.
 Interface is horrible! Ex. VERIFYPEER parameter is a boolean, similar
VERIFYHOST parameter is an integer
 Wide misunderstanding of parameters
 PHP: many ways to make SSL connection
 Widely used fsockopen does not perform
any certificate checks whatsoever
 Python- Python modules can be used for
SSL connection establishment
 urllib, urllib2, and httplib connect to
SSL servers but do not check certificates
SSL uses in Non-Browser Software
 Cloud Client APIs
 operators supply client SDKs through which 3rd party software
can forward user data to cloud-based storage, manage cloudbased computation, and access other cloud services (ex.
Apache Libcloud)
 Merchant Payment SDKs
 Merchant software uses libraries to send customers’ payment
details and/or receive notifications when customer makes
payment

See Figure 4 on next page
 Web-services middleware
 Middleware most often uses SSL but allocates SSL connection
responsibility to Data Transport Library ex. Apache
HttpClient or Weberknecht
 Mobile Advertising
 Connection from application provider’s site to AdMob server
contains provider’s credentials and must be protected by SSL.
MISUNDERSTANDING THE SSL API
 Amazon Flexible Payments Service (PHP)
 PHP version of the FPS SDK uses a wrapper around the libcurl library) to
establish an SSL connection to the payment gateway. Vulnerable to MiM
 PayPal Payments Standard and PayPal Invoicing (PHP)
 Any PHP code using these PayPal-provided SDKs to make an SSL connection to
PayPal’s payment processing gateway is insecure against a man-in-the-middle
attack
 PayPal IPN in ZenCart
 Huge misunderstanding of cURL’s parameters. Disables certificate validation
entirely
 Lynx - text-based (often used by other software)
 Hostname verification correct, but chain-of-trust verification defective
 Apache HttpClient
 Apache HttpClient 3 accepts any certificate with a valid chain of trust,
regardless of the name. Bugs in updated version 4 also.
 Trillian- popular IM client, relies on OpenSSL to make SSL connection
 Accepts any SSL certificate and is insecure against a man-in-the-middle attack.
 Rackspace- app for iOS, open-source application for managing cloud services
 Insecure against MiM
 TextSecure- is an Android application for encrypting SMS (text) and
MMS(text, video, pictures, etc.) messages.
 SSL certificate validation vulnerabilities
Using Insecure Middleware
 Web Service software relies on middleware libraries to
facilitate network connections.
 Apache Axis, Axis 2, Codehaus Xfire use:
 SSLSocketFactory for SSL connection
 SSL vulnerabilities caused by bugs in Web-services
middleware found in Amazon libraries.
 Pusher
 WebSocket-based API that offers real-time messaging
functionality to mobile and Web applications.
 Pusher’s Android libraries use Weberknecht

Vulnerable to MiM
 Overall, SSL functionality inside these libraries is
unclear to the app developers
Insecure SSL Libraries
 PHP fsockopen does not validate SSL certificates, often used by applications that
should be secure against a man-in-the-middle attack.
 Ex. PayPal’s IPN (instant payment notification) utility contains this code:
 Included in code in PayPal payment modules for ZenCart, PrestaShop shopping
carts
 PrestaShop uses fsockopen in its CanadaPost payment module also
 Other vulnerable software includes Open Source classifieds
 Python’s URL libraries do not validate certificates but developers still use them
for SSL connections.
 Tweepy


a library for accessing Twitter API utilizes httplib
Mozilla’s Zamboni project

accepts contributions for extension developers and uses urllib2 to connect to PayPal
Breaking or Disabling Certificate
Validation
 Sometimes developer’s answer to problems with
SSL Libraries is to disable proper certificate
validation
 Bad security practices used where protection
against MiM attack is essential, and SSL
certificate validation is necessary
 “Tutorial: Disabling Certificate Validation in an
HTTPS Connection. . . Reply: Thank you very
much. You solved my biggest problem in the
project.”
 “I have always turned off
CURLOPT_SSL_VERIFYPEER in curl.”
 “I am using axis on java to consume a webservice.
The web service is in https, and I want to avoid the
check for certificate.”
Breaking or Disabling Certificate
Validation (Others)
 Amazon Elastic Load Balancing API Tools
 X509TrustManager

Disable hostname verification
 Shopping carts
 osCommerce, ZenCart, Ubercart, and
PrestaShop are open- source shopping
carts (PHP)
 Use cURL for SSL connections to payment
Gateways, if cURL not available, fall back on
insecure Fsockopen
 AdMob: provides sample code to mobile site owners
that they can use on their servers to
associate instances of their mobile apps
with their developer accounts
 Vulnerable to MiM attack
 Android apps
 Groupon Redemptions, Breezy, ACRA vulnerable to MiM
 AIM
 accept certificates signed by untrusted authorities.
 No hostname verification
 FilesAnywhere- is an application for managing cloud storage.
 When presented with third-party certificate, accepts it and sends user’s data to a wrong/
potentially malicious server.
Chase Mobile Banking
 SSL connections established by Android Mobile
App. vulnerable to Man-in-the-Middle Attacks
 Allows a network attacker to capture username and
password and rest of session customer using the app
* Unreachable code. temporary plug during
development, in final version of app., returns
without checking server’s certificate
Apache LibCloud
 Python library extension providing support for 26 different cloud service
providers
 Libcloud depends on the Python library (uses OpenSSL) to verify the chain of
trust in SSL certificates
 Code uses an in- correct regular expression for hostname verification
 For example: it accepts oogle.com as a match for google.com, exposing all
Libcloud clients to a man-in-the-middle attack:
Recommendations
 It is inevitable Application developers will grapple with
SSL, and standard SSL libraries
 Common for developers of high-security software to use
standard SSL libraries incorrectly.
 Do’s and Dont’s:
 For Application developers:
 DO use better testing against different types of certificates
(black-box)
 DON’T disable certificate validation for testing with self-signed
and/or untrusted certificates.
 DON’T depend on the library’s defaults to set up secure SSL
connection
 For SSL Library Developers:
 DO improve documentation in SSL libraries APIs.
 DON’T make applications responsible for SSL connections
 DO design better error reporting interface.
Conclusion:
 Using SSL in non-browser software is a tough task
 Paper shows applications that depend on standard SSL
libraries such as JSSE, OpenSSL, GnuTLS, etc. often
accomplish SSL Certificate Validation incorrectly or not at
all.
 Future research directions include



(1) develop better black-box testing and code analysis tools to
identify errors in logic when making SSL connection
(2) develop better verification techniques and programming
language support for making sure applications correctly use SSL
Libraries in order to better understand important options and
parameters
(3) develop better APIs for SSL and other secure networking
protocols.