Kbase P90483: SSL 3.0 Handshake and Connection Routine
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/12/2004 |
|
Status: Unverified
GOAL:
SSL 3.0 Handshake and Connection Routine
FIX:
There are two subprotocols in the SSL suite. These are the handshake protocol (SSL Handshake Protocol or SSLHP) and the record protocol (SSL Record Protocol or SSLRP). SSLRP defines the message formats for exchanging data and performs the job of packaging data and applying a MAC (message authentication code). SSLHP defines the dynamic exchange of messages between client and server. During the handshake, the server is authenticated to the client, a cryptographic algorithm is selected, the client is optionally authenticated to the server, shared session keys are generated, and an encrypted SSL connection is established.
The handshake starts when a client connects with a server.
The server?s certificate and public key are used for the initial authentication. After authentication, a symmetric one-time session key is created that both client and server will use to encrypt all subsequent data. Symmetric algorithms are used because their encryption/decryption performance is much faster than public/private-key encryption.
These steps assume only the client needs to authenticate the server. If the server also needs to authenticate the client, the client must have a certificate and send it to the server in step 5.
1. Client: ?Hello server. I want to use SSL. Here?s my SSL version number, some randomly generated data, my cipher settings, and some other useful information.?
2. Server: ?Hello client. Here?s my certificate, SSL version number, some randomly generated data, my cipher settings, and some other useful information. By the way, do you have a certificate??
3. The client authenticates the server by validating the certificate. The steps to validating a certificate are outlined under the topic ?Certificates and Certification Systems.? See the section ?Validating a Certificate.?
4. The client and server are ready to establish a secret session key. The client generates what is called a ?premaster secret,? then encrypts it with the server?s public key and sends it to the server.
5. The server uses its private key to decrypt the premaster secret it received from the client. Now, both the client and the server follow the same steps to create a master secret from the premaster.
6. Both the client and server send a ?finished? message to one another to indicate that the negotiation is complete. To create the message, the master key is combined with all the previously sent messages and hashed. If both parties can verify the ?finished? messages received from the other, then an SSL connection is established and all subsequent data is securely transmitted using session keys derived from the master key.