The handshake is the most complicated phase in the process and though our example specifically uses HTTPS (web based security) the same items apply to other protocols.
The "handshake" syncs the server and the client up with the encryption methods and keys that will be used for the remainder of the communications. This is also where the server authentication is determined (and client authentication if required by the server).
Typically it is enough to know that server and client establish a secure connection but the following is a summary of what happens (again, using https and "web browser" as an example):
-
The customer's web browser sends the web site server it's methods of encrypting data. This includes the encryption type, some random data that the encryption programs on both sides can use in the scrambling routines, and other ssl related data.
-
The server returns it's own random data to be used for encryption as well as other secure sockets layer information (including it's ssl certificate with a long string of characters called a public key) that the browser will need in step 4 (step 1 on next page).
-
The customer's browser checks the information it recieved and compares it to the domain it was trying to connect securely with. If the secure certificate information on the web site doesn't match the domain name the browser will notify the customer that there is a problem. The certificate expiration date and valid certificate authority are also checked at this point.
Validating the Certificate Authority is important to prevent "man in the middle" attacks (see left side panel). The CA assures that the certificate was generated by an acceptable entity.
