Originally designed for browsers, the SSL / TLS protocol later became the de facto standard for all secure Internet communications. It is now used to remotely administer a virtual infrastructure deployed in the cloud to transfer customer’s payment details from e-commerce servers to payment processors such as PayPal and Amazon to send local data to the cloud storage, store messages in instant messengers, and authenticate servers in mobile applications iOS and Android.

The list of situations where the exchange of highly sensitive information requires maximum security is quite impressive. In this article we will look at how the security of these communications is ensured in practice.

SSL / TLS protocol: we wanted it better ...

In theory, the SSL / TLS-protected connection should ensure the confidentiality, authenticity and integrity of client and server software communications - even in the presence of an active advanced attacker from the network: when the network is completely captured by the enemy, the DNS is poisoned, and access points and routers, switches and WiFi is controlled by the attacker; an attacker who among other things controls the SSL / TLS backend. In addition, when client software tries to connect to a legitimate server, an attacker can replace the network address of the server (for example, through DNS poisoning), and instead of the legitimate server, redirect the client to its malicious server.

The security of communications in such harsh conditions, as is well known, depends entirely on the adequacy of the verification of the cryptographic certificate provided by the server during connection establishment. Including the adequacy of the implementation of a cipher suite (ciphersuite) that the client and server use during data exchange. In order for the SSL / TLS connection to be completely secure, the client software, among other things, must carefully ensure that:

• certificate issued by the current certification body;
• its validity period has not expired (or the certificate has not been revoked);
• in the list of names listed in the certificate there is the domain to which the connection is made.

... but it turned out as always: examples of failing SSL / TLS certificate verification

However, in many applications and libraries for which the security of communications is very critical, the procedure for verifying an SSL / TLS certificate, and even EV-SSL, a certificate with extended verification [4], is completely failing. In all popular operating systems: Linux, Windows, Android and iOS. Among the vulnerable software, libraries and middleware-services are the following [1]:

• Amazon Java EC2 Library and all cloud front-end clients built on it.
• Amazon's and PayPal's shopping SDK, responsible for delivering payment details from sites (which have an online commerce infrastructure) to payment gateways.
• Integrated baskets, such as osCommerce, ZenCart, Ubercart and PrestaShop, which do not check certificates at all.
• AdMob-code used by mobile software for displaying contextual advertising.
• Interface frontend components ElephantDrive and FilesAnywhere responsible for interacting with the cloud storage.
• Android's Pusher library and all software that uses the Pusher API for managing instant messaging (for example, GitHub's Gaug.es).
• Apache HttpClient (version 3.x); Apache Libcloud; and all client connections to Apache ActiveMQ servers, etc.
• SOAP middleware Java services, including Apache Axis, Axis 2, Codehaus XFire; as well as all the software that is built on the basis of these middleware-services.
• API Tools Elastic Load Balancing.
• Weberknecht implementation of WebSockets.
• As well as all mobile software built on the basis of the above libraries and middleware-services (to understand what middleware-services are, see Fig. 1); including the iOS client hosting provider Rackspace.

Figure 1. What are middleware-services

In addition, in [2] even more hundreds of vulnerable mobile applications are listed (see Fig. 2). Including: Android's Google Cloud Messaging, Angie's List of Business Center Passwords, AT & T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (remote access), Cisco Technical Support, Cisco Webex, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer , Google Earth, Huntington Mobile (Bank), Intuit Tax Online Accountant, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN client), SouthWest Airlines, Uber, US Bank - Access Online, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail.

Figure 2. A small sample from the list of vulnerable mobile applications

Logical SSL / TLS Protocol Vulnerabilities

SSL / TLS connections of all this and many other software are vulnerable to a wide range of MiTM attacks. At the same time, MiTM-attack can be carried out, often, even without forging certificates and without stealing private keys with which the servers sign their certificates. A MiTM attack can be performed by simply exploiting the logical vulnerabilities that are present in the SSL / TLS certificate verification procedure on the client software side. As a result, the MiTM attacker may, for example, collect authorization tokens, credit card numbers, names, addresses, etc. - any merchant who uses vulnerable payment processing web applications.

Mobile software providers who take the AdMob sample code to link their applications to an AdMob account are also vulnerable - they allow an attacker to capture account data and access all of his Google services. For example, due to incorrect verification of certificates in instant messengers such as Trillian and AIM, a MiTM attacker could steal login credentials to all Google services (including Gmail), Yahoo !; and also to Windows Live services (including SkyDrive). Among other vulnerabilities that modern non-browser web-software suffers are: the use of incorrect regular expressions when comparing the host name; ignoring the results of certificate validation; accidental or intentional disabling of the scan. [one]

Other common SSL / TLS implementation vulnerabilities

And of course, one should not forget that even if there are no logical errors in the implementation of the SSL / TLS protocol (if of course someone still believes in it), then protection can be circumvented by stealing the private key [12], by using 0day- exploits for such things as keyboards, browsers, operating systems, utilities and firmware [3]; by compromising BGP routing [10]; or attack SSL / TLS through hardware (see Fig. 3) [8] and / or software [9] bypass channels.

Figure 3. SSL attack on hardware bypass channels

In addition, attackers can perform virtually invisible MiTM-attacks, abusing the caching mechanism of SSL / TLS-sessions, implemented in the class SSLSessionCache. This mechanism verifies the validity of certificates only during the initial connection; nor is it able to properly cancel a communication session after deleting certificates from the device. In addition, after restarting the Android device (via the “Restart” or “Power Off” options), you can continue to see encrypted traffic from some applications that did not start after the restart, but worked before the restart. So for example with Google Maps going on. In [2], it is described how, thanks to these caching flaws, an attacker can completely transparently allow the user to install and remove “invisible certificates”, and then establish a network connection with any application.

