The death knell for SSL is getting louder.

Researchers at the University of Texas at Austin and Stanford University have discovered that poorly designed APIs used in SSL implementations are to blame for vulnerabilities in many critical non-browser software packages.

Serious security vulnerabilities were found in programs such as Amazon’s EC2 Java library, Amazon’s and PayPal’s merchant SDKs, Trillian and AIM instant messaging software, popular integrated shopping cart software packages, Chase mobile banking software, and several Android applications and libraries. SSL connections from these programs and many others are vulnerable to a man in the middle attack.

“This is exactly the attack that SSL is intended to protect against,” according to the research paper “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.“ 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.”

SSL encrypts network communications between clients and servers. The research, done by Martin Georgiev, Suman Jana and Vitaly Shmatikov of the University of Texas at Austin and Subodh Iyengar, Dan Boneh and Rishita Anubhai of Stanford University, focuses on SSL connection authentication in non-browser software. The team looked at a number of applications and libraries supported on Linux, Windows, Android and Mac iOS platforms, and how they validate SSL certificates. All of the applications and libraries tested failed to reject self-signed and third-party digital certificates and instead established SSL connections initiated by a man in the middle who siphoned the transaction information.

“SSL certificate validation is completely broken in many critical software applications and libraries,” the report concluded.

Non-browser software often requires a secure Internet connection, and SSL is deployed as the preferred encryption protocol. Some of the critical applications tested by the researchers included instances where SSL was used to send local data to cloud-based storage, transmit payment data to processors such as PayPal and Amazon, establish connections between IM clients and the respective service, and authenticate servers to Android and iOS mobile applications, the research paper said.

“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,” the paper said. “As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstanding their manifold parameters, options, side effects, and return values.”

Developers, meanwhile, may incorrectly use legitimate SSL libraries that don’t validate certificates, or inadvertently turn off certificate validation.

In addition to certificate validation vulnerabilities in a number of cloud-based storage management programs, Java-based Web services middleware, merchant software development kits and IM authentication instances that could lead to various types of data leakage (lost credentials, payment information and more), the researchers were most disturbed with issues discovered on the Chase mobile banking application for Android devices. The researchers discovered that the mobile app overrides default x509 code which causes the app to fail to check the requesting server’s certificate.

“Perhaps the most devastating (because of the ease of exploitation) bug is the broken certificate validation in the Chase mobile banking app on Android,” the report said. “Even a primitive network attacker—for example, someone in control of a malicious Wi-Fi access point—can exploit this vulnerability to harvest the login credentials of Chase mobile banking customers.”

The researchers point out that the SSL libraries (JSSE, OpenSSL, GnuTLS and others) are often correct, but developers misunderstand the security options, parameters and return values. By incorrectly setting a return value in Amazon’s Flexible Payments Service PHP library, for example, a developer can accidently turn off certificate validation functionality. PayPal Payments Standard PHP library contains the same bug, the researchers said.

The research team said a number of factors contribute to the poor security of SSL implementations: a lack of testing for vulnerabilities during development; unsecure SSL libraries by default; misuse or misinterpretation of security options in secure libraries by developers; SSL vulnerabilities are often not present on the application layer, but in middleware—out of a developers’ purview; and some cases where developers deliberately turn off validation.

“A principled solution to the problem must involve a complete redesign of the SSL libraries’ API,” the report said. “Instead of asking application developers to manage incomprehensible options such as CURLOPT_SSL_VERIFYPEER or SSL_get_verify_result, they should present high-level abstractions that explicitly express security properties of network connections in terms that are close to application semantics.”

Categories: Web Security

Comments (13)

  1. Anonymous
    1

    This is pure hysteria. We are seriously going to ditch SSL as an end-to-end encryption protocol simply because the programming APIs are bad? 

    Let’s all stop using SSH because the command-line options are clunky. Sheesh.

     

  2. Anonymous
    2

    This isn’t a problem with the SSL API — its a problem with the (lack of a) standard mechanism/API for CA/certificate management.  Since there is no standard, all applications need to roll their own (which is hard) and most get it wrong.

     

    You can claim that perhaps this should be part of the SSL API, but claiming that the SSL API is misdesigned because it just provides hooks for connecting to a certificate manager rather than actually providing a certificate manager (when noone can agree on exactly what said manager should do or how it should work) is a stretch.

     

     

  3. Anonymous
    3

    how about X509 PKI is flawed and managing CA + CRL lists is a PITA.  no that couldn’t certainly be part of the cause.

  4. Anonymous
    4

    The opening sentence ‘The death knell for SSL is getting louder’ isn’t justified by the rest of the article, apart from that it seems pretty decent.

  5. Matt Haak
    5

    I would think a major contributing factor is that the vast majority of developers use self-signed certificates in their development and test environments and so must initially design their software to accept self-signed certs. Also, corporate security policies probably prevents developers from installing production certs on sub-prod servers, even if they use DNS redirection for “production-like” testing.

    Once the app goes through several test cycles and works “perfectly” against a self-signed cert, many probably don’t bother to go back to the code and update it one last time to reject self-signed certs. This last change would be untestable, after all, except against the real production server.

    So I would think big defficiency is that it is so difficult and sometimes costly for developers to set up good sub-production environments to test against that truly mimic the eventual production environment.

  6. Chase Venters
    6

    CURLOPT_SSL_VERIFYPEER or SSL_get_verify_result… this is supposed to be complicated? Come on. I’m not a crypto expert, and I’m not the world’s greatest software developer, but I have used SSL libraries before and these concepts are really simple to understand. 

    None of this is SSL’s fault, or even the fault of SSL client libraries.

    That SSL certificates are validated should be a critical part of a test suite, or at least a one-off test procedure after writing SSL code. Not doing so is laziness / incompetence on the part of the developer.

  7. jacob
    7

    I think using self signed certificate is the best solution for above issue. anyone can generate self signed certificate for their website from selfsignedcertificate.com

  8. Anonymous
    8

    I like how Android is specifically mentioned, and Apple gets rolled into “and many others”

  9. Anonymous
    9

    Is there a way to build a solution / checker to verify if and disable the self-signed certificate acceptance?

  10. Anonymous
    10

    People like Amazon & PaylPal are great of advertising hype, but obviously don’t care about security, OR they don’t have the knowlege to do it correctly.  If they don’t have the knowlege, then perhaps they need a new manager.

  11. Anonymous
    11

    As several have hinted at or basically stated, the real problem here is certificate management. SSL is not broken, beyond its encryption vulnerabilities, and the available APIs generally work, confusing or not, barring the usual bugs. Current SSL end-user applications are written the way they are because there simply is no standard way to manage certificates. As an application vendor, you cannot install/uninstall certs everywhere you need to, and you cannot rely on users to do it for you, and you cannot do without SSL support. What to do? Implement SSL support but ignore certificates. This is a business decision, and it will continue to be made this way, unless a standard is adopted for certificate management that doesn’t require users to do anything other than click OK.

  12. Anonymous
    12

    I believe you overreact to this news. The bad API design is a real problem, not the underlying libraries which are correct. The problem is with the developpers using an API the wrong way.

    So, without ditching SSL, improving the API or writing an higher-level API could be a solution.

Comments are closed.