The purpose of the SSL Handshake is a multifaceted one. It involves server (and optionally client) authentication, determining what cryptographic algorithms are to be used, and the generating of a secret key by which all future SSL Data Exchanges are to be encrypted by. The steps by which this is accomplished are as follows:
Client Hello
The main purpose of the client hello is to inform the server of what cryptographic algorithms the client can support and to ask for verification of the server's identity.
The client sends to the server three things:
· Set of supported cryptographic protocols.
· Compression algorithms.
· Random number.
The purpose of the random numbers is if the server does not have a Digital ID, a secure connection can still be made using a different set of algorithms(like Diffie-Hellman), although it is impossible to verify their identity.
Within the set of cryptographic protocols there is the Key Exchange protocol (how we are going to exchange the information), the secret Key algorithms (what encryption methods can we use), and a one-way hash algorithm. No secret information is passed at this point, just a list of choices
Server Hello
The server responds by sending the client it's Digital ID (which includes it's public key), the set of determined cryptographic and compression algorithms, and another random number. The decision as to which cryptographic algorithms are to be used is based on which ever are the strongest that both the client and server support. In some situations, the server may also ask the client to identify themselves as well (by requesting a Digital ID).
Client Approval
This step involves the clients browser checking the validity of the Digital ID sent by the server. This is first done by decrypting the Digital ID using the Public key of the certificate's issuer and determining that the certificate comes from a trusted certificate authority. After it has been decrypted, a series of validity checks occur. This includes checking validity dates and making sure that web page URL matches the one listed in the certificate.
Once the server's identity has been verified, the client randomly generates the secret key and encrypts it using the server's public key (Server has sent this to Client in first step) and the previously determined cryptographic and compression algorithms. The client then sends the encrypted secret key to the server.
Verification
At this point both parties know the secret key. The client knows the secret key because the client generated it, and the only other person who knows it is the server, because a message encrypted with the server's public key can only be decrypted by the server's private key. A final check is done to ensure that the previous transfers have not been tampered with. both parties send a copy of all the previous transactions encrypted with the secret-key. If both parties confirm the validity of the transactions, the handshake is completed. Otherwise the handshake process is re-initiated.
Both parties are now ready to communicate securely using the agreed upon secret-key and cryptographic/compression algorithms. The SSL handshake is only done once and the secret-key is used for only one session.
Graphical Representation of Steps
No comments:
Post a Comment