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 google.com 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 www.google.com:443
CONNECTED(00000003)
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/CN=www.google.com
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
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x
MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy
wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B
d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp
ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le
IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
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
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 8FEF40B71445984250A6658D3664CB8D391EEA43EB40CD535249FAB6EFC79F11
Session-ID-ctx:
Master-Key:
8CFE3997E583BC3D9FDBCC81F3FA136DCC1872818FF9BECA6B10C64EA03D6D52C163DA470779E7D5AB23A89967A05E39
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
(0x0005).
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)
Challenge
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)
Random
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!
Count Upon Security 