SSL Record Protocol

The web communication from the browser to the server goes through multiple tiers on the server, before the requested data makes it to the other side.

First, the request from the browser goes through the first tier of high level protocols, depending on what type of request the end-user is makes: HTTP (web server), IMAP, (mail server) and/or FTP

HTTP, IMAP or FTP administers the client request through the Secure Sockets Layer (SSL). If the request is for a non-secure connection it passes through to the TCP/IP layer and the server application or data.

The client can request a secure or non-secure connection, however, if it's a non-secure connection, the server may require a secure connection before any communication takes place and it may send an error message back to the client, or it may deny the non-secure connection.

If the client requests a secure connection, the SSL protocol commences with a handshake to start the secure communication between the two endpoints.

SSL Handshake Protocol
Just like a handshake between two people, the "handshake" between the server and client matches them and lets them exchange both with encryption methods and keys for the communication.

These encryption methods, or ciphers-a procedure of algorithm for performing encryption and decryption -are implemented during the SSL process to ensure that the data is truly safe and not readable by anyone who might intercept the communication.

• DES - Digital Encryption Standard
• DSA - Digital Signature Algorithm
• KEA - Key Exchange Algorithm
• MD5 - Message Digest algorithm
• RC2 - Rivest encryption cipher-128 bit encryption
• RC4 - Rivest encryption cipher-128 bit encryption
• SHA-1 - Secure Hash Algorithm
• Triple DES - DES used 3 times
• Others

128-bit encryption is the standard with most SSL certificates, as they are not easily hacked.

As well, this is the point where server and client authentication (if required by the server) is determined.

Briefly, here is what takes place during the handshake process:

1. Web Browser - Sends server the encryption type, data used in scrambling routines and other SSL data.
2. Server - Sends the browser its encryption data, other SSL data, and its certificate- a data string called a public key.
   
   
3. Web Browser - Matches the data it receives with the domain that the end-user was trying to reach, making sure it is secure. If the web site's certificate does not match the domain name, the browser displays an error message to the end-user/client. The certificate expiration date and valid certificate authority are also checked at this point.
   
   
4. Key creation - The web browser creates a random key that it encrypts, based on the selected encryption method, and it is combined with the server's public key from step 2. The browser sends the key back to the server.
   
   
5. Session Keys - The browser and the server create a data string and both use it to create session keys- keys used for encrypting one message or an entire communications session - that both server and browser encryption programs use to encrypt and decrypt all communications, and verify that the data didn't change in transmission for the rest of the session.
   
   
6. Web Browser - The browser receives the information to launch a secure communication and sends a message to the server, confirming the use of the new session key. As well, the browser sends a message to the server that its part in securing the session is complete.
   
   
7. Server - Responds by sending a message back to the browser that it will use the new session key also. As well, the server sends a message to the browser that its part in securing the session is complete. Simply, SSL works via a secure server, and communicates with a user's web browser, when someone logs into the secure server.
   
   

Let's take a look at a simple scenario of the record and handshake protocols.

For example, in order to balance your checkbook, you need to login to your bank's Web site, and view your account details.

Once you enter your User ID and Password, the secure server communicates with your browser, and vice versa, sending encryption information and a session key that is exclusive to your browser and the secure server.

The following example displays what the end-user sees during the handshake protocol.



While waiting for validation, so many things are going on in the background. Once you enter a URL, SSL makes the URL begin with https, instead of http.

From there, it works with the previous handshake steps:

• Certificate - The server sends a certificate to the browser.
  
  
• Validation - Browser verifies the digital signature and ensures that the name on the SSL certificate is correct, the expiration date of the certificate, and that it was issued and signed by a certificate authority (CA).
  
  
• Encryption - Browser creates data for cryptographic key, encrypts it using the public key on the server's certificate, and sends it to the server.
  
  
• Security Keys - Browser and server generate keys and encrypt all session traffic from that point forward.

Once an initial SSL session is established between the two endpoints, the information gathered from each endpoint and any applications can be cached in secure memory.

In the bank example, that means the next time there is a login, if the end-user has saved his/her login information, or any other settings used in the initial or previous SSL session, that information is already secure and ready to go.

This can speed up the SSL process-handshakes, etc.-for subsequent SSL sessions. The two endpoints use an abbreviated handshake to authenticate that each party has access to the information, without the use of public or private keys. If each endpoint can prove that they have permission to access the information, then new keys are established and the SSL session continues.

Viewing the authenticated page, it looks like a normal Web page, however the information is totally encrypted.

The yellow browser address window and the little lock at the top and the bottom of the page have continued to be the standard that end-users look for, in order to know that it's a 'safe' site or safe page.

If a site has "https" instead of "http," it is supposedly secure and it is truly the company's Web site. The lock means that the information sent or received is secure and encrypted.

Any information all info coming into the secure server from the user to the secure server, or going out from the secure server to the user, is encrypted.

Having SSL encryption-128 bit encryption is best-is the first step in making it hard for any phisher or third-party attacker to view, hack and decipher sensitive information like passwords, account numbers, or any other information transferred during this SSL session.

At the same time, connections like an SSL protocol only protect the information coming and going from the user to the server or vice versa. It doesn't protect information when it is just sitting on the server.

SSL is good, but in 2007, with several phishing scams that wreaked so much havoc since the mid 1990's and have continued until now, good is not good enough.

                    

Print this page