How does ssl work? Step 2

Quick SSL Fact 2:

Man-in-the-middle attacks occur when the communication is intercepted en route. This is where an unauthorized program sends its own certificate back to the client and makes a client request to the server. Rather than the client and server validating with each other they are validating with the unauthorized program.

Using (and expecting) certificates from valid certificate authorities minimizes this risk.

SSL Performance Issues:

Latency is increased with SSL connection since as shown in these “hand shake” steps there are additional round trips added in order to establish authentication. This is only a fraction of a second for each connection so it wouldn’t be noticible on most small or medium businesses. For large business processing numerous transactions per minute this can add up, especially if “client authentication” is required.

More performance issues on next page.

 

How does ssl work?
Detailed SSL – Step 2 The SSL Hand shake
( updated 2004-01-16 )

This is page 3 of our SSL articles. You can go back to the SSL overview by clicking here.
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):

 

    1. 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.