Recently I created a presentation for a client on SSL. The purpose was to give a packet level view of the SSL protocol so the client and their support team would have a better understanding of the problems they had. The original presentation was done in powerpoint so I adapted it to blog format.
Brief SSL History
SSL v1 was developed by Netscape back in 1994. It was developed with the main purpose of security web browser traffic to the server. Now the SSL protocol is used for many different system to system communications.
SSL v2 was released but contained numerous vulnerabilities so was not widely adopted and deployed.
SSL v3 was released in 1996 and is still used by a great number of systems. One system I was troubleshooting recently had a Java client that would only support SSL v3.
Up to this point the protocol SSL was developed and managed by Netscape. In 1999 the Internet Engineering Task Force (IETF) used the SSLv3 base to create a standards based secure protocol and released it as TLS v1.0. In my experience this is the most widely used version of SSL used in securing communications.
TLS v1.1 and v1.2 have been released but not many browsers support them. With the recent uptick in SSL exploits you will see more focus placed on securing communications via browsers and system to system communications.
(This is after the 3 way TCP Handshake)
This is an basic overview of the communication between a client and server.
On Step 2 the server can be configured one of two ways. If the server needs to authenticate the client it will initiate a Dual Side Authentication channel. This will require the client to provide a certificate to authenticate its entity. Most communication over SSL utilizes the Single Side Authentication process but I will highlight the differences between these two methods.
Server Hello – This part is sent for both methods and provides basic information for the connection.
Certificate – This part is also sent for both methods of connection and provides the server’s public key. This will be used later to encrypt information back to the server.
Certificate Request – This is only sent during a single side authentication. (Hint) It contains some very important information when troubleshooting failures for these types of connections.
Server Hello Done – Is always sent for this type of communication.
Since we have reviewed two methods of SSL connections, dual side and single side authentication, the client also has two methods to respond depending on what the server required.
Certificate – If the method requested was for Dual Side Authentication the client will respond with its certificate. This will not happen for the Single Side Authentication. The certificate in this case will only be used for authentication of the client identity to the server. It will not be used to encrypt data like the server’s certificate. If the client doesn’t have a certificate it SHOULD respond with a 0 length cert. This doesn’t always happen and errors between systems and non-standard interactions will fail the connection.
Client Key Exchange – This is where the magic happens. The key generated here will be used as the seed to the Master Secret Key which is used to encrypt all the traffic between the systems.
Change Cipher Spec – This message is included with all methods of SSL channel setups.
Encrypted Handshake Message – A very simple notification to say everything will now be encrypted.
And finally, the server responds with a Change Cipher Spec and Encrypted Handshake Message.
If all goes well your traffic will be encrypted between the client and server. With Wireshark you have the ability to capture encrypted traffic and decrypt inside the tool. To accomplish this you will need the server’s private key and also capture the packets listed here. In a future blog I will show how to setup Wireshark to capture and decrypt the traffic.
I hope this helps and provides some insight into the SSL protocol capture analysis.