Originally developed for browsers, the SSL / TLS protocol later became the de facto standard for all secure Internet communications. Now it is used for remote administration of the virtual infrastructure deployed in the cloud, for transferring customer payment details from e-commerce servers to payment processors such as PayPal and Amazon, for sending local data to cloud storage, saving correspondence in instant messengers and server authentication 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 examine how the security of these communications is ensured in practice.

- SSL / TLS protocol: we wanted the best ...
- ... but it turned out as always: examples of a failed SSL / TLS certificate verification
- Logical vulnerabilities of the SSL / TLS protocol
- Other common vulnerabilities in the SSL / TLS protocol implementation
- The root cause of the vulnerabilities in SSL / TLS Protocol
- A spoonful of honey in a barrel of tar

SSL / TLS protocol: we wanted the best ...

In theory, a secure SSL / TLS protocol connection should ensure the confidentiality, reliability 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 taken by the enemy, DNS is poisoned, and access points and routers, switches and WiFi are controlled by an attacker; an attacker who, among other things, controls an SSL / TLS backend. In addition, when client software tries to connect to a legitimate server, an attacker can change the server’s network address (for example, through DNS poisoning), and instead of a legitimate server, redirect the client to its malicious server.

The security of communications in such harsh conditions, as you know, depends entirely on the adequacy of the verification of the cryptographic certificate provided by the server when establishing the connection. Including the adequacy of the implementation of a set of ciphers (ciphersuite), which the client and server use when exchanging data. In order for the SSL / TLS connection to be completely secure, client software, among other things, must carefully verify that:

• certificate issued by the current certification body;
• its validity period has not expired (or the certificate has not been revoked);
• the list of names listed in the certificate contains the domain to which you are connecting.

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

However, in many applications and libraries for which communication security is very critical, the procedure for verifying an SSL / TLS certificate — and even EV-SSL, an advanced verification certificate [4] - is completely unsuccessful. In all popular operating systems: Linux, Windows, Android and iOS. Among the vulnerable software, libraries, and middleware services, the following can be distinguished [1]:

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

Figure 1. What are middleware services

In addition, in [2] even more than a hundred vulnerable mobile applications are listed (see. Fig. 2). Including: Android's Google Cloud Messaging, Angie's List 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 selection from the list of vulnerable mobile applications

SSL / TLS Logical Vulnerabilities

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

Mobile software vendors, who take the AdMob sample code to connect their applications with the AdMob account, are also vulnerable - they allow an attacker to capture credentials and gain access to all of his Google services. For example, due to incorrect verification of certificates in messengers such as Trillian and AIM, a MiTM-attacker can steal login credentials for all Google services (including Gmail), Yahoo !; and also to Windows Live services (including SkyDrive). Other vulnerabilities that affect modern non-browser web software include: the use of incorrect regular expressions when comparing a host name; ignoring certificate validation results; accidental or intentional shutdown of verification. [1]

Other common SSL / TLS protocol implementation vulnerabilities

And of course, we must not forget that even if there are no logical errors in the implementation of the SSL / TLS protocol (unless of course someone else believes in this), protection can be circumvented by stealing a 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 over hardware (see Figure 3) [8] and / or software [9] bypass channels.

Figure 3. SSL attack on hardware bypass

In addition, attackers can carry out practically invisible MiTM attacks, abusing the SSL / TLS session caching mechanism implemented in the SSLSessionCache class. This mechanism checks the validity of certificates only at the initial connection; nor is it capable of properly canceling a communication session after deleting certificates from the device. In addition, after rebooting the Android device (through the “Restart” or “Power off” options), you can continue to see the encrypted traffic of some applications that did not start after the reboot, but worked before the reboot. So for example with Google Maps happens. In [2], it is described how, thanks to these caching shortcomings, an attacker can completely transparently set and remove “invisible certificates” for the user,

Figure 4. Retrospective of vulnerable encryption

