First, the client sends the server its SSL version number, cipher settings and a random number with a time stamp. The server then sends the client its SSL version numbers, cipher settings and randomly generated data. The server also sends its certificate and, if the client is requesting a server resource that requires client authentication, requests that the client certificate be sent back to the server.

The client then attempts to authenticate the server using information in the server's certificate. If the certificate is deemed valid or the client decides to accept the certificate regardless of the validity of the certificate (not a good idea!), the client will create the premaster secret for the session; encrypt it with the server's public key, which was obtained from the server's certificate; and send the encrypted premaster secret to the server. If the server has requested client authentication, the client computes a hash of all the SSL messages that have been exchanged, encrypts the result with its private key and sends this data along with the client's own certificate to the server.

If the server has requested client authentication, the server attempts to authenticate the client. The server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and verify its integrity. The generation of keys is aided by SSL accelerators because they perform the CPU-intensive cryptographic processing necessary to create these symmetric keys in silicon, rather than in software.

Encryption and decryption, known as bulk encryption, are also CPU-intensive and can be aided by SSL acceleration devices. But the real value of an SSL accelerator lies in its ability to perform hundreds of key signings per second, something that software simply can't do.

The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. The client then sends a separate (encrypted) message indicating that the client portion of the handshake is finished. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. The server then sends a separate (encrypted) message indicating that the server portion of the handshake is finished. Once the handshake is complete, data is transferred between the client and the server in an encrypted mode. Since private keys are never exchanged and data encrypted with the public key can be decrypted using only the matching private key pair, data is secure.