2. ChangeCipherSpec Layer
The ChangeCipherSpec layer is composed of one message that signals the beginning of secure communications between the client and server. Though the ChangeCipherSpec Protocol uses the Record Layer format, the actual ChangeCipherSpec message is only one byte long, and signals the change in communications protocol by having a value of ‘1’.
3. Alert Protocol
This protocol sends errors, problems or warnings about the connection between the two parties. This layer is formed with two fields: the Severity Level and Alert Description.
Severity Level
The Severity Level sends messages with a ‘1’ or ‘2’ value, depending on the level of concern. A message with a value of ‘1’ is a cautionary or warning message, suggesting that the parties discontinue their session and reconnect using a new handshake. A message with a value of ‘2’ is a fatal alert message, and requires that the parties discontinue their session.
Alert Description
The Alert Description field indicates the specific error that caused the Alert Message to be sent from a party. This field is one byte, mapped to one of twelve specific numbers, and can take on one of the following meanings. Those descriptions that always follow a “fatal” alert message are underlined.
4. Handshake Protocol
It messages passed back and forth between the user’s browser (client) and web application (server) establish a handshake that begins a secure connection.
This is the most complex part of SSL and allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. This protocol is used before any application data is sent. It consists of a series of messages exchanged by the client and server. Each message has three fields:
i. Type (1 byte): Indicates one of 10 messages such as “hello request”.
ii. Length (3 bytes): The length of the message in bytes.
iii. Content(≥ 0 byte): The parameters associated with this message such version of SSL being used.
The Handshake Protocol is shown in figure . This consists of four phases:
i. Establish security capabilities including protocol version, session ID, cipher suite, compression method and initial random numbers. This phase consists of the client hello and server hello messages which contain the following (this is for the client however it’s a little different for the server):
- Version: The highest SSL version understood by client
- Random: 32-bit timestamp and 28 byte nonce.
- Session ID: A variable length session identifier.
- CipherSuite: List of cryptoalgorithms supported by client in decreasing order of preference. Both key exchange and CipherSpec (this includes fields such as CipherAlgorithm, MacAlgorithm, CipherType, HashSize, Key Material and IV Size) are defined.
- Compression Method: List of methods supported by client.
ii. Server may send certificate, key exchange, and request certificate it also signals end of hello message phase. The certificate sent is one of a chain of X.509 certificates discussed earlier in the course. The server key exchange is sent only if required. A certificate may be requested from the client if needs be by certificate request.
iii. Upon receipt of the server done message, the client should verify that the server provided a valid certificate, if required, and check that the server hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server. The client sends certificate if requested (if none available then it sends a no certificate alert instead). Next the client sends client key exchange message . Finally, the client may send certificate verification.
iv. Change cipher suite and finish handshake protocol. The secure connection is now setup and the client and server may begin to exchange application layer data.
