December 2006
SSL handshake for multiple pages
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?
- HTTP is stateless, so is SSL. Full SSL handshake needed for each HTTP page.
- SSL is stateful, only one full handshake for multiple HTTP pages in a session.
- 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.