握手协议（RFC 5246节选）

7.3 握手协议

会话状态的加密参数由TLS握手协议产生，该协议在TLS记录层顶端运行。当一个TLS 客户和服务器第一次开始通讯时，他们需要协议相同的版本，选择加密算法，选择是否相互认证，并且使用公钥加密技术生成共享密钥。

TLS 握手协议包含了以下步骤：

1. 交换hello消息 ，协商算法，交换随机值，核对（check for）会话的恢复（...？）

2.交换必要的加密参数允许双方协商预先的主密钥。

3. 交换证书和加密信息允许双方实现认证。

4. 从预先的主密钥中生成主密钥并交换随机值。

5. 向记录层提供安全参数。

6. 允许客户和服务器验证他们的对端已经计算出了相同的安全参数以及握手过程（尤指握手消息）没有被攻击者篡改。

注意，更高层不应过于依赖TLS是否总能在两端协商出强度最高的连接。中间人攻击有很多种方法可以使两个实体降到他们所支持的最低安全（连接）方式（？）。该协议的设计已经最下化该风险，但仍然存在可能的攻击：例如，攻击者可以阻塞安全服务的端口，或是获取同等体（冒充？）去协商一个不被认证的连接。基本规则是，更高层必须知道它们的安全需求是什么，并且从不通过低于安全需求的通道发送信息。 TLS协议是安全的所以任何加密套件都可以提供它允许的安全等级（？） 如果你与一个证书已被你验证过的主机用1024比特的RSA密钥协商，你可以认为这是安全的。

他们的目标由握手协议获取，概括的说是以下几点：客户发送一个ClientHello 消息给服务器，服务器必须回应一个ServerHello 消息，否则一个致命的错误将会发生连接同时失败。ClientHello和ServerHello 将会用来建立安全能力。 ClientHello 和 ServerHello 将确定以下属性：协议版本，会话ID，加密套件，压缩算法。 另外，两个随机值也会被生成并交换：ClientHello.random & ServerHello.random

真正的密钥交换至多使用4个消息：服务器证书，服务器密钥交换，客户证书，客户密钥交换。新的密钥交换方法将会通过指定一个这些消息的格式和定义这些消息的用法 来生成使得客户和服务器能够协商一个共享密钥。这个密钥必须相当长。现在定义的密钥交换方法中的密钥长度大于等于46字节。

跟在Hello消息之后，如果要被认证的话，服务器将会发送包含它的证书的证书消息。另外一个服务器密钥消息也会被发送（如果要求的话，例如，服务器没有证书或者它的证书只用于签名）。如果服务器被认证，它可能需要一个来自客户的证书，前提是选择的加密套件允许。下一步，服务器将会发送ServerHelloDone消息，表示握手过程中的hello阶段已经完成。 服务器将会等待客户的回复。 如果服务器已经发送CertificateRequest 消息，客户就必须发送证书消息。 客户密钥交换消息此时被发送，它的内容取决于ClientHello和ServerHello确定的公钥算法。 如果客户已经发送了带签名的证书，一个数字签名的CertificateVerify 消息将会被（明确地？）发送用以确定证书中私钥的所有权。

在此时，一个ChangeCipherSpec 消息有客户发出，客户将拷贝未决的密码规格到现有的密码规格中去，然后客户立即基于新的算法、密钥发送结束消息。在回复中，服务器将发送自己的ChangeCipherSpec（改变密码规格）消息，传递未决的到现有的密码规格中，基于新的密码规格发送它的结束消息。 此时，握手过程结束，服务器和客户开始交换应用层的数据。 应用层数据绝不可以先于第一个握手过程结束前发出。 

message flow 略。

注意：为了避免管道停止（pipeline stalls） ChangeCipherSpec 不依赖于TLS协议，它实际上不是一个TLS 握手消息。

当客户和服务器决定恢复前一个会话或复制现有的会话时，消息流（message flow 如下）：

客户发送ClientHello 使用的是即将被恢复的会话的ID。 服务器则去高速缓存中检查是否匹配。如果找到匹配的ID，并且服务器愿意在指定的会话状态下重建连接，他将发送携带相同会话ID的ServerHello。 此时，客户和服务器都必须发送ChangeCipherSpec消息 并且直接进行到发送结束消息（？）。 一旦重建完成，客户和服务器可能会开始交换应用层的数据。 如果会话ID不匹配，服务器将生成新的会话ID，然后TLS 客户和服务器将进行一次完整的握手过程。