问服务器是否完成了TLS服务器的签名？

EN

我认为最好概括为：

完成消息是用会话密钥加密的。

或

包含握手记录上的HMAC的Finish消息是用会话密钥加密的。

正如@dave_thompson在评论中指出的那样，这实质上等同于对记录进行签名(尽管Finish消息本身没有签名)。

下面是我对TLS Finish消息的理解(@Steffen，@forest，@dave_thompson，请随时纠正我的理解)。

TLS 1.2 (RFC 5246)

7.4.9完成节给出了以下内容：

此消息的含义:已完成的消息是第一条受刚刚协商好的算法、密钥和秘密保护的消息。已完成邮件的收件人必须验证内容是否正确。一旦一方发送了其已完成的消息，并从其对等方接收并验证了已完成的消息，它就可以开始通过连接发送和接收应用程序数据。结构: struct {

      opaque verify_data[verify_data_length];
  } Finished;

verify_data

     PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

finished_label

     For Finished messages sent by the client, the string
     "client finished".  For Finished messages sent by the server,
     the string "server finished".

哈希表示握手消息的哈希。..。handshake_messages

     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

我的理解是，以前所有握手消息的散列都用作伪随机函数(PRF)的种子，用于生成12个或更多(取决于密码套件)的psuedo随机八进制，然后使用刚刚在握手中同意的AES会话密钥加密。

因此，我要说的是，“服务器看到的整个握手的哈希是在第一个加密消息中发送的，而另一方必须验证它是否与客户机看到的整个握手的哈希匹配”。(我知道这比“服务器签署完成消息”更像是一口，但你能做些什么)。

TLS 1.3 (RFC 8446)

第4.4.4节类似于RFC 5246's节7.4.9，但它说明了0-RTT模式，他们已经使用协商密钥将PRF改为HMAC。核心思想是相同的: Finish消息包括整个握手的散列，并且使用协商的会话密钥对其进行加密。

TLS服务器完成的消息使用握手前生成的共享密钥加密。

编辑:为了进一步清楚起见，客户机(在服务器完成消息之前)发送一个随机字节字符串，客户机和服务器都使用该字符串来计算共享密钥。随机字节字符串本身是用服务器的公钥加密的(这意味着服务器只有在拥有服务器的私钥时才能计算共享密钥)。公开密钥先前以类似的随机字节字符串方式被验证为属于服务器。

编辑2:针对目前根据Qualys实验室1/31/2019提供的协议支持的进一步评论：

此外，随机字节字符串仍用作键控材料(用于生成短暂密钥的非per )、服务器Hello和客户端Hello的一部分( RFC 8446 )。

最后，这个答案不包括对短暂密钥的讨论(使用RSA交换密钥，我们使用密钥交换密钥，然后将随机值纳塞输入到用于tls 1.3的HKDF或tls 1.2的PRF )...I希望所有这些编辑都能说明为什么我最初的答案是故意简短和精确的.如果您想深入实现的深度，请阅读RFC！如果你想得到一个简单的答案，你就会来到这样的地方。如果你想要一个蒸馏，但密码精确的答案去密码堆栈交换。

这个答案现在是令人憎恶的。