Anothe article, which I wrote some weeks ago for university. This time the Transport Layer Security is covered.
This article deals with security in network communication and in this area especially with the protocol family of SSLv3 and TLS.
Therefore in the first section the general motivation for security in network communication will be given. Thereafter an overview of SSL/TLS will be given and afterwards an in-detail explanation of the establishment of a secure connection will be shown. At last some applications and protocols, which make use of SSL/TLS are shown and a final conclusion is given.
In a perfect world, where everybody trusts his commuication partners and where nobody wants to harm someone else, there would be no need for security, but this is not the Internet as it is today. Therefore sensible data, like authentication credentials, personal data or payment data has to be protected to ensure that such data is kept confidential. This protection has originally not been included into the HTTP protocol because when it has been designed security was not a problem.
As a result of the missing security features the data, which the user transmits by using a website is usually sent in cleartext. This leads us to the problem, that an adversary, which is performing a man-in-the-middle attack can simply read and also alter any contained cleartext login, banking data or purchase data.
This is the entry point of SSL/TLS, because it establishes a secure communication channel between two communication partners and ensures confidentiality, integrity and also can ensure authenticity.
A typical man-in-the-middle attack can be seen in the picture above. In the scenario Alice wants to communicate with Bob, but Trudy has found a way to reroute their direct connection over his system. Such a rerouting for instance is possible by poisoning the ARP table of a router (this means, that the system is told, that the shortest path between Alice and Bob is via Trudys machine).
The picture below shows the Wireshark log of an HTTP request, which was made during the login process to the forum of the Fachschaft Informatik. As it can be seen in the picture the login name and the password is transmitted in cleartext.
Secure Socket Layer (SSL) and Transport Layer Security (TLS) are protocols, which aim at enhancing the TCP protocol with security services, like confidentaility and auhentication.
If we think about securing communication or data in general against exploration it becomes clear, that the best way to avert this is by using cryptography. But if we think about this there is one big problem, which is the distribution of the keys. So there has to be some mechanism, which is able to negotiate a key between the server and the client.
This will now be shown during the explanation of the SSL protocol.
The SSL Protocol
The SSL protocol itself is built up of two layers, as it is shown in the picture below.
SSL Record Protocol
The lower layer, is called the SSL Record Protocol and is placed direct on top of the transport layer. It provides end-to-end-encryption using symmetric cryptography. The used key has to be negotiated within the Handshake Protocol. Besides this it is responsible for ensuring integrity and authenticity by the use of cryptographic hash functions (normally MD5 and SHA-1 are used).
SSL Handshake Protcol
The Handshake Protocol is placed on the upper layer and is responsible for the negotiation of a session key, which then can be used by the Record Protocol, with the communication partner. For the negotiation asymmetric cryptography is used. The handshake will be discussed more in detail in a later section.
SSL Change Cipher Spec Protocol
The Change Cipher Spec Protocol is simply responsible for changing the cipher suite during the negotiation with the communication partner.
SSL Alert Protocol
This protocol is responsible for interpreting the alert messages, which can occur during the use of SSL. These messages range from telling about the end of the established connction to critical warning messages about an unexpected message.
SSL Application Data Protocol
This protocol is responsibel for segmentation of the application data and encrypting the segments afterwars.
The SSL Handshake
In this section the handshake mechanism during the establishment of a SSL secured connection will be described step by step. The overall procedure can be seen on figure SSL1.
The Client initiates a connection by sending a Client Hello message ot the server. The contents of this message are:
Rc = 32-bit timestamp and a 28-byte random number. This part is needed for the detection of replay attacks
ID = Session identificator, which can be used for resuming a former session
Lc = A list containing the cipher suites and compression algorithms, which are supported by the client. These are sorted according to the priority (usually the strongest algorithm has the highest priority)
As an reply to the Client Hello the server sends the Server Hello message to the client, with the following contents:
Rs = a nonce analog to Rc of the client
L = the chosen cipher suite (from the list Lc of the client)
Optional the server can send his certificate to the client for authentification. If the server does not send his certificate he has to provide an temporary public key to the client.
The server has also the possibiliy to request the clients certificate, but this is optional.
After this the Server Hello is done.
Response from the client
The client now posseses a public key of the server. This key has either been extracted from the certificate or has been provided direct by the server. If a certificate has been used the client now has the possibility to check the validity of the certificate and the contained key of the server by checking if a valid CA (Certification Authority) created the certificate. A sample can be seen beneath.
If the credentials of the server have been verified the client may provide his own certificate to the server (this step is optional).
The client now will initiate the Client Key Exchange. Therefore a Pre-Master Secret is generated (48 byte long) and then encrypted with the public key of the server and transmitted. After this the client switches to the chosen cipher suite and all communication is encrypted from this point on with a key derived from the master secret.
Besides this a MD5 and a SHA-1 MAC (Message Authentication Code) for all exchanged data is generated and used for verifying that server and client received the same data. This is called the Finished-message.
Server side again
The server received the encrypted Pre-Master Secret from the client. After decrypting this message with his private key the server has to compute the master secret and derive the session keys from this for resuming the communication with the client. For in-detail information on the computation of the master secret and the according keys please refer to .
After this the server also changes the used cipher suite to the chosen one and uses his derived keys for securing the communication with the client. He also generates a Finished-message in the same way as the client does and communication is only resumed, if the computed MACs match.
If one party wants to end the communication it simply sends a close_notify alert message to the communication party. The session then will be teared down.
SSL/TLS in Action
The figure below shows the trace of a connection with a TLS using server (Deutsche Bank). All former described handshake steps can be found. An explanation is given below the picture.
Line 13/14: Here the connection is still a normal TCP connection.
Line 15/16: The client initiates the handshake by sending the Client Hello to the server
Line 17/18: The server answers the client with a Server Hello message
Line 23: Additional to the Server Hello the server provides his certificate to the client and after this sends the Server Hello Done message
Line 24: The client now calculates the Pre Master and provides this to the server. From this point on all messages from the client are encrypted.
Line 26: The server calculates the Master and after this also changes the cipher suite. The communication channel is secured from this point on.
Line 27: The Application data is exchanged. The transmitted application data can be seen in the bottom of the picture. An adversary, who is monitoring the network could not gain any information from this ciphertext.
Usage of SSL/TLS
SSL/TLS is due to the good security of the transmitted data often used in applications and also in combination with protocols, which do not provide security by themselves, for securing the communication with these protocols.
SSL/TLS is included in nearly every browser or server nowadays, as it can be seen in the figure above the browsers support at least one of the both protocols or even both. In this context normally TLS is used or SSLv3 if TLS is not available. SSLv2 should be disabled and give a warning message in the users client if it is used. Besides the domain of browsers and webservers SSL is also used during the establishment of a VPN connection.
If the web browser detects, that a website uses SSL/TLS secured communication and also a certificate is provided, an information is presented in the address bar as shown below. By clicking on the colored space the user normally is also granted additional information about the received certificate and the communication security.
Combined with other protocols
Many internet protocols have not been designed to ensure security and confidentiality of data during transmission. Due to the fact that these are already wide-spread replacing of the currently used protocols with secure ones is almost impossible. Therefore these protocols are combined with SSL/TLS to ensure an high level of security for the transmitted data.
Popular protocols, which have been combined with SSL are: HTTP, POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP and FTP.
IANA assigned ports for SSL secured protocols
The following ports have been assigned by the IANA (Internet Assigned Numbers Authority) for SSL secured protocls
What TSL/SSL does not provide
As it has been shown above SSL/TLS gives the user a reasonable security improvement. So the users sensible data is transmitted encrypted, so that confidentiality is guaranteed. Also due to the certificates, which are used during the SSL protocol the user has an information about the identity of his communication partner and has the possibility to verify his communication.
But it also has to be acknowledged, that SSL/TLS is not the holy grail of networking security, because an adversary still has the ability to bypass the security mechanisms of SSL to gain some profit. For instance an adversary might reroute some domain to his own server, somehow like phishing. If now the user does not check the provided certificate he might expose all information which the enemy wants to gain. Besides this a man-in-the-middle attack is still possible, but it is not as easy as before.
Vorlesungsfolien Network Security Chapter 04, Module 02; Summer 2010; Prof. Dr.-Ing. Matthias Hollick, TU Darmstadt
 Vorlesungsfolien Network Security Chapter 04, Module 03; Summer 2010; Prof. Dr.-Ing. Matthias Hollick, TU Darmstadt
James F. Kurose and Keith W. Ross. Computer Networking. Pearson. 2010
 C. Eckert. IT-Sicherheit. Oldenbourg. 2005
Figure SSL1 taken from