TLS握手时断开

前言

TSL握手需要几个阶段，一般是需要发送证书，并且根据不同的环境来用不同的算法计算公钥和私钥，比较复杂，初学者一般很难理解。本文是国外网站上一个问题的解释，希望对大家有用。

提问

I am trying to debug a TLS handshake between two SIP trunk endpoints: .75 and .82. Mutual authentication is being used.我正在尝试调试两个SIP干线端点之间的TLS握手：.75和.82。正在使用相互认证。

.75 sends:

Client Hello

Certificate, Client Key Exchange

Certificate Verify, Change Cipher Spec, Encrypted Handshake Message

Encrypted Alert

.82 sends:

Server Hello, Certificate, Certificate Request, Server Hello Done

Change Cipher Spec, Encrypted Handshake Message

[FIN, ACK]

From the wireshark trace on .75, the details of the Encrypted Alert is: Content Type: Alert (21)

How do I know what causes the failure from 82?从.75上的wireshark跟踪，加密警报的详细信息是： Content Type: Alert (21)

我怎么知道导致82失败的原因是什么？

回答

Your .75 machine (the client) sends an "encrypted alert" message. If it does that, then this machine, at that point, believes that the connection is still up and running, and the server will be able to receive the alert message, and in particular decrypt it. Otherwise, what would be the point of sending that message ? Therefore, it is probable that the FIN message from the server has been sent after receiving this alert. Quite possibly, the client sends an alert which triggers the connection closure, and the server reacts by closing the transport medium (the FIN packet).您的.75计算机（客户端）发送“加密警报”消息。如果它这样做，那么此机器在此时认为连接仍在运行，并且服务器将能够接收警报消息，特别是解密它。否则，发送该消息的重点是什么？因此，在收到此警报后，很可能已发送来自服务器的FIN消息。很可能，客户端发送一个触发连接关闭的警报，服务器通过关闭传输介质（FIN数据包）做出反应。

Note that in a normal handshake, the server will wait for reception of the Finished message from the client (the "encrypted handshake message" after the Change Cipher Spec) before sending its own Change Cipher Spec and Finished. We see that here, so the server was able to process the Finished message from the client, including decryption, MAC verification and message contents.请注意，在正常的握手中，服务器将等待从客户端发来的Finished消息（Change Cipher Spec之后的“加密握手消息” ），然后再发送自己的Change Cipher Spec和Finished。我们在这里看到，因此服务器能够处理来自客户端的Finished消息，包括解密、MAC验证和消息内容

Assuming that both implementations conform to the standard, the "encrypted alert" message is not a close_notify warning. A close_notify is an alert message which warns the recipient of the intention of the sender to gracefully terminate the connection. The recipient must then reply with a close_notify of its own, marking its acceptance of that fact. Here, the client sends an alert message but no alert message is sent in response by the server, so we might surmise that we are not witnessing a graceful termination with a pair of close_notify. Most plausibly, the client's alert is a fatal alert, which tells to the server that something is amiss, and that the connection is doomed. The server can then only close the transport medium because there is nothing else that it can do at that point.假设两个实现都符合标准，“加密警报”消息不是close_notify警告。A close_notify是警告消息，警告接收方发送方有意终止连接的意图。然后，收件人必须close_notify自己回复，表明其接受了这一事实。在这里，客户端发送一条警报消息，但服务器没有响应发送警报消息，因此我们可能会猜测我们没有目睹一对正常终止close_notify。最可信的是，客户的警报是致命的alert，告诉服务器某些东西是不对的，并且连接注定要失败。然后，服务器只能关闭传输介质，因为此时无法执行任何其他操作。

There is no indication as to what bothered the client enough to make it send an alert; however, there are rather decisive indications that all cryptographic operations went well.没有迹象表明困扰客户的是什么让它发出警报; 然而，有相当决定性的迹象表明所有加密操作都进展顺利。

You may want to run two network captures on both systems, so that you may get precise timings for all packets; it helps in reconstructing the actual sequence of events.您可能希望在两个系统上运行两个网络捕获，以便您可以获得所有数据包的精确计时; 它有助于重建事件的实际顺序。

I have edited the question to clarify the Alert was 21, which I understand is a fatal error: Decryption failed我已经编辑了这个问题，以澄清警报是21，我理解这是一个致命的错误：解密失败

Actually I may be confusing Content Type 21, which is Alert, with Alert Code 21. Is this case, I think the former is the correct, and therefore I dont know what Alert code was sent事实上，我可能会混淆内容类型21，即警报，警报代码21.在这种情况下，我认为前者是正确的，因此我不知道发送了什么警报代码

The alert message is encrypted, so you cannot see its contents. The message type (which is "handshake", "alert", "change_cipher_spec" or "application_data") is written in the record header, and that's what wireshark shows you; the contents (whether the alert is fatal or a warning, and the actual error code) are inaccessible to wireshark.警报消息已加密，因此您无法看到其内容。该消息类型（这是“握手”，“警告”，“change_cipher_spec”或“application_data”）被写入记录头，这就是Wireshark的告诉您; wireshark无法访问内容（警报是致命的还是警告，以及实际的错误代码）

友情链接

汕头招聘网 | 山东招聘网 | 郑州教育培训 | 软件下载