ssl 握手过程【收藏】
收藏几篇关于ssl handshake的好文
http://www.slashroot.in/comment/1242
SSL protocol, does its fantastic job of securing communication over the wire, with the help of multiple layers of protocols, above TCP(And After Application Layer).
Always keep in mind that, although HTTP protocol is the protocol, which highly makes use of SSL, to secure communication. SSL is an application layer independent protocol.So you can use that with any application layer Protocol.
There are different versions and types of encryption and authentication algorithms out there. SSL can make use of, most of them out there. But a major point to note here is that, both the server and client must first agree on the same algorithm, that they are going to use in their communication.
As the client is the first person to begin the communication, the first step that the client does is to tell server, about the cipher suits and MAC(Message Authentication code, this is made in record Layer.Read Record Layer Protocol in SSL) hash algorithm's it supports.
This is done by sending a CLIENT-HELLO message. The client's Hello message consists of the following contents.
SSL version that the client supports
In what order the client prefer the versions
The ciphersuits(Cryptographic Algo's) supported by the client
Compression methods supported if any
Random Number
Keep in mind that, during the SSL initial handshake, nothing is encrypted. So anybody can sniff, and see whats going on. Encryption, starts only after the master secret(which will be used to encrypt and decrypt data as well as MAC calculation) is send by the client
Client Hello message content in SSL/TLS
SSL VERSION NUMBER : the client sends a list of ssl version it supports. And priority is given to the highest version it supports
Random Data Number : Its made up of 32 bytes. 4 byte number made up from client's date & time plus 28 byte randomly generated number(this will be used with server's random value made of date & time for generating the "master secret", from which encryption key will be derived).
SESSION ID: In order to enable client's resuming capabilities this session ID is included.
CIPHER SUITS: RSA algorithm is used for the initial key exchange which will be done using public key cryptography. And SHA is used for MAC and hashing. And also sends the encrption algo's supported by the client like DES for example.
Compression Algorithm: this will include compression algorithms details, if used.
After the client has sent, its client-hello message, its the job of the server to send back a server-hello message. Which will contain the below information.
Server Hello message in SSL/TLS
Version Number: Server selects an ssl version thats supported by both the server and the client, and is the highest version supported by both of them
Random Data: the server also generates a random value using the server's date and time plus a random number of 28bytes. Client will use this random value and its own random value to generate the "master key"
Sesssion ID: There are three possiblities, with regard to the session id. It all depends on the type of client-hello message. If the client requires to resume a previously created session, then both the client and server will use the same session ID. But, if the client is initiating a new session, the server will send a new session ID. Sometimes a null session ID is also used, where server will never support resuming the session, so no session id's are used at all.
Cipher Suits: Similar to the version number selected by the server, the server will select the best cipher suite version supported by both of them.
Certificate:The server also sends a certificate, which is signed and verified by a Certificate Authority, along with the public key(Content encrypted with public key can only be opened with a corresponding private key. In this case, only the server can unlock it because, the server has the private key for its public key).
A certificate signed by a certificate authority(a trusted third party), consists the complete information about the company using that certificate. The certificate identity of many well known certificate authority is made avialable to the web browser. Whenever a certificate is recieved by the client's browser, it is verified with the one it has from the certificate authority. So this proves that, that the server which claims, that it is "example.com" is infact correct.
Server Key Exchange: this step is taken by the server, only when there is no public key shared along with the certificate. If this key is used, this will be used to encrypt the "Client Key Exchange Method"
Client Certificate request: This is seldom used, because this is only used, when the client also needs to get authenticated, by a client certificate.
Server Hello Done: this message from the server will tell the client, that the server has finished sending its hello message, and is waiting for a response from the client.
Response from the client to server's hello message:
Client Certificate: The client sends a client certificate back to the server. This step is only used when a client certificate is requested by the server(through the server hello message).
Client Key Exchange: This message is only sent, after the client calculates, the premaster secret with the help of the random values of both the server and the client(Which was shared by both the server and the client through the hello message).
"Client Key exchange" message, is sent by encrypting it with the server's public key, which was shared through the hello message. This message can only be decrypted with the server's private key. If successful, the server is authenticated.
the client will also send the ssl protocol version once again along with the "client key exchange" method, so that the server can verify, this version with the previous one send, so as to prevent a man in the middle from changing the protocol version.
