Understanding SSL Handshake Protocol
Due to the elaborate explanation required to comprehend SSL protocol, we have divided this SSL tutorial, into multiple parts.
Read: Record Protocol in SSL
Read:Working of Secure Socket Layer
In this post, we will understand "SSL Handshake Protocol".
SSL protocol, does its fantastic job of securing communication over the wire, with the help of multiple layers of protocols, above TCP(And After Application Layer).
- Always keep in mind that, although HTTP protocol is the protocol, which highly makes use of SSL, to secure communication. SSL is an application layer independent protocol.So you can use that with any application layer Protocol.
There are different versions and types of encryption and authentication algorithms out there. SSL can make use of, most of them out there. But a major point to note here is that, both the server and client must first agree on the same algorithm, that they are going to use in their communication.
As the client is the first person to begin the communication, the first step that the client does is to tell server, about the cipher suits and MAC(Message Authentication code, this is made in record Layer.Read Record Layer Protocol in SSL) hash algorithm's it supports.
This is done by sending a CLIENT-HELLO message. The client's Hello message consists of the following contents.
- SSL version that the client supports
- In what order the client prefer the versions
- The ciphersuits(Cryptographic Algo's) supported by the client
- Compression methods supported if any
- Random Number
- Keep in mind that, during the SSL initial handshake, nothing is encrypted. So anybody can sniff, and see whats going on. Encryption, starts only after the master secret(which will be used to encrypt and decrypt data as well as MAC calculation) is send by the client
Client Hello message content in SSL/TLS
- SSL VERSION NUMBER : the client sends a list of ssl version it supports. And priority is given to the highest version it supports
- Random Data Number : Its made up of 32 bytes. 4 byte number made up from client's date & time plus 28 byte randomly generated number(this will be used with server's random value made of date & time for generating the "master secret", from which encryption key will be derived).
- SESSION ID: In order to enable client's resuming capabilities this session ID is included.
- CIPHER SUITS: RSA algorithm is used for the initial key exchange which will be done using public key cryptography. And SHA is used for MAC and hashing. And also sends the encrption algo's supported by the client like DES for example.
- Compression Algorithm: this will include compression algorithms details, if used.
After the client has sent, its client-hello message, its the job of the server to send back a server-hello message. Which will contain the below information.
Server Hello message in SSL/TLS
- Version Number: Server selects an ssl version thats supported by both the server and the client, and is the highest version supported by both of them
- Random Data: the server also generates a random value using the server's date and time plus a random number of 28bytes. Client will use this random value and its own random value to generate the "master key"
- Sesssion ID: There are three possiblities, with regard to the session id. It all depends on the type of client-hello message. If the client requires to resume a previously created session, then both the client and server will use the same session ID. But, if the client is initiating a new session, the server will send a new session ID. Sometimes a null session ID is also used, where server will never support resuming the session, so no session id's are used at all.
- Cipher Suits: Similar to the version number selected by the server, the server will select the best cipher suite version supported by both of them.
Certificate:The server also sends a certificate, which is signed and verified by a Certificate Authority, along with the public key(Content encrypted with public key can only be opened with a corresponding private key. In this case, only the server can unlock it because, the server has the private key for its public key).
- A certificate signed by a certificate authority(a trusted third party), consists the complete information about the company using that certificate. The certificate identity of many well known certificate authority is made avialable to the web browser. Whenever a certificate is recieved by the client's browser, it is verified with the one it has from the certificate authority. So this proves that, that the server which claims, that it is "example.com" is infact correct.
- Server Key Exchange: this step is taken by the server, only when there is no public key shared along with the certificate. If this key is used, this will be used to encrypt the "Client Key Exchange Method"
- Client Certificate request: This is seldom used, because this is only used, when the client also needs to get authenticated, by a client certificate.
- Server Hello Done: this message from the server will tell the client, that the server has finished sending its hello message, and is waiting for a response from the client.
Response from the client to server's hello message:
- Client Certificate: The client sends a client certificate back to the server. This step is only used when a client certificate is requested by the server(through the server hello message).
- Client Key Exchange: This message is only sent, after the client calculates, the premaster secret with the help of the random values of both the server and the client(Which was shared by both the server and the client through the hello message).
"Client Key exchange" message, is sent by encrypting it with the server's public key, which was shared through the hello message. This message can only be decrypted with the server's private key. If successful, the server is authenticated.
- the client will also send the ssl protocol version once again along with the "client key exchange" method, so that the server can verify, this version with the previous one send, so as to prevent a man in the middle from changing the protocol version.
The above explained things is depicted in the below diagram.
Comments
Excellent compilation
Sarath,
Thanks for this page, very elaborate yet organized write up on the most used protocol in the field of network security!
Kudos,
Himanshu
Excellent!!
Sarath and Satish,
Thanks for this page, very elaborate yet organized write up on the most used protocol in the field of network security!
Kudos,
Himanshu
Excellent and Concise
Sarath,
Really awesome explanation with concise information about SSL handshake.Thanks!!
Regards,
Rajesh
Nice post
Thank you so much for your post. It's very great with me but I can not read article "Record Protocol in SSL". Could you please check it ?
Thank in advance!
This is a great explanation.
This is a great explanation. Thank you for the information.
Excellent
I have referred many articles , I can tell this is best one which provides a very clear and elaborate articulation of SSL handshake
excellent
Thanks for this concise and wonderful explanation about ssl handshake.
Isn't there a chance of hacking?
As the pre-master secret key is created using the random number shared by client and server in non-encrypted format, can't a hacker (who has intercepted both the random numbers) generate the same secret key using the Public Key from the certificate and the algorithm chosen?
Hacking
Good question Keyur, I was about to ask the same thing. ECDH simply says that the private key is a randomly selected number in [0,n-1], where n is the order of the elliptic curve subgroup. Here the author says that the random values calculated by both parties participate in the key generation. My question is how? I would assume an operation that involves these 2 values but this should be kept secret.
very informative, and it was
very informative, and it was very helpfull !!
Thanks much
Add new comment