目的

为能够透彻理解HTTPS报文交互过程，做此笔记。

本文大部分内容来自 ： http://albertx.mx/blog/https-handshake/

http://www.cnblogs.com/svan/p/5090201.html

TLS Handshake Protocol

The TLS Handshake its like a sub-protocol of the TLS protocol. Its purpose is to define the algorithms and keys to authenticate the parties, verify and encrypt the data.

一次完整的http交互如下：

client hello -- 客户端向服务器打招呼 （带着 支持的 ciper suites）

server hello -- 服务器响应客户端 （告诉客户端， 我选择了哪一个 ciper suite）

Certificate Server hello done -- 服务器向客户端送证书（表明自己的身份）

Client Key Exchange， change ciper spec， encrypted handshake message -- 客户端发送密钥，  告诉服务器开始传送密文数据了， 传送一个加密的握手数据

New Session Ticket， change ciper spec， encrypted handshake message -- 服务器建立会话凭据， 告诉客户端开始传送密文数据了，传送一个加密的握手数据。

流程如下：

http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847

  Client                                               ServerClientHello                  -------->ServerHelloCertificate*ServerKeyExchange*CertificateRequest*<--------      ServerHelloDoneCertificate*ClientKeyExchangeCertificateVerify*[ChangeCipherSpec]Finished                     -------->[ChangeCipherSpec]<--------             FinishedApplication Data             <------->     Application Data

Client Hello

• The version of SSL that the client is trying to use for negotiating with the server
• Some random bytes generated by the client that will be used next to generate a master key for encryption.
• A list of encryption algorithms called cipher_suites. The client tells the server which cipher suites it understands.

主要传送 客户端支持的 加密算法列表：

Cipher Suites

包括四个部分：

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

DHE -- 密码交换加密算法

RSA -- 认证算法

AES_256_CBC -- 数据交换加密算法

SHA -- 数据完整性算法

Now, let me talk about the cipher suites listed above. If you review the image posted in the client hello section you will see a list. This list indicates the algorithms that will be used during the handshake and data transmission. The protocol needs 4 algorithms to work:

• Authentication algorithm
• Key Exchange algorithm
• Bulk cipher algorithm
• Message Authentication algorithm

These 4 algorithms are specified in the cipher suite.
Analyzing the first suite in the list we have the text: TLS_DHE_RSA_WITH_AES_256_CBC_SHA.

• TLS: This is Transport Layer Security, the protocol we are using in the negotiation
• DHE: Denotes Ephemeral Diffie-Hellman. Diffie-Hellman is an algorithm for key exchanging cryptographic keys. Diffie-Hellman in ephemeral mode enhances its security
• RSA: This is the algorithm used for authentication. The most used algorithm in public-key cryptography (Rivest, Shamir and Adleman)
• WITH_AES_256_CBC: Advanced Encryption Standard is one of the best algorithms used in symmetric cryptography. Its key size can be of 128 bits, 192 bits or 256 bits. In this case the key size is 256 bits. CBC stands for Cipher-block Chaining one mode of operation in encryption. It means that the algorithm will encrypt the bytes of data by blocks and then it will link the encrypted blocks like a chain.
• SHA: Secure Hash Algorithm will be used for message authentication creating a hash of each block of the message to verify the integrity of such message.

Server Hello

• Some random bytes now generated by the server that will be used to generate a master key.
• The cipher suite selected by the server (from the previous list sent by the client) that will be used for authentication, encryption and verification of the messages

告诉客户端，我选择的算法。

Certificate

The Certificate command is usually sent again from server to client. In this command the information transmitted is the list of certificates that the client needs to have in order to authenticate the server and to encrypt some information. This can be one, two or more certificates.

证书用于认证服务器端的身份，防止被钓鱼等攻击。 其中也包括 服务器端的 公钥， 用于加密数据。

证书 可以是多个， 呈现链式法则。

Server Hello Done

Immediately after the Certificate message the server sends the Server Hello Done message. At this point the client has all the information it needs to generate the key material that both parties will need to encrypt the data. This key material is sent in the next handshake message…

服务器端，告诉客户端， 你已经具备产生密钥的条件， 快生成吧。

Client Key Exchange

The client generates some bytes of data, encrypt them with the public key of the certificate it received and then sends the encrypted data to the server (this is called PreMaster secret and will be used to generate the Master secret). The algorithm by which the client protects the data is defined during the Client Hello and Server Hello messages. It can be RSA or Diffie-Hellman.

客户端生成  一串随机的byte（PreMaster secret）， 使用公钥加密后，传给服务器。 加密的算法hello过程已经确定。

关于master secret 生成， 见如下文章介绍（在第五点告诉你 master secret产生）：

http://www.cnblogs.com/svan/p/5090201.html

使用RSA算法的SSL握手过程是这样的

Source: Keyless SSL: The Nitty Gritty Technical Details

1. [明文] 客户端发送随机数client_random和支持的加密方式列表
2. [明文] 服务器返回随机数server_random，选择的加密方式和服务器证书链
3. [RSA] 客户端验证服务器证书，使用证书中的公钥加密premaster secret发送给服务端
4. 服务端使用私钥解密premaster secret
5. 两端分别通过client_random，server_random和premaster secret生成master secret，用于对称加密后续通信内容

master secret是如何计算的

  master_secret = PRF(pre_master_secret, "master secret",ClientHello.random + ServerHello.random)[0..47];

Change Cipher Spec

This is also sent from client to server indicating that the server MUST be prepared to receive the data in encrypted format and not in readable format because all the previous messages exchanged between client and server had been readable. This is the last message sent from client to server as readable. After this all the data sent to the server will be encrypted and we will not be able to read the contents with wireshark or any other sniffer tool. Proof of this is that in the below image the message after the Change Cipher Spec is an Encrypted Handshake Message.

客户端告诉服务器， 下一个报文开始传送 密文 了噢。

Finished

This is the first message protected by the algorithms and keys negotiated between the entities (this is the Encrypted Handshake Messsage we saw in the image). Both client and server send the Finished message but the first to do it is the client. If the server receives the message and could decrypt and understand it, it means the the server is reading the encrypted information in the right way. Now the only missing part is that client could decrypt the information sent by the server. To do that the server must send a Change Cipher Spec message too followed by the Finished message in the encrypted way. Exactly the same as client did. Again if the client could decrypt the Finished message it means that both parties are in frequency and they can talk to each other protecting all the data in transit.

客户端先想服务器端， 发送一个加密的报文， 如果服务器能够解密，并理解无误（客户端加密的内容， 是之前明文报文的一个摘要， 服务器端解密后， 计算其受到报文的摘要，并跟解密的摘要比较， 如果相等，则服务器接受客户端数据通道无误。）

然后服务器端，也一致， 需要按照客户端的做法， 先发送一个 change ciper spec消息， 告诉客户端要发送 密文了准备接受哦，

然后发送一个验证性通道畅通的加密报文， 客户端解密OK， 并可以理解（同上）， 则两端握手成功。

开始传送应用数据。