I’ve already discussed SSL in my previous article. Here I’ll be explaining SSLv3. It was developed by Netscape.
General SSL Architecture
It was designed to secure end-to-end services on the internet. I’ll show that SSL isn’t a single handed protocol. It’s a layer of more than one protocol such as:
- SSL record protocol
- SSL handshake protocol
- SSL change cipher spec protocol
SSL alert protocol
The SSL record protocol provides basic security to other higher level protocols, specially HTTP, which is responsible for server client interaction on the web. The other three protocols are responsible for managing for the whole SSL exchange. There are two basic concepts in SSL. They are:
- SSL connection : In SSL, mechanism connections are a P2P (Peer-to-peer) relationship.
- SSL session : Its client-server association. Most likely created by the SSL handshake protocol.
SSL Record Protocol
It provides two main services for SSL:
- Integrity : Handshake protocol, which produces a shared secret key, used to form the MAC (Message Authentication Code).
- Confidentiality : Handshake protocol produces a shared secret key to encrypt the SSL payload.
The chart below describes the operation of the protocol.
The record protocol takes application data and fragments data into blocks. Then it compresses and adds a MAC to encrypt the data. Finally header information added and transmitted to the TCP segment. Fragmentation application data is fragmented into blocks of 214 bytes or less. Then the compression it applies has to be lossless. It shouldn’t increase the content length more than 1024 bytes. Compression is optional. SSLv3 doesn’t use any compression mechanism. After that, the MAC is computed in which a 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, it’s time for encryption. It may increase the content length more than 1024, but the total length of it should not exceed 214+2048.
The following table shows encryption algorithms and their key sizes.
|Fortezza (Used in Smartcard Encryption)||80|
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 uses the SSL record protocol. It helps the party to avoid a pipeline stall. It’s a TLS protocol. It consists of one single message of one byte. It causes a pending state in order to copy it to the current state. It updates the encrypted text to be used in TLS.
The architecture of SSL record:
SSL Alert Protocol
It’s usually used to send and receive SSL related alerts to end to end identities. These alert messages are also compressed and encrypted. The figure below shows the alert protocol structure.
Each message uses two bytes. The level byte is a value warning and the alert byte conveys the severity of the payload. If the level becomes fatal, SSL will directly initiates a connection. If there are more connections in same session, then they may continue. The alert byte contains code which produces a specific alert. Some alerts are listed below and they can be identified by their name.
SSL Handshake Protocol
The most important and complicated part of SSL is the SSL handshake protocol. This protocol allows both ends to connect each other, authenticating each other, negotiating encryption and exchanging packets. It contains a series of messages transferred between a server and client.
The SSL handshake has four main phases.
Phase 1. Establishing Connection and Capabilities For Security
It initiates the logical connection between a client and a server. It also generates security capabilities of which a server and a client will both use.
RN are random numbers which are generated by clients. It consists of a 32 bit timestamp and 28 bytes. First, the client sends a client_hello message and waits for the server to reply. The server replies to the client with a server_hello message. Both messages contain the same parameters such as versions, session IDs, cipher suites, compression methods, and initial random numbers. Then, a random field is generated by the server which is different than the client’s. The cipher suite contains a single cipher which is selected by the server. 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 chains of X.509 certificates. Then, the server_key_exchange message may be sent if it’s required. It’s necessary if you use anonymous Diffie-Hellman, ephemeral Diffie-Hellman, RSA key exchange or Fortezza.
Phase 3. Key Exchange & Client Authentication
After the server sends a certificate to a client, the client should verify whether it’s valid or not. If everything is satisfactory, then the client sends more than one message back to the server. If there is no suitable certificate, The client sends a no_certificate alert to the server. Then the client sends a client_key_exchange_message.
In this phase a client sends a certificate_verify message to the server. This certificate always has signing capability. It signs a hash code based on the previous message. Verification needs to be done by signing a certificate. If anyone misuses it, then they won’t able to send that message.
Phase 4. Finish Phase
The fourth phase creates a secure connection. The client sends a change_cipher_spec message. Then, the client copies the new cipher_spec into the current cipher_spec. Then, the client sends a finish message. Only the finish message verifies that the key authentication and exchanging of the key have been successful.
In a nutshell, the whole SSL process can be illustrated as shown in the figure below.
In this article I tried to simplify and describe SSL, it’s architecture and how the SSL handshake works. I also mentioned the encryption algorithms that are used in SSLv3. In my next article I will present Transport Layer Security.