Manually Testing SSL/TLS Weaknesses

Manually Testing SSL/TLS Weaknesses

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.

By Jay Kalsi and Daniel Mossop

01 Jun 2015

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:

  • SSLv2 Support
  • SSLv3 Support
  • Cipher Suites
  • SSL Certificates
  • Renegotiation
  • Compression
  • Implementation Issues

SSLv2 Support

SSLv2 was released twenty years ago and soon after discovered to have significant weaknesses which could allow an attacker to decrypt and modify communications. It was superseded a year later by SSLv3 which addressed these issues, but despite its age and short lifespan SSLv2 support is still surprisingly common.

To check whether SSLv2 is enabled on the remote host, the following command can be used: 

openssl s_client –ssl2 -connect

If SSLv2 is supported, the handshake will complete and server certificate information will be returned, as shown in the following response:

openssl s_client -ssl2 -connect

depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver
verify return:1
Server certificate
No client certificate CA names sent
Ciphers common between both SSL endpoints:
RC4-MD5         EXP-RC4-MD5     RC2-CBC-MD5    
SSL handshake has read 807 bytes and written 233 bytes
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1000 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
    Protocol  : SSLv2
    Cipher    : DES-CBC3-MD5
    Session-ID: 3BD641677102DBE9BDADF9B990D2D716
    Master-Key: D2AAB3751263EB53BAD83453D26A09DA1F700059FD16B510
    Key-Arg   : DB92A6A80BF4CA4A
    Start Time: 1390178607
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)

If the server does not support SSLv2 the response will be a handshake failure error similar to the following:

458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

SSLv3 Support

Despite some issues, SSLv3 was considered secure (at least when configured correctly) until last year when the Google Security Team introduced their Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. POODLE demonstrated that, under certain conditions, it is possible to conduct a "padding oracle" attack against ciphers using cipher-block chaining (CBC) mode. This may allow decryption of communications and disclosure of session cookies. As the only non-CBC cipher supported in SSLv3, RC4, is also known to be cryptographically weak, the conclusion is that SSLv3 should not be used for communications. The Google Security Team further showed that an attacker can force the client and server to downgrade to SSLv3 even if they would normally use TLS, meaning that it is important to ensure that SSLv3 is disabled completely.

To test whether a system supports SSLv3, the following OpenSSL command can be used:

openssl s_client -ssl3 -connect

depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate chain

--- Certificate details removed for brevity ---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : SSLv3
    Cipher    : RC4-SHA
    Session-ID: 6E461AEAD8C1516F9D8950A9B5E735F9882BFC6EA0838D81CFD41C01A3799A41
    Master-Key: 7E7680640BB7E2C83CBE87342727E0D09AC10EEEB095A8C0A2501EAE80FA1C20D3F3FE4346B1234057D6D506420273FA
    Key-Arg   : None
    Start Time: 1421296281
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

A handshake failure error would indicate that SSLv3 is not supported and the server is not vulnerable to POODLE.

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:


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:

nmap --script ssl-enum-ciphers -p 443


nmap --script ssl-enum-ciphers -p 443

Nmap scan report for
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3
|     Ciphers (6)
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength
|       TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 - broken
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
|     Compressors (1)
|       uncompressed
|   TLSv1.0
|     Ciphers (6)
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
|     Compressors (1)
|       uncompressed

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:

openssl s_client -connect | openssl x509 -noout -text

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

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc,, CN=DigiCert SHA2 High Assurance Server CA
            Not Before: Dec 12 00:00:00 2014 GMT
            Not After : Dec 16 12:00:00 2016 GMT
        Subject: C=US, ST=California, L=San Jose, O=PayPal, Inc., OU=PayPal Production,
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
            X509v3 Subject Key Identifier:
            X509v3 Subject Alternative Name:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:

                Full Name:

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.1.1

            Authority Information Access:
                OCSP - URI:
                CA Issuers - URI:

            X509v3 Basic Constraints: critical
    Signature Algorithm: sha256WithRSAEncryption


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.

openssl s_client -connect

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

139677333890704:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 36 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
    Protocol  : SSLv2
    Cipher    : 0000
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1428910482
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Client Initiated Renegotiation

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

openssl s_client -connect

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.

openssl s_client -connect host:port
<Enter or Return key>

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. 


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


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: 

