我通过 openSSL 启动了 TLS1.3 服务器（版本 1.1.1-pre4 (beta) 2018 年 4 月 3 日）
$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www -tls1_3
以及 TLS1.3 客户端
$ openssl s_client -connect 127.0.0.1:44330 -tls1_3
我通过 wirehark（版本：2.9.0-55）捕获了流量：
为什么检测/定义了有关握手协议的 1.2 版本，甚至记录层的 1.0 版本？
在阅读rfc 草案， 我找到了这个：
为了最大限度地实现向后兼容性，包含初始 ClientHello 的记录应该具有版本 0x0301，而包含第二个 ClientHello 或 ServerHello 的记录必须具有版本 0x0303，分别反映 TLS 1.0 和 TLS 1.2。
查看我的 pcap，找不到包含第二个 ClientHello 的这条记录。以下是 ServerHello确实是版本 0x0303。
但看起来，客户端和服务器确实使用的是 TLS1.3：
我不明白这一点。你能帮助我吗？
答案1
因为当呈现 1.3 时，糟糕的实现就失效了。
Cloudflare：为什么 TLS 1.3 尚未在浏览器中使用
当客户端收到 3.4 版的 hello 请求时，大部分支持 TLS 1.2 的服务器会断开连接，而不是回复 3.3 版。Hanno Böck、David Benjamin、SSL Labs 和其他人员进行的互联网扫描证实，TLS 1.3 的失败率非常高，在许多测量中超过 3%。
有争议的选择是接受 David Benjamin 的提议，让第一个 TLS 1.3 消息（客户端问候）看起来像 TLS 1.2。客户端的版本号改回了 (3, 3)，并引入了一个新的“版本”扩展，其中包含受支持的版本列表。如果支持 TLS 1.3，服务器将返回以 (3, 4) 开头的服务器问候，否则返回 (3, 3) 或更早的版本。TLS 1.3 的第 16 号草案包含这个新的“改进”协议协商逻辑。
原始协议协商机制已不可恢复。这意味着它很可能无法在未来版本的 TLS 中使用，除非发生重大损坏。
答案2
发送第二个 ClientHello仅有的如果服务器要求的话——它将作为对 HelloRetryRequest 消息的响应发送。
key_shares如果服务器接受扩展中的 DH 密钥共享，则它不会要求客户端发送第二个 ClientHello；如果服务器不接受，但客户端宣称支持其他supported_groups可接受的组（在扩展中），则服务器将通过发送 HelloRetryRequest 以及客户端应发送的组来要求客户端发送第二个 ClientHello。如果服务器不supported_groups接受扩展中的任何组，它将拒绝连接并发出handshake_failure警报（如果符合 RFC 标准）。
旁注：宣传和协商的真实协议版本存在于supported_versions扩展中（这就是 Wireshark 知道它是 TLS 1.3 连接的方式，即使 ServerHello.version 中的值为 0x0303）。