传输层安全协议Version1.2（RFC 5246节选）

RFC5246 RFC5246英语原文

7.4.3 服务器密钥交换消息

消息发送：如果需要发送，该消息将在服务器证书信息（或者匿名协商中的服务器hello消息）之后被立即发送。

服务器密钥交换消息只在一种情况下被服务器发送，即服务器证书消息没有包含足够的数据让客户能够交换预先的主密钥。以下几种算法允许该消息的发送：

DHE_DSS, DHE_RSA, DH_anon； 以下几种算法中该消息的发动是非法的：

RAS, DH_DSS, DH_RSA.

另外一些算法 (在TLSECC中定义)必须单独指出服务器密钥交换消息是否允许被发送。

该消息的含义：该消息传送了加密信息使得用户能够交换预先的主密钥（）

消息的结构：略，见原文。

如果客户已经提供了一个签名算法的扩展，签名算法必须和哈希算法成对列在扩展消息中。注意这里可能出现前后矛盾。举个例子，客户可能提供了DHE_DSS密钥交换算法，但是忽略了所有来自签名算法扩展消息总的 DSA对，为了正确的协商，服务器端必须在选择之前核对所有候选客户的加密套件组。这种方法或许有些不够“优雅” （...水平有限，翻译很渣）但是确为一个折中的方案可以最小化原始加密套件的变化（？）

另外，签名加密算法和哈希算法必须对服务器终端实体的证书密钥兼容。RSA密钥可以与任何允许的哈希算法配套使用，受制于证书中的一些限制（如果有的话）。

因为DSA签名不包含哈希算法的任何安全特征，如果多种哈希算法被用在任何一个密钥上，哈希替换将会由很大的风险。现在，DSA(DSS) 只可以和SHA-1 一起使用。 未来 DSS[DSS-3] 的调整可能会允许其他消息摘要算法于DSA一起使用，也可能允许指导（guidance）针对不同的密钥大小使用哪一种摘要算法。另外，未来 PKIX 的调整会特别指出应用于证书的具体机制从而指明使用哪一种摘要算法。

作为包含了新的密钥交换算法，为了传输层安全而定义的，额外补充的加密套件组，服务器密钥交换消息只在一种情况下发送，即与密钥交换算法相关联的证书没有提供足够的信息让客户交换预先的主密钥。（上文有提及）

8.加密计算

为了开始连接保护，TLS记录协议提供了算法套件、一个主密钥，以及客户、服务器的随机值的规范。认证、加密以及消息认证码（MAC）算法由被服务器选择的加密套件所决定，并在服务器hello消息中显示。 压缩算法在hello消息中协商。剩余的部分用来计算主密钥。

8.1 计算主密钥

对于所有密钥交换消息，采用相同的算法用来将预先主密钥转换为主密钥。主密钥一旦计算得出，预先的主密钥将从内存中删除。

主密钥：master——secret = PRF(pre_master_secret，“master_secret”,ClientHello.random+ServerHello.random) [0..47];

主密钥长度为48字节，预先的主密钥根据密钥交换算法而改变长度。

8.1.1 RSA

当RSA用来服务器认证和密钥交换时，客户端将生成一个48字节的预先主密钥，并用服务器的公钥加密，然后发送给服务器。服务器用自己的私钥解密。双方各自采用上述方法转换的到主密钥。

8.1.2 Deffie -Hellman

采用常规的Deffie-Hellman 计算方法。协商出来的密钥记做Z，它被当做预先的主密钥，并转换为主密钥。Z的前端都是0比特位，在转换前被剥离。

注意：Deffie-Hellman 的参数由服务器指定，且有可能是非永久的或包含在服务器的证书里。