openssl s_client -connect

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. 

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
    Protocol  : TLSv1.1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 50791A02E03E42F8983344B25C8ED4598620518D5C917A3388239AAACE991858
    Master-Key: 9FEDB91F439775B49A5C49342FF53C3DD7384E4AFC33F9C6AFB64EA3D639CA57253AD7D059BA54E01581AD3A73306342
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 34 38 24 70 35 88 4a 68-0c 80 e6 c5 76 a1 0e ee   48$p5.Jh....v...
    0010 - 14 2e fb ef fa 42 f0 c1-58 ee 70 02 90 45 f4 8c   .....B..X.p..E..
    0020 - 7d 0b 2e 1e 71 70 b0 a2-cc 27 1b 13 29 cc f5 ee   }...qp...'..)...
    0030 - 84 43 98 fa b1 ae 83 dc-ff 6d aa 07 9f 7a 95 4f   .C.......m...z.O
    0040 - 44 68 63 21 72 d7 b9 18-97 d8 8e d7 61 7d 71 6f   Dhc!r.......a}qo
    0050 - a7 16 85 79 f9 a2 80 2a-b4 bc f9 47 78 6a b7 08   ...y...*...Gxj..
    0060 - f6 4f 09 96 7b e8 d4 9b-26 2d 1a fd 55 fe 6a ab   .O..{...&-..U.j.
    0070 - fc 8d 6d 87 7a 13 e1 a9-0a 05 09 d9 ce ea fe 70   ..m.z..........p
    0080 - 09 c9 5f 33 3c 5f 28 4e-20 3b 3a 10 75 c4 86 45   .._3<_(N ;:.u..E
    0090 - 1d 8b c8 a5 21 89 a1 12-59 b6 0f 55 e3 48 8f 91   ....!...Y..U.H..
    00a0 - 01 af 53 b6                                       ..S.

    Compression: 1 (zlib compression)
    Start Time: 1348073759
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

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.

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 7E49EA6457B200B441A26C05F1AE9634AAF97284AC7A12EC58F69CEF5470B052
    Master-Key: E035F082F5545424373A546A1F76D77673E8AEE018B3F0A3AFD7A3545746013664C18E6BB69F08BFAECA6C7FB3010C9C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 66 72 6f 6e 74 70 61 67-65 61 61 61 61 61 61 61   frontpageaaaaaaa
    0010 - 89 55 c6 6a 92 c3 28 85-86 b0 ff c3 08 12 5a a8   .U.j..(.......Z.
    0020 - f2 ec f8 56 6d d3 29 99-7b 98 90 ef 57 fd c6 15   ...Vm.).{...W...
    0030 - ee a2 53 4b 43 ef 19 ee-41 25 1f 76 28 37 68 b6   ..SKC...A%.v(7h.
    0040 - 64 ca e7 3f 71 01 70 30-35 91 ef bc d8 19 20 4f   d..?q.p05..... O
    0050 - 9d 9e 2c ab 3f 35 5c 3f-65 f8 c6 9a a9 90 fa 60   ..,.?5\?e......`
    0060 - 4d 53 a1 b8 49 8c e7 61-e4 6c e1 51 8e 83 b5 25   MS..I..a.l.Q...%
    0070 - bc 9a 32 d8 fa be 16 a1-ae 3d 8c 0b e3 9e e4 78   ..2......=.....x
    0080 - 77 d7 91 6b a9 a0 01 2b-e1 98 33 d4 2c eb b3 84   w..k...+..3.,...
    0090 - f9 da 0f fa 77 df ac d6-08 b6 34 97 07 d9 b2 58   ....w.....4....X

    Start Time: 1428988675
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)


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

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

GET / HTTP/1.1
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.

HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Sun, 19 Mar 2015 20:48:31 GMT
Content-Type: text/html
Last-Modified: Thu, 19 Mar 2015 23:34:28 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip
¬ =�A
   �}E�� �/�փg�
�� oP��
��u4��22��,f&4Y��Į9 .�R�oKc�]�`|�o�r

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

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.


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, 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.

nmap -p 443 --script ssl-heartbleed --script-args vulns.showall

The output will be similar to the following:

443/tcp open  https
| ssl-heartbleed:
|   The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
|     State: VULNERABLE
|     Risk factor: High
|     Description:
|       OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|     References:

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

nmap -p 443 --script ssl-ccs-injection

Sample Output

443/tcp open  https
| ssl-ccs-injection:
|   SSL/TLS MITM vulnerability (CCS Injection)
|     State: VULNERABLE
|     Risk factor: High
|     Description:
|       OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
|       1.0.1h does not properly restrict processing of ChangeCipherSpec
|       messages, which allows man-in-the-middle attackers to trigger use
|       of a zero-length master key in certain OpenSSL-to-OpenSSL
|       communications, and consequently hijack sessions or obtain
|       sensitive information, via a crafted TLS handshake, aka the
|       "CCS Injection" vulnerability.
|     References:


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.

Contact and Follow-Up

Jay and Dan are a part of our Assurance team based in our Melbourne office.

Subscribe for more Research like this

About Jay Kalsi and Daniel Mossop

CHECK IT Health Check Service
Cyber Essentials
CESG Certified Service
First - Improving Security Together
BSI ISO 9001 FS 581360
BSI ISO 27001 IS 553326
PCI - Approved Scanning Vendor