A stinging indictment of the state of SSL client applications was
as part of the Proceedings from the ACM Computer and Communications
Security (CCS) conference. The six authors of the paper (three each from
Stanford and The University of Texas) describe testing that certainly
should have been done as part of the application development
process, but clearly wasn't. The problem stems partly from the libraries that
provide SSL certificate verification, because developers are not using them properly. By and large the low-level library
cryptographic protocol implementations are fine, the authors found, but the
APIs are designed so
developers commonly misuse them.
[PDF] is entitled "The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software" and lives up to that
label. It is truly an eye-opening read. The researchers simulated
man-in-the-middle attacks using a combination of
self-signed and invalid SSL certificates along with a valid certificate for
the amusing AllYourSSLAreBelongTo.us domain to observe the effects
on various applications. The observations led to the overall conclusion: "SSL certificate validation is completely broken in many critical software applications and libraries".
The researchers used Windows and Ubuntu laptops, a Nexus One
smartphone, and an iPad 2 as clients for their testing. A second Ubuntu
system running custom Java and C proxies, as well as the Fiddler web debugging
proxy, served as the man in the middle. As they noted, the kind
of attack that can be launched from the proxies is precisely what SSL is
meant to thwart—their testing did
not go beyond what an active man in the middle could do:
This is exactly the attack that SSL is intended to protect against.
It does not involve compromised or malicious certificate authorities, nor forged certificates, nor compromised private keys of legitimate servers. The only class of vulnerabilities we exploit are logic
errors in client-side SSL certificate validation.
What they found was client applications that largely (or completely)
accepted various kinds of invalid certificates and blindly sent private
information (cookies, authentication information, credit card numbers) over
an unsecured link. In many cases, the proxies could make the actual SSL
connection to the remote server and funnel the data along—while
surreptitiously storing the data away for (ab)use at a later time.
The paper gives plenty of examples of where the applications go wrong.
Much of it can be blamed on bad library APIs, they said, in essentially
all of the low-level SSL libraries (OpenSSL, GnuTLS, JSSE,
The root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as
confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers. As a consequence, developers often use SSL APIs incorrectly, misinterpreting
and misunderstanding their manifold parameters, options, side effects, and return values.
While that is certainly a problem, the application authors do bear some of
the responsibility as well. It is not difficult to test an application
against a few types of bad certificates. Because of the complexity of the
APIs, developers should probably have been more wary that they might have
made a mistake. Given that there is some kind of security requirement for
the application (why use SSL otherwise?), it would seem prudent to verify
proper functioning. Using a well-tested, industry-standard library is
certainly an important piece of the puzzle, but there is more to
it than just that.
There is also the problem of higher-level libraries perched atop OpenSSL,
et al. The researchers found that libraries like Apache HttpClient, cURL,
and the PHP and Python SSL libraries all had flaws in certificate
validation. In fact, Python's urllib, urllib2, and
httplib documentation warns that no certificate checking is done
by the libraries,
doesn't stop "high security" applications from still using them. One of
the examples shows how this can all go awry:
Amazon's Flexible Payments
Service PHP library attempts to enable hostname verification by
setting cURL's CURLOPT_SSL_VERIFYHOST parameter to true. Unfortunately, the correct, default value of this parameter is 2; setting
it to true silently changes it to 1 and disables certificate validation. PayPal Payments Standard PHP library introduced the same bug
when updating a previous, broken implementation.
These kinds of errors would almost be comical, if they weren't so serious.
While it may sound difficult for attackers to position themselves "in the
middle", the prevalence of wireless networking these days makes it easier.
over an access point (or just running a hostile one as "Free Airport WiFi",
say) puts an attacker squarely in the middle. Users that are running the
vulnerable applications over a link to a bad access point are susceptible
to many kinds of attacks. Compromise of home routers is another possibility.
Obviously, malware running upstream in the wired internet is equally
dangerous (if harder to pull off).
The researchers conclude the article with recommendations for both application
and SSL library developers. For the most part, they are pretty
common-sense suggestions (do test your application, don't have multiple
inconsistent error reporting mechanisms, etc.) that could certainly apply
more widely than just SSL applications and libraries. Obviously, they
could not test each and every non-browser SSL-using client (or even all of
the SSL client libraries) out there, but the list of vulnerable
from the abstract is rather astonishing:
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 applications
employing this middleware.
Perhaps the most distressing piece of this research is the
appearance—at least—that developers are being pretty cavalier
about checking the security baked into their supposedly "high security"
applications. Beyond that, it is amazing that payment processors
who are dealing with credit cards (and, importantly, credit card fraud)
have seemingly not been very diligent about the code they distribute to
their customers. All in all, this research shows that even "secure"
applications and libraries often skimp on important verification
testing—a seriously sad state of affairs.
to post comments)