具有扩展主密钥时SSL/TLS的主密钥计算

简介

最近在基于openssl1.0.2t源码做开发，解密TLS1.2数据包，出现部分数据包解密失败的问题，通过定位发现，不同的HTTPS服务器，在客户端与服务端协商时部分扩展字段有差异，导致计算密钥失败或错误，其中关于“Extended Master Secret Extension”，如果协商时具有此扩展字段，计算主密钥的方式会有所差异，具体对此字段的解释，详见RFC7627

TLS密钥计算流程

无“Extended Master Secret”

在TLS中，每个会话都有一个“master_secret”，其计算方式如下：

 master_secret = PRF（pre_master_secret，“主密码”，
                       ClientHello.random + ServerHello.random）
                       [0..47];

其中“pre_master_secret”是某些密钥交换的结果协议。例如，当握手使用RSA密码套件时，该值是由客户端均匀随机生成的。

具有“Extended Master Secret”

全面协商扩展主密钥后，握手时，“master_secret”的计算公式为：

 master_secret = PRF（pre_master_secret，“扩展的主密钥”，
                       session_hash）
                       [0..47];

其中的session_hash的定义如下：

session_hash = 哈希（handshake_messages）

其中“handshake_messages”是指所有已发送的握手消息，或者从ClientHello开始，直至并包ClientKeyExchange消息，包括以下内容的类型和长度字段握手消息。

三重握手

三重握手(Triple Handshake) (CVE-2014-1295)：攻击者（A）分别与客户端（C）和服务器（S）握手，协商出同一个主密钥；之后令客户端（C）和服务器（S）之间重新协商（renegotiation）或继续（resumption）会话来握手。可攻破重新协商，TLS Exporter RFC5705和"tls-unique" RFC5929。

具体握手过程

C：客户端。 A： 攻击者 S：服务端

1. C向A发送“ ClientHello”，A将其转发给S。

2. S向A发送“ ServerHello”，A将其转发给C。

3. S将包含其证书链的“证书”发送给A。
   A用自己的证书链替换它，并将其发送给C。

4. S向A发送“ ServerHelloDone”，A将其转发给C。

5. C向A发送“ ClientKeyExchange”，其中包含
   “ pre_master_secret”，已使用A的公钥加密。解密
   “ pre_master_secret”，使用S的公钥对其重新加密，并且
   将其发送给S。

6. C向A发送“完成”。A计算其“完成”
   与S连接并将其发送给S。

7. S向A发送“完成”。A计算其“完成”
   与C的连接，并将其发送给C。

通过以上方式，如果使用无“Extended Master Secret”扩展字段的计算方式将发现，从C->A和从A->S之间使用的会话密钥是一样的，这种叫做未知密钥共享（unkown key-share（UKS））攻击。当使用

 master_secret = PRF（pre_master_secret，“扩展的主密钥”，
                       session_hash）
                       [0..47];

的计算方式时，因为有session_hash，计算了所有协商消息的hash，如果中间攻击者A对协商消息进行改动，则客户端和服务端计算的hash值则不一样，最后计算出的主密钥也会不同。

参考资料

https://tools.ietf.org/html/rfc7627
https://forum.nginx.org/read.php?2,272703,272704