Manually Testing SSL/TLS Weaknesses

on May 18th, 2016 by Hades | No Comments »

The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols aim to provide client and server systems with a means of establishing an encrypted communication channel. Though best known for putting the “S” in HTTPS,  their use is not limited to web-based systems; they are also commonly used as a wrapper for other unencrypted services such as FTP.

While SSL has historically been the dominant protocol for securing the Internet, a rash of attacks in recent years has prompted a migration to its successor, TLS. This alone is not enough to guarantee a secure connection, however. TLS has also been found to have weaknesses and careful configuration is needed to avoid exposing communications to compromise from a network-based attacker. SSL/TLS flaws are widespread; SSL Pulse estimates that over three-quarters of the SSL/TLS deployments currently in use by the top one million websites are inadequately configured.

This post presents a review of the main SSL/TLS (mis)configurations and simple ways to test your system’s susceptibility. The following configurations and attacks are considered:

  • Cipher Suites
  • SSL Certificates
  • Renegotiation
  • Compression
  • Implementation Issues

Cipher Suites

One of the main functions of the SSL/TLS protocols is to allow the client and server to negotiate a mutually acceptable “cipher suite” to use for the connection. The cipher suite chosen specifies a set of algorithms which the client and server will use to perform key exchange, encryption, and message authentication.

A cipher suite is typically described in a format similar to this:

TLS_RSA_WITH_AES_128_CBC_SHA

where RSA is the key exchange algorithm, AES_128_CBC is the encryption cipher (AES using a 128-bit key operating in Cipher-Block Chaining mode), and SHA is the Message Authentication Code (MAC) algorithm.

The cipher suites a server is configured to support should be dictated by its security requirements. The following guidelines are generally recommended as a baseline:

  • The key exchange algorithm should be restricted to those which provide “perfect forward secrecy”, such as Ephemeral Diffie-Hellman (DHE) or Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).
  • The cipher should not suffer from known cryptanalytic flaws. This rules out RC4 which has been known to have flaws for many years and in the past few years has been shown to be significantly weaker than originally thought.
  • The cipher should use at least a 128 bit key (which rules out DES and Triple-DES).
  • Cipher-Block Chaining (CBC) mode is prone to padding oracle attacks and should ideally be avoided altogether, but specifically it should not be used in conjunction with SSLv3 or TLSv1.0 as this can lead to vulnerability to the BEAST attack. An alternative is Galois Counter Mode (GCM) which is not affected by these problems and offers authenticated encryption.
  • The message authentication algorithm should ideally be SHA256. MD5 is known to be cryptographically weak and should be avoided, and SHA1 (just denoted SHA in the cipher suite specifications) has its own weaknesses which place attacks within the realm of possibility.
  • For all three algorithms, the NULL / anon setting should be avoided as these provide no security at all. “Export” algorithms should also be disabled as their short key lengths make them susceptible to brute-force attacks and other attacks such as the FREAK attack.

Nmap’s “ssl-enum-ciphers” script can be used to produce a list of the supported cipher suites in the following way:

Example

While nmap will give a strength rating for each supported cipher suite, the fast pace of change SSL/TLS security means that these ratings should be manually reviewed.

SSL Certificates

SSL/TLS supports the use of authentication via X.509 certificates, which are often termed “SSL certificates” when used in this context. Server certificates enable the client to verify that it is connecting to the correct host. Though not usually used for HTTPS, SSL/TLS can also support mutual authentication in which the client proves its own identity through the provision of its own certificate.

Some of the main security properties which should be considered when setting up a certificate, include:

  • “Not Before” – This gives the start date of the certificate and should be a date in the past.
  • “Not After” – This gives the expiry date of the certificate after which is should not be trusted. It is therefore important to ensure that this is a date in the future. As the expiry date approaches, a new certificate should be issued to replace it.
  • “Signature Algorithm” – This is the algorithm used to ensure the certificate’s integrity. MD5 has been shown to be inadequate for this, with collision attacks allowing fake, but valid, certificates to be generated. SHA1 is in the process of being phased out due to known weaknesses, with SHA2 hash functions being the preferred alternative.
  • “Public-Key” – The public key should be long enough to ensure that attacks are computationally infeasible. In the case of RSA, 2048 bit public keys are now considered a sensible minimum to protect against factoring attacks.
  • “Issuer” – This is the entity which has issued the certificate and should be a trusted party recognised by both the client and server. The issuer is typically a third-party certificate authority (such as DigiCert in the example above), though larger organisations often operate their own certificate authority to sign certificates for internal use. While it is possible to generate so-called “self-signed” certificates, these prevent the client from authenticating the server and open up the possibility of man-in-the-middle attacks in which an attacker dupes the client and/or server into communicating with the attacker rather than each other.
  • “Subject” and “Subject Alternative Name” – These should contain the DNS information necessary to tie the IP of the server running the SSL/TLS service. If these values are not valid domain names (or wildcard domains), then the client will be unable to determine whether or not the certificate is associated with the server in question and cannot therefore use it to authenticate the server.

