Monthly Archives: June 2013

Browser Exploit Against SSL/TLS

On my last post I wrote about how cipher suite decision works on SSL with a practical example. Today, I would like to write about what is the impact of choosing and prioritizing the appropriate cipher suites on your SSL environment.

Back in May 2011, Juliano Rizzo and Thai Duong released a paper named Here Come The XOR Ninjas [1]. This paper was a contribution to the security community on illustrating a concrete proof of concept against implementations of SSL 3.0 and TLS 1.0 using cipher block chaining (CBC) encryption scheme in a browser environment [3]. The attack also become known as The BEAST (Browser Exploit Against SSL/TLS) [2]. It has been widely publicized after it’s released since the vulnerability was known in the research community but before the paper, attacks against CBC were believed to be theoretical. As a reference, the use of predictable initialization vectors (IV) for CBC mode in a chosen-plaintext attack against SSL 3.0 and TLS 1.0 are described by Bodo Moeller here and by Gregory Bard here.  In a SSL connection if the data is encrypted using CBC with chained IVs, it allows a man-in-the-middle to obtain plain text HTTP headers using blockwise-adaptive chosen-plaintext attack [4][5]. In short it will allow decrypting HTTPS requests and steal information such as session cookies to be used to impersonate the user. The attack has been demonstrated by the researchers on the Ekoparty security conference using Java, a network sniffer and a popular browser [8].

Are you vulnerable to such attack? To quickly verify your web server SSL settings I would recommend looking at SSL Labs from Qualys and running the SSL Server test. If, for example,  you use a SSL load balancer or application firewall from F5 take a look here on how to reduce the exposure to this attack. All major vendors have information about how to configure and remediate this vulnerability. On 09 July 2011 the US National Vulnerability Database published CVE-2011-3389 to address this vulnerability with a CVSS score of 4.3.

On the other hand, in order to remediate this vulnerability the focus should be on configuring the web servers to prioritize a different cipher suite, or upgrade to TLS 1.1/1.2 [8]. Also consider that this attack has a low CVSS score and it’s not easy to pull. Therefore, unless you are exposed to someone who would have the means, motive and opportunity it might be worth to spend time on fixing other things.

If you want to read more about it, I would recommend taking a look at Thai Duong blog article he released one week after the security conference. The summary from Thierry Zoller and the below references.


Tagged , , , , , ,

SSL Handshake Protocol

Some years ago during the recruitment phase for a position in professional services. At the end of the technical interview, the practice manager asked if I could provide him by email a little research about the SSL handshake (specific to Web applications) and let him know about the decision on cipher suites, which side (client or server) makes the decision. Basically he wanted to know who makes the decision about which cipher suite to use and details behind it.

I must say I really liked the challenge because it allowed me to do research and build documentation about security matters. So I made a small investigation using one or two good books and produced a three pages document with the technical details.

This is what this blog entry is about. I would like to share with not the three pages document but a short technical summary about the answer I provided on the SSL handshake protocol and the CipherSuite parameter decision. Plus a practical illustration on the usage of the SSL handshake protocol and the cipher suite decision process using openssl and tshark tools.

In short, the most difficult part of SSL stack is the handshake protocol. During the phase 1 of the handshake protocol, where it’s established the security capabilities, the exchange is initiated by the client who sends a client_hello message with a set of parameters. One of those parameters is the CipherSuite which is a list that contains the combinations of cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec.

After sending the client_hello message, the client waits for the server_hello message, which containts the same parameters as the client_hello message. Again, here one of the parameters is the CipherSuite, which in the server_hello message contains the single cipher suite selected by the server from those proposed by the client. With this two messages the phase 1 is established and the SSL establishments continues with the phase 2 which is the Server Authentication and Key Exchange. Then the phase 3 for Client Authentication and Key Exchange. Finally the phase 4 to complete the handshake and begin to exchange application layer data.

In short and to make a direct answer to his question: the cipher suits are proposed by the client and decided by the server.

Now, the interesting part is below where a practical exercise was made to illustrate this.

Running on a Linux system I established a HTTPS connection with the host www using openssl command and in parallel executed tshark to capture the packets. Some of the verbose output has been omitted to show what is truly pertinent to the SSL Handshake protocol.

In the output of the openssl command we can see the server X.509 public certificate and its parameters and that the SSL handshake protocol was accomplished using RC4-SHA as cipher and TLSv1 as protocol.

lrocha@host:~$ openssl s_client -connect
 depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 verify error:num=20:unable to get local issuer certificate
 verify return:0
 Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/
 i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
 Server certificate
 subject=/C=US/ST=California/L=Mountain View/O=Google Inc/
 issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 No client certificate CA names sent
 SSL handshake has read 1772 bytes and written 307 bytes
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 Protocol : TLSv1
 Cipher : RC4-SHA
 Session-ID: 8FEF40B71445984250A6658D3664CB8D391EEA43EB40CD535249FAB6EFC79F11
 Key-Arg : None
 Start Time: 1335093485
 Timeout : 300 (sec)
 Verify return code: 20 (unable to get local issuer certificate)

With tshark we can see that during the client_hello message the client proposes
26 cipher specs in order of preference which by its turn it’s followed by the server_hello
message which decides to use the Cipher Suite: TLS_RSA_WITH_RC4_128_SHA

lrocha@host:~$ tshark -i eth0 -Vx -s0 port 443 

Secure Socket Layer 
 SSLv2 Record Layer: Client Hello
 [Version: SSL 2.0 (0x0002)] 
 Length: 119 
 Handshake Message Type: Client Hello (1) 
 Version: TLS 1.0 (0x0301) 
 Cipher Spec Length: 78 
 Session ID Length: 0 
 Challenge Length: 32 
 Cipher Specs (26 specs) Cipher Specs (26 specs)
 Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) 
 Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) 
 Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) 
 Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) 
 Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) 
 Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) 
 Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) 
 Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) 
 Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
 Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) 
 Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) 
 Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) 
 Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) 
 Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) 
 Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) 
 Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014) 
 Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) 
 Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) 
 Cipher Spec: Unknown (0x0000ff) 

Secure Socket Layer 
 TLSv1 Record Layer: Handshake Protocol: Server Hello
 Content Type: Handshake (22) 
 Version: TLS 1.0 (0x0301)
 Length: 81 
 Handshake Protocol: Server Hello 
 Handshake Type: Server Hello (2) 
 Length: 77 
 Version: TLS 1.0 (0x0301) 
 gmt_unix_time: Aug 22, 2009 07:18:05.000000000 EDT 
 random_bytes: 4abfee70b2a89e684e917c40c47054bf074028babe764af3... 
 Session ID Length: 32 
 Session ID: 8fef40b71445984250a6658d3664cb8d391eea43eb40cd53... 
 Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
 Compression Method: null (0) 
 Extensions Length: 5 
 Extension: renegotiation_info 
 Type: renegotiation_info (0xff01) 
 Length: 1 
 Data (1 byte)

Bottom line, I didn’t got the job but it was fun!