Figure 4. Retrospective Vulnerable Encryption

Other common SSL / TLS protocol implementation vulnerabilities include vulnerable encryption (see Figure 4) [5], GCM reuse (Galois / Counter Mode; counter with Galois authentication) [6], CNG trickery (CryptoAPI-NG ) in Schannel (see Fig. 5) [7], incorrect verification of the trust chain [2], incorrect verification of the host name [11].

Figure 5. CNG trick: pulling secrets out of Schannel

An incorrect trust chain check is a situation where a web application accepts absolutely any certificate that indicates the correct host name without checking which certificate authority it was signed with. This allows you to intercept and decrypt passwords and / or credit card numbers. And in some cases, even make an injection of malicious code. This vulnerability penetrates into Android software, for example, when a customized X509TrustManger interface is created that ignores CertificateException exceptions. Or when a software developer inserts a call to the SslErrorHandler.proceed () method in the code of the WebViews component. [2]

Incorrect verification of the host name is a situation where the web application accepts a certificate without making sure that the host from which this certificate came is in the list of trusted hosts. This vulnerability penetrates to Android software, for example, when a HostnameVerifier interface is created, which returns TRUE under any conditions. Or when a software developer inserts a call to the SslErrorHandler.proceed () method in the WebViews component code. [2]

The root cause of the existence of vulnerabilities in the SSL / TLS-protocol

The root cause of the overwhelming majority of the listed vulnerabilities is the terrible API design of the SSL / TLS libraries (including JSSE, OpenSSL, and GnuTLS). As well as the equally awful design of data transfer libraries (such as cURL, Apache HttpClient and urllib), each of which is a high-level wrapper for SSL / TLS libraries. Not to mention middleware services (such as Apache Axis, Axis 2, or Codehaus XFire), which are even more high-level wrappers, and which increase the snowball of a terrible design even more. Instead of communicating with an application developer (often far from system programming) in a language he understands (in terms of confidentiality and authentication), abstracting from the low-level details of the SSL / TLS protocol implementation, these APIs dump a bunch of low-level SSL / TLS parameters on the poor guy , incomprehensible to him. They require high-level software to correctly set low-level options; implemented the functions of checking the host name and took care of interpreting the values ​​returned by low-level operations.

As a result, application developers use the SSL / TLS API incorrectly: they misinterpret the variety of their parameters, options, side effects, and return values. For example [1]:

• Amazon's PHP Library Flexible Payments Service is trying to turn on host name verification by setting the CURLOPT_SSL_VERIFYHOST parameter to TRUE (in the cURL library). However, the correct default value for this parameter is 2; if, however, you assign it a value of TRUE, then this parameter, imperceptibly for the developer, is assigned the value 1, and so certificate verification is disabled.
• PHP-library PayPal Payments Standard - acquired the same error; and at that moment, when the previous, vulnerable, implementation was updated (i.e., one error was removed, another was added).
• Another example is Lynx, a text-oriented browser. It checks self-signed certificates, but only if the GnuTLS certificate verification function returns a negative value. However, this very function for some errors returns 0; including in cases where certificates are signed by an untrusted authority. Because of this, the trust chain in Lynx is broken.

In addition, application developers often misunderstand what kind of security guarantees a particular SSL / TLS library provides. Therefore, in the wild, you can find clinical cases where applications that are fundamentally in need of secure communications (for example, interacting with a payment processor) use an SSL / TLS library that does not check SSL / TLS certificates at all. More prosaic, but even more deadly, is when a developer of any of the intermediate layers of software silently disables the SSL / TLS certificate verification procedure (he can do this, for example, to test the system, and after testing, forget to re-enable it). At the same time, high-level program code using this intermediate layer is sure that certificates are checked. So SSL / TLS errors are often hidden in the depth of one or several intermediate library layers at once — which makes it almost impossible to detect this problem.

For example, in JSSE (Java Secure Socket Extension), the advanced interface SSLSocketFactory API silently skips checking the host name if the "algorithm" field in the SSL client is set to NULL or to an empty string, but not to HTTPS. Although this is mentioned in the JSSE Reference Manual, many Java implementations of the SSL protocols use SSLSocketFactory without performing a host name check ...

A spoon of honey in a tar barrel

Thus, in fact, it turns out that in most modern non-browser web software, SSL / TLS certificate checking is either disabled completely or not implemented correctly. Figure 7 presents the classification of the current SSL / TLS protocol vulnerabilities. Some of these vulnerabilities, but not all, have been described and / or mentioned above. You can familiarize yourself with the mentioned but undescribed vulnerabilities by reading the materials listed in the bibliography.

Figure 6. Classification of SSL / TLS vulnerabilities relevant

Well, to add a spoonful of honey to the tar barrel, it is worth noting that [1] describes in detail / clearly / popularly / correctly how SSL should be implemented, with reference to the RFC. We did not find a better description that would be technically accurate and at the same time understandable. Also in [1], the most common SSL libraries are sorted, with classification by level of abstraction (low-level / high-level). All with diagrams and laconic algorithms in pseudocode. Details of the specific product vulnerabilities are described, with an incorrect code, and an indication of errors. So if suddenly someone once again has a desire to create such an implementation of the SSL / TLS framework, which will be an exception to the saying “they wanted it better, but it turned out as always,” then [1] is an ideal beginning.