TLS1.3クライアント-/サーバー-Helloバージョン1.2
OpenSSL経由でTLS1.3サーバーを起動しました（バージョン1.1.1-pre4（ベータ版）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
ワイヤーハーク（バージョン：2.9.0-55）を介してトラフィックをキャプチャしました：
ハンドシェイクプロトコルに関するバージョン1.2、さらにはレコードレイヤーの1.0が検出/定義されるのはなぜですか？
rfc-draft を読んでいるときに、私はこれを見つけました：
下位互換性を最大化するために、最初のClientHelloを含むレコードのバージョンは0x0301である必要があり、2番目のClientHelloまたはServerHelloを含むレコードのバージョンは0x0303である必要があり、それぞれTLS1.0とTLS1.2を反映しています。
私のpcapを見ると、2番目のClientHelloを含むこのレコードが見つかりません。そして、次のServerHelloは確かにバージョン0x0303です。
しかし、結局のところ、クライアントとサーバーはTLS1.3を話しているようです： 
ぜんぜんわかりません。手伝って頂けますか？
1.3で提示されたとき、貧弱な実装が壊れたからです。
Cloudflare：TLS 1.3がまだブラウザにない理由
バージョン3.4のクライアントhelloが提示された場合、TLS 1.2対応サーバーの大部分は、3.3で応答する代わりに切断します。 HannoBöck、David Benjamin、SSL Labsなどによるインターネットスキャンでは、TLS 1.3の失敗率が非常に高く、多くの測定で3％を超えていることが確認されました。
物議を醸した選択は、最初のTLS 1.3メッセージ（クライアントhello）をTLS1.2のように見せるためのDavidBenjaminからの提案を受け入れることでした。クライアントからのバージョン番号が（3、3）に戻され、サポートされているバージョンのリストを含む新しい「バージョン」拡張機能が導入されました。サーバーは、TLS 1.3がサポートされている場合は（3、4）で始まり、それ以外の場合は（3、3）以前のサーバーhelloを返します。 TLS 1.3のドラフト16には、この新しく「改善された」プロトコルネゴシエーションロジックが含まれていました。
元のプロトコルネゴシエーションメカニズムは回復不能に焼失しています。つまり、TLSの将来のバージョンでは、重大な破損なしに使用できない可能性があります。
2番目のClientHelloが送信されますのみサーバーが要求した場合–HelloRetryRequestメッセージへの応答として送信されます。
key_shares拡張子のDHキー共有がサーバーに受け入れられる場合、受け入れられない場合はクライアントに2番目のClientHelloを要求しませんが、クライアントは他のグループ（supported_groups拡張子内）のサポートをアドバタイズします）許容できる場合、サーバーは、クライアントが送信する必要のあるグループとともにHelloRetryRequestを送信することにより、2番目のClientHelloをクライアントに要求します。 supported_groups拡張子のグループのいずれもサーバーに受け入れられない場合、サーバーはhandshake_failureアラートで接続を拒否します（RFCに準拠している場合）。
補足：アドバタイズおよびネゴシエートされた実際のプロトコルバージョンは、supported_versions拡張機能に存在します（ServerHello.versionの値が0x0303であっても、WiresharkはそれがTLS 1.3接続であることを認識します）。