Secure Sockets Layer version 3 (SSLv3) was introduced by Netscape CommunicationsCorporation in 1995. SSLeay implements both SSLv2 and SSLv3 and TLSv1 as of therelease of SSLeay-0.9.0. SSLv3 was designed with public review and input from industryand was published as an Internet-Draft document. After reaching a consensus of opinion toInternet standardisation, the Transport Layer Security (TLS) Working Group was formedwithin IETF in order to develop an initial version of TLS as an Internet standard. Thefirst version of TLS is very closely compatible with SSLv3. The TLSv1 protocol providescommunications privacy and data integrity between two communicating parties over theInternet. Both the SSL and TLS protocols allow client/server applications to communicatein such a way that they prevent eavesdropping, tampering or message forgery. The SSL(or TLS) protocol is composed of two layers: the SSL (or TLS) Record Protocol and theSSL (or TLS) Handshake Protocol.This article is devoted to a full discussion of the protocols of both SSLv3 and TLSv1.
e. all certificates except those containing fixed DiffieHellman parameters). When sent, it will immediately follow the client key exchange message. This message signs a hash code based on the preceding messages, and its structure is defined as follows
id: 9eb5677967eb87b943cfe02c4c2033ae - page: 7
signature.md5_hash MD5(master_secret||pad2||MD5(handshake-message|| master_secret||pad1)) Certificate.signature.sha_hash SHA(master_secret||pad2||SHA(handshake-message|| master_secret||pad1)) where pad1 and pad2 are the values defined earlier for the MAC, handshake-messages refer to all Handshake Protocol messages sent or received starting at client-hello but not including this message, and master secret is the calculated secret. If the users private key is DSS, then it is used to encrypt the SHA-1 hash. If the users private key is RSA, it is used to encrypt the concatenation of the MD5 and SHA-1 hashes.
id: 9487e386fdb14e376e8d73d7f5b4b336 - page: 7
8.1.5.4 Phase 4: End of Secure Connection At this point, a change cipher spec message is sent by the client, and the client copies the pending CipherSpec into the current CipherSpec. The client then immediately sends the finished message under the new algorithms, keys and secrets. In response, the server will send its own change cipher spec message, transfer the pending CipherSpec to the current one, and then send its finished message under the new CipherSpec. At this point, the handshake is complete and the client and server may begin to exchange application layer data (see Figure 8.5). Change cipher spec messages: The client sends a change cipher spec message and copies the pending CipherSpec in the current CipherSpec. This message is immediately sent after the certificate verify message that is used to provide explicit verification of a client certificate. It is essential that a change cipher spec message is received between the other handshake messages and the finished message. It
id: e694fbd548776071b1d0f833e8e332ad - page: 7
Finished message: This is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. The content of the finished message is the concatenation of two hash values: MD5(master_secret||pad2||MD5(handshake_messages||Sender|| master_secret||pad1)) SHA(master_secret||pad2||SHA(handshake_messages||Sender|| master_secret||pad1)) where Sender is a code that identifies that the sender is the client and handshake
id: 93a1efeb0158b6c26410c2a6bc11821e - page: 7