tscape and through lots of bumpy industrial quasi-consensus and intervention by the IETF, it has become a formal standard now covered by RFC 2246 and it is known as Transport Layer Security (TLS). Its so-called record layer lies on top of reliable transport protocols such as TCP. The principles on which SSL is built have already been discussed SO nothing should be surprising. If a client device wants to establish a secure communication session with a server, three steps must be taken during the handshake phase: After the server has been authenticated, the two parties must agree on the cryptographic algorithms to be used in the session. The keys to be used by the agreed-upon algorithms must be derived and established. The handshake may optionally authenticate the client. Once the handshake phase has been successfully concluded, the data transfer phase begins. To understand the computational load needed at session setup time, let's look at the handshake process a little closer. For more details, refer to the excellent book SSL and TLS: Designing and Building Secure Systems by Eric Rescorla (Reading, Massachusetts: Addison Wesley, 2000). The client first sends a list of algorithms it can support and a random number to the server. Both parties will use this random number for subsequent calculations. 2. The server chooses the cipher it prefers from the proposed list and sends it back to the client along with a digital certificate, which contains the server's public key. Other information is also located in the certificate that the client can potentially use to further authenticate the server, if necessary. The server also sends another random number that will also be used by the parties as part of the key-generation calculations. 3. The client verifies the server's certificate and extracts the server's public key. The client will then generate a random secret string called the premaster secret. It encrypts it with the server's public key and sends it to the server. 4. From the premaster secret, the two parties will in