To view the details of a server’s certificate, the following command can be used:

This will produce output similar to the following (here PayPal’s certificate is shown):

Renegotiation

The SSL/TLS protocols allow the client and server to renegotiate new encryption keys during a session. A vulnerability was discovered in 2009 whereby an attacker could exploit a flaw in the renegotiation process and inject content into the start of the session, compromising the integrity of the session.

This is only possible if two conditions are met, namely that the server does not support secure renegotiation but does honour client-initiated renegotiations. These conditions can be checked for as described below:

Secure Renegotiation

The following demonstrates how to verify if a system supports secure renegotiation.

A system that does not support secure renegotiation will return the following when a connection is established.

Client Initiated Renegotiation

The following demonstrates how to check if client initiated renegotiation is supported.

Once the connection is established, the server will wait for us to type the next command. We can write the following two lines in order to initiate a renegotiation by specifying R in the second line, followed by enter or return.

 

A system that does not support client initiated renegotiation will return an error and end the connection, or the connection will time out.

A system that supports client initiated renegotiation will keep the connection active, and respond to further commands.

Compression

The use of compression has been linked to two side channel attacks: CRIME and BREACH.

CRIME

The Compression Ratio Info-leak Made Easy (CRIME) attack is a side-channel attack against TLS compression. To carry out the attack, the attacker needs to exert partial control over the content of requests made by the client (e.g. by using a Cross-Site Scripting vulnerability to force the user’s browser to issue requests). The attacker can then observe the compressed size of these requests on the network and from that infer the contents of the remainder of the request (e.g. session cookies) based on the level of compression achieved.

To test whether a server supports TLS compression, and is vulnerable to CRIME, the following method can be used:

On the servers supporting compression, a response similar to the one below will be received, containing details about the compression. The lines “Compression: zlib compression” and “Compression: 1 (zlib compression)” indicate that the remote server is vulnerable to the CRIME attack.

For servers that have TLS compression disabled, the response will be similar to the following. The “Compression: NONE” shows that this server rejects usage of TLS-level compression.

BREACH

The BREACH attack is analogous to the CRIME attack, but this time exploits the use of HTTP compression to again infer the contents of attacker-influenced requests.

To test whether a server supports deflate or compression, the following steps can be performed:

openssl s_client -connect example.com:443

If the response contains encoded data, similar to the following response, it indicates that HTTP compression is supported; therefore the remote host is vulnerable.

 

A system which does not support deflate or compression will ignore the compress header request and respond with uncompressed data, indicating that it is not vulnerable.

Implementation Issues

 

Submitting the following will allow us to see if HTTP compression is supported by the server.

GET / HTTP/1.1 Host: example.com Accept-Encoding: compress, gzip

 

If the response contains encoded data, similar to the following response, it indicates that HTTP compression is supported; therefore the remote host is vulnerable.

SSL/TLS is only as secure as its implementation and a number of flaws have surfaced in TLS software in recent years. This has included TLS (not SSLv3) implementations which are vulnerable to POODLE, and timing attacks such as the Lucky-13 attack. We highlight two notable implementation vulnerabilities here, but more important than their details is the message that keeping SSL/TLS software patched and up-to-date is an essential piece of the security puzzle.

Heartbleed

The Heartbleed bug is a result of a weakness in OpenSSL. It can be exploited to retrieve memory contents of a server/host running a vulnerable version of OpenSSL.

The following versions of OpenSSL are vulnerable:

• OpenSSL 1.0.1 through 1.0.1f (inclusive)

The following versions of OpenSSL are not vulnerable:

• OpenSSL 1.0.1g

• OpenSSL 1.0.0 branch

• OpenSSL 0.9.8 branch

There are many scripts publicly available that can be used to test whether a system is affected by this vulnerability.

Servers accessible from the internet can be tested using the Heartbleed test websites like https://filippo.io/Heartbleed/, which is run by Filippo Valsorda.

Alternatively, Nmap (v6.46 and above) can be used to test this bug by using the ‘ssl-heartbleed.nse’ script.

 

The output will be similar to the following:

 

Change Cipher Spec Injection

A weakness exists in some versions of OpenSSL which can be exploited by intermediary third parties in order to retrieve sensitive information from encrypted communication.

Affected Versions:

• OpenSSL 1.0.1 through 1.0.1g

• OpenSSL 1.0.0 through 1.0.0l

• all versions before OpenSSL 0.9.8y

Testing requires using publicly available tools, such as the the ‘ssl-ccs-injection’ nmap script by Claudiu Perta, which can be used to test for this vulnerability. This script can be downloaded from https://nmap.org/nsedoc/scripts/ssl-ccs-injection.html.

Sample Output

Conclusion

This post has presented some of the common attacks and misconfigurations which can undermine the security of SSL/TLS connections. Addressing these should be considered a minimum for anyone configuring SSL/TLS. It should be noted that  other attacks exist which are not covered here, which may require additional work to adequately defend against. Furthermore, a secure SSL/TLS configuration is a moving target and additional or better attacks may be discovered in the future.