Secure Sockets Layer

Notes:

This slide provides an overview of an SSL session (PCT is nearly identical, it simply provides choices of authentication algorithms separate from encryption algorithms).
The client makes the first connection and informs the server what encryption methods it supports, note that “None” is a valid choice, so if the client and server can’t agree on a protocol they could theoretically end up negotiating a connection where no is encryption is present, authentication would still be applied.
The server responds by sending back its certificate and informing the client what encryption scheme it would like to use. It could also ask for the client’s certificate at this point (usually called a Digital-id), although client side certificates are not yet widespread.
The client now validates the certificate, checking that server it’s talking to against the one the certificate is registered to. It should also check expiry dates, certificate revocation lists etc at this point.
If the client considers the certificate valid it then generates a session key to use using the encryption scheme suggested by the server - this key is encrypted with the server’s public key before being transmitted. At this point if the client had a certificate it would send it back.
The server receives the session key and a client certificate if one has been sent. The server can also at this point validate the client certificate and decide whether it wishes to continue the connection.
Both parties now have the session key and use it to encrypt data flowing between them. The session key is changed frequently (whenever you start a new SSL session and there is also provision to change it mid-session) to avoid the session being broken - (e.g. through RC4’s vulnerability to encrypting different known plaintext values using the same session key).