Other common vulnerabilities in the SSL / TLS protocol implementation include vulnerable encryption (see Figure 4) [5], reuse of GCM (Galois / Counter Mode; counter with Galois authentication) [6], trick with CNG (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 from Schannel

An incorrect verification of the trust chain is a situation where the web application accepts absolutely any certificate that indicates the correct host name, without checking what certificate authority it was signed with. This allows you to intercept and decrypt passwords and / or credit card numbers. And in some cases even do an injection of malicious code. In Android software, this vulnerability penetrates, 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 into the code of a WebViews component. [2]

An incorrect host name verification is a situation when a web application accepts a certificate without making sure that the host from which this certificate came is in the list of trusted hosts. In Android software, this vulnerability penetrates, 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 into the code of a WebViews component. [2]

The root cause of vulnerabilities in SSL / TLS protocol

The root cause of the vast majority of these vulnerabilities is the terrible API design of SSL / TLS libraries (including JSSE, OpenSSL, and GnuTLS). As well as the equally terrible 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 an even higher-level wrapper, and which increase the “snowball” of terrible design even more. Instead of conducting a dialogue with an application developer (often far from system programming) in a language that he understands (in terms of confidentiality and authentication), it is abstracted 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 fellow, which are incomprehensible to him. They require high-level software to correctly expose low-level options; implements host name verification functions and takes care of the interpretation of the values ​​returned by low-level operations.

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

• Amazon's Flexible Payments Service PHP library attempts to enable host name validation by setting the CURLOPT_SSL_VERIFYHOST parameter to TRUE (in the cURL library). However, the correct default value for this parameter is 2; if you assign it a value of TRUE, then this parameter is invisibly for the developer assigned the value 1, and so on. certificate verification is disabled.
• PHP library PayPal Payments Standard - got the same error; Moreover, at the 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 verifies self-signed certificates - but only if the GnuTLS certificate verification function returns a negative value. However, this function returns 0 for some errors; including in cases where the certificates are signed by an untrusted body. 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 one can encounter clinical cases when in applications that fundamentally need secure communications (for example, interacting with a payment processor), an SSL / TLS library is used that does not check SSL / TLS certificates at all. More prosaic, but even more murderous cases are when the developer of any of the intermediate software layers silently disables the procedure for checking SSL / TLS certificates (he can do this, for example, to test the system, and after testing forget to re-enable it). At the same time, the high-level program code using this intermediate layer is sure that certificate verification is performed. T.O.

For example, in JSSE (Java Secure Socket Extension), the SSLSocketFactory API extended interface silently skips checking the host name if the "algorithm" field in the SSL client is set to NULL or to an empty string, and not to HTTPS. Although this fact is mentioned in the JSSE reference guide, many Java SSL protocol implementations use SSLSocketFactory without performing hostname validation ...

A spoon of honey in a barrel of tar

Thus, in fact, it turns out that in most modern non-browser web software, the verification of SSL / TLS certificates is either completely disabled or implemented incorrectly. Figure 7 shows the classification of 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 vulnerabilities relevant for SSL / TLS

Ну и чтобы добавить ложку мёда в бочку дёгтя, стоит отметить, что в [1] подробно/понятно/популярно/грамотно описано, как SSL реализовываться должен, со ссылкой на RFC. Лучшего описания, которое бы технически точным и одновременно понятным было, мы не встречали. Также в [1] разбираются самые распространённые SSL-библиотеки, с классификацией по уровню абстрагирования (низкоуровневые/высокоуровневые). Всё с диаграммами и лаконичными алгоритмами в псевдокоде. Подробно уязвимости конкретных продуктов описаны, с приведением программного кода некорректного, и указанием ошибок. Так что если вдруг у кого-то в очередной раз возникнет желание создать такую реализацию SSL/TLS-фреймворка, которая станет исключением из поговорки «хотели как лучше, а получилось как всегда», то [1] – идеальное для этого начало.