Transport Layer Security - Part 2 SSL

Introduction
I have already discussed about SSL in my previous article. Here I will be explaining you SSLv3. It is developed by Netscape company .In this section I will discuss on SSLv3.

General SSL Architecture
It is designed to secure end-to-end service on the internet. I will illustrate that SSL is not a single handed protocol. It is a layer of more than one protocol such as
a.    SSL record protocol
b.    SSL handshake protocol
c.    SSL change cipher spec protocol
d.    SSL alert protocol

 

The SSL record protocol provides basic necessary security to other higher level protocols specially HTTP which is responsible to server client interaction. Another three protocols are responsible in management for the whole SSL exchange. There are basic two concepts in SSL. They are as below:

a.    SSL connection : In SSL mechanism connections are P2P (Peer-to-peer) relationship.
b.    SSL session : Its client-server association. Most likely it is created by the SSL handshake protocol.



SSL Record Protocol
It provides mainly two services for SSL connection such as:
a.    Integrity : Handshake protocol, which produces a shared secret key is used to form the MAC (Message Authentication Code).
b.    Confidentiality : Handshake protocol produces shared secret key to encrypt the SSL payload.
Below figure describes the operation of this protocol.

Record protocol takes application data and does the fragmentation of data into some blocks. Then it compresses it and adds MAC into that in order to encrypt the data. Finally header information added to it and transmitted to TCP segment. In Fragmentation application data is fragmented into blocks of 214 bytes or less. Then the compression it applies has to be loss less compression. It should not increase the content length more than 1024 bytes. This compression is an optional. SSLv3 doesn’t use any compression mechanism. After that, the MAC is computed in which shared secret key is used. The SSLv3 MAC algorithm is based on HMAC which you may find in RFC 2104. The latest version of HMAC uses XOR. Then encryption comes. It may increase content length more than 1024 but the total length of it should not exceed 214+2048.


The following table gives the encryption algorithm along with their key size which are permitted.

Algorithm	Key Size
RC4-40	40
RC4-128	128
AES	128,256
Fortezza (Used in Smartcard Encryption)	80
IDEA	128
RC2-40	40
3DES	168
DES-40	40
DES	56

                                   

The final step of the SSL Record protocol is to add header information to the final encrypted content.

Change Cipher Spec Protocol
Change cipher spec protocol is the one who uses the SSL record protocol. It helps the party to avoid a pipeline stall. It is a TLS protocol. It consists one single message of 1 byte. It causes a pending state in order to copy it from there to current state. It updates the encrypted text to be used in TLS.

 

Architecture of SSL Record is as below:

 

SSL Alert Protocol
Most likely it is used to send and receive SSL related alerts to end to end identity. These alert messages are also compressed and encrypted. Below figure describes the alert protocol structure.

Each message within this protocol occupies 2 bytes as shown in above figure. Level bytes takes value warning and alert byte convey severity of the payload. If level becomes fatal, SSL will directly terminate the connection. If there are more connections on same sessions, then they may continue. The Second byte “Alert” contains the code which produces a specific alert. Some alerts are listed below and they those can be identified by their name. 

1. bad_certificate
2. unsupported_certificate
3. certificate_revoked
4. illegal_parameter
5. decompression_failure
6. bad_record_mac
7. handshake_failure
8. no_certificate
9. certificate_expired

SSL Handshake Protocol
The most important and complex part of SSL is SSL handshake and the protocol of it. This protocol allows both ends to connect each other, authenticate each other, negotiation an encryption between them and exchanging packets between each other. It contains a series of message transferred between server & client.
The SSL handshake happens in four main phases.

Phase 1. Establishing Connection and Capabilities For Security
It initiates the logical connection between client & server. It also generates security capabilities with which server & client both will associate in the future.

Here RN means random numbers which are generated by clients. It consists of 32 bit timestamp & 28 bytes. First client sends client_hello message and waits for the server to reply. The server then replies client with server_hello message. Both messages contain the same parameters such as version, session ID, cipher suite, compression method, initial random number.  Then the random field is generated by the server which is different than the client’s one. Cipher suite contains a single cipher suite which is selected by the server and then the compression field contains the compression method selected by the server.

Phase 2. Key Exchange & Server Authentication
The server sends a certificate to a client which needs to be authenticated. It contains one or more chain of X.509 certificates. Then server_key_exchange message may be sent if its required. Generally it is required if you use anonymous Diffie-Hellman, ephemeral Diffie-Hellman, RSA key exchange & Fortezza. The below figure illustrates the architecture of phase 2.

 

Phase 3. Key Exchange & Client Authentication
After the server sends a certificate to client, client should verify it that whether it is valid or not. If everything is satisfactory, then the client sends more than one message back to the server. If there is no any suitable certificate there, then the client sends a no_certificate alert to the server. Then the client sends client_key_exchange_message. The below figure illustrates the architecture of phase 3.

 

In this phase client sends certificate_verify message to the server. This certificate always has signing capability. It signs hash code based on the previous message. Here verification needs to be done by signing a certificate so if any person's misuse it then he/she won’t able to send this message.

Phase 4. Finish Phase
It accomplishes the secure connection. The client sends change_cipher_spec message. The client also copies remaining cipher_spec into the current cipher_spec. Then the client sends finish message. Only finish message verifies that key authentication and exchanging of the key has been successfully completed. The below picture shows the structure of last phase.

 

In a nutshell, the whole SSL process can be illustrated as shown in below figure.

 

ConclusionThrough this article I tried to simplify and tried to describe SSL, its architecture and how SSL handshake is being done. I also mentioned which are the encryption algorithms are being used in SSLv3. Article simplifies the 4 main phases of important SSL handshake too. In my next article I will be presenting “Transport layer security”.

References
1.    http://i.technet.microsoft.com/dynimg/IC197613.gif
2.    http://technet.microsoft.com/en-us/library/Cc767139.f14-4_big%28l=en-us%29.gif
3.    http://en.kryptotel.net/images/sslprocess.jpg
4.    http://www.hit.bme.hu/~buttyan/courses/BMEVIHI4372/ssl.pdf
5.    http://www.pierobon.org/ssl/ch2/record.htm
6.    http://www.pierobon.org/ssl/ch2/hand.htm
7.    http://www.pierobon.org/ssl/ch2/alert.htm
8.    http://pic.dhe.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtps5%2Fs5hand.html
9.    http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html