TLS序列号

Question

在使用Wireshark查看TLS 1.2流量时，我发现在应用程序数据记录中，某些连接中的64位序列号是发送的，而另一些则不是。这取决于密码套件吗？

Answer 1

要获得确切的答案，请参考标准。

对于一个简短的摘要:序列号是隐式的，不被传输。发送方和接收方都会跟踪他们发送和接收的记录的数量，所以他们不需要在记录本身中重复它(如果它在那里，那么他们将不得不验证它，因为序列号的要点是检测重复的记录、删除的记录和无序的记录)。

但是，TLS 1.1和1.2记录具有显式IV，对于需要它们的分组密码模式(在SSL3.0和TLS1.0中，用于记录的IV是上一条记录的最后一个加密块的副本，它允许使用选择-明文攻击，在TLS的情况下以“them”的名称推广)。对于授权CBC加密模式的密码套件，IV应该是随机生成的，从您的wireshark眼中，这些IV将显示为“随机”。然而，TLS1.2也支持艾亚德加密模式，这是一种高级分组密码模式，它不仅将加密和MAC结合在一起(而基于CBC的密码套件需要额外的HMAC来实现完整性)，而且对它们的IV也不那么挑剔。

特别考虑在GCM中指定的RFC 5288密码套件。GCM需要一个12字节的IV，它不需要是随机的；唯一的限制是，对于给定的对称密钥，不止一个记录不能使用任何IV值。当在TLS中使用GCM时，IV的前4个字节被计算为握手密钥推导的一部分，并且给定连接中的所有记录对这四个字节使用相同的值；其余的8个字节与记录本身一起传输，并由发送方来确保在特定连接中不重用8字节值。正如RFC 5288所说：

每个不同的nonce_explicit值必须是不同的。

invocation of the GCM encrypt function for any fixed key.  Failure to
meet this uniqueness requirement can significantly degrade security.
The nonce_explicit MAY be the 64-bit sequence number.

特别是最后一句:使用计数器很好，记录序列号就是这样一个计数器。这就是您所观察到的:您正在研究的特定TLS实现似乎使用序列号的副本，作为每个记录的IV的一部分。这是允许的，而且很好(重复一遍:这对于GCM密码套件来说很好；对于CBC密码套件来说，这是弱的)。

但是，请注意细节:对此字段使用序列号并不是强制性的；实际上，使用计数器并不是强制性的。TLS记录的接收端不能假定nonce_explicit字段将等于序列号；相反，它必须使用接收到的字段值。此外，发送方和接收方仍然必须跟踪序列号，因为序列号是AEAD计算中“认证数据”的一部分。使用序列号作为nonce_explicit是非常方便和明智的，RFC 5288预见到了这个问题，并明确表示它是好的。

(如果TLS标准规定GCM的IV是序列号，而根本不需要将其发送到线路上，那么TLS的标准就会稍微简单一些；但RFC 5246试图成为通用的，以适应未来可能对IV有其他要求的其他AEAD模式)。

为了有效地研究这些细节，一个好的策略是实现您自己的SSL/TLS库--不是用于生产，而是为了教学价值。当客户端(分别为服务器)代码成功地与现有服务器(分别为客户端)实现交谈时，您将学到很多东西。我甚至会从经验中断言，没有更好的方法来学习TLS。

Answer 2

是的，序列号的可见性取决于密码套件:在AEAD密码中，序列号包括在附加数据中(RFC5246，6.2.3.3)：

additional_data = seq_num + TLSCompressed.type +
                            TLSCompressed.version + 
                            TLSCompressed.length;

其他数据是经过身份验证的，但没有加密。因此，您可以使用Wireshark查看它的内容。

在TLS 1.2支持的其他密码中，即流密码和CBC分组密码模式中，序列号在MAC中隐式(RFC5246，6.2.3.1)：

MAC = HMAC(MAC_write_key, seq_num +
                          TLSCompressed.type +
                          TLSCompressed.version +
                          TLSCompressed.length +
                          TLSCompressed.fragment);

因此在那里是看不见的。