SSL handshake for multiple pages

balaji
By balaji

December 27, 2006

Your Internet Banking site is fully SSL enabled. Login-page, Account summary page and Fund transfer page are all HTTPS enabled. When you bank online - login, check your account summary and do a fund transfer, is SSL authentication and handshake happening separately for each page or is it one handshake for all the three pages?

  1. HTTP is stateless, so is SSL. Full SSL handshake needed for each HTTP page.
  2. SSL is stateful, only one full handshake for multiple HTTP pages in a session.
  3. SSL is security at IP layer. One handshake for one set of source/destination IP address.

The correct answer is (2)SSL is stateful, only one full handshake for multiple HTTP pages in a session.

Unlike HTTP where the programmer needs to write code to maintain session across pages, SSL has built-in mechanism to maintain state across multiple pages. Let us look at the SSL handshake in more detail.

When I make the first SSL connection to that site, the client completes TCP handshake with Port 443. After the TCP handshake is done SSL handshake starts. Client sends C-HELLO message which includes crypto algorithms supported, a SESSION_ID value and some random text (let's call it c-text). Since this is first SSL handshake with the site the SESSION_ID value is empty. Server sends back a S-HELLO which includes crypto-algorithms it supports and random text (let's call it s-text). Server also sends it digital certificate to client.

Client validates the certificate by checking the signing authority, expiration date and domain name. After validating the server's certificate, client generates a random MASTER_KEY, encrypts it with server's public key [obtained from the certificate] and sends it back to the server. Server decrypts MASTER_KEY using its private key. Now server and client share a common MASTER_KEY.

Next the client derives a unique CLIENT_WRITE_KEY from the MASTER_KEY [algorithm to derive this and input parameters required are known to both server and client] and encrypts s-text using this key and sends to server. Server also generates CLIENT_WRITE_KEY and verifies it by successfully decrypting message send by client. Similarly server derives a unique SERVER_WRITE_KEY [algorithm to derive this and input parameters required are known to both server and client] from the MASTER_KEY and encrypts c-text and sends back to client. Client also generates SERVER_WRITE_KEY and verifies it by successfully decrypting message send by server.

At this stage, the client and server have 3 keys - MASTER_KEY, CLIENT_WRITE_KEY and SERVER_WRITE_KEY. All data sent from client to server is encrypted using CLIENT_WRITE_KEY and all data sent from server to client is encrypted using SERVER_WRITE_KEY.

Now the handshake is over. Server assigns a SESSION_ID for this connection and sends it to the client. SESSION_ID value is stored at both the client and server.

Now secure data transfer for page-1 can begin. When we move to a new page in the same site [lets say from account_summary page to fund_transfer page], a new TCP handshake happens to Port 443. Once TCP handshake is over, SSL handshake begins. The client sends a C-HELLO which includes crypto algorithms supported, a SESSION_ID value and some random text. Unlike last time, this time the SESSION_ID field is not EMPTY but contains the currently active SESSION_ID. Server checks if the SESSION_ID is valid. Server returns S-HELLO by mentioning algorithms it supports, echoes the same SESSION_ID and some random text.

Since both client and session agree the session-id is valid and active, the certificate validation and MASTER_KEY generation steps are skipped. A new set of CLIENT-WRITE-KEY and SERVER_WRITE_KEY are regenerated. Secure data transfer for page-2 can happen with new pair of encryption keys. How long the SESSION_ID is stored in the cache can be determined by the settings on client and server. After that time the SESSION_ID is dropped and for subsequent HTTPS pages a full handshake has to happen. SSLver 3 supports the resumption of SSL sessions using session id.


Tags: Quiz

About

balaji

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset