Security researchers at Sucuri revisited a paper written in 2012 focused on the security of API calls. When used, these calls assumed the integrity of underlying libraries such as JSSE, OpenSSL and GnuTLS, or of data transport libraries such as cURL. However, researchers discovered the TLS certificate used to validate the entire transaction can be spoofed.
Specifically, the original research paper noted that the underlying sources of this vulnerability include “SSL libraries such as OpenSSL, GnuTLS, JSSE, CryptoAPI, etc., as well as higher-level data transport libraries such as cURL, Apache HttpClient, andurllib, that act as wrappers around SSL libraries.” The authors also cited the concern that software may leverage “Web-services middleware such as Apache Axis, Axis 2 or Codehaus XFire.”
Sucuri found that use of these libraries made it hard or impossible to check revocation status of a TLS certificate, as well as other verification problems. This would leave the client open to a man-in-the-middle (MitM) attack.
The TLS Certificate Problem
Here’s how such an attack would work: The server on the other end of the TLS conversation — the API server — authenticates itself by sending an X.509 certificate to the client. The client must verify the certificate’s signature against the list of known root certificates.
If unchecked, the validity of the X.509 certificate is in question, and the client can be spoofed by the invalid certificate of the API server. The user wouldn’t even know the spoofing was taking place since the browser is untouched in all of this.
Sucuri researchers decided to use these new languages and see what would still break by testing TLS. According to the blog, “all programming language implementations fail to check if a certificate is revoked,” which is a recognized OWASP vulnerability. So things are broken by default unless corrective action is taken.
There are some mitigation routes available. Upgrading to the latest version of languages will remove many certificate verification problems, although not the revocation aspect.
With Python, for example, one must pass the context parameter to verify the certificate. Similarly, the http.client.HTTPSConnection constructor must also pass the context parameter.
TLS implementation in PHP 5.5 and below is broken with the use of stream functions, Sucuri reported. Using cURL functions instead of stream functions and upgrading to PHP 5.6 whenever possible will help.
There are also Web services that can test any APIs a server is using. This kind of service can identify problem situations that may arise from the use of shared or unmaintained programs.
The end result is that TLS can still be broken, even four years after significant faults were pointed out. The remedies are there, but their use must be vigilant for them to be effective.