私はSSL/TLSプロトコル、より具体的にはそのハンドシェイクを研究しています。最初に、クライアントがClient Helloメッセージをサーバーに送信し、クライアントがサポートするTLSバージョンを含むことを知っています。
クライアントで WinHTTP およびサーバーでApache Javaで実装されたHTTPS接続を使用するアプリケーションがあります。HTTPSトラフィックを Wireshark 、これは次のようになります:
_Client Hello, version-TLS 1.2
Server Hello, version-TLS 1.2
Client Key Exchange, version-TLS 1.2
Client Cipher spec, version-TLS 1.2
Application data, version-TLS 1.2
Encrypted alert version-TLS 1.2 [from client]
FIN version-TLS 1.2
ACK version-TLS 1.2
_
_Encrypted alert
_の意味がわかりません(WiresharkではEncrypt alert (21)
と表示されます)-クライアントから送信されるため、と想定していますnotifyアラートを閉じます。
最初のセッションが閉じられてから数秒後、次のように新しいセッションが開始されます。
_Client Hello, version-TLS 1.0
Server Hello, version-TLS 1.0
Client Key Exchange, version-TLS 1.0
Client Cipher spec, version-TLS 1.0
Application data, version-TLS 1.0
Encrypted alert version-TLS 1.0 [from client]
FIN version-TLS 1.0
ACK version-TLS 1.0
_
これから、バージョンの変更と暗号について結論を出します。
これは毎回発生するわけではありません。新しいセッションがTLS 1.2を使用することもあれば、TLS 1.0にフォールバックすることもあります。これの理由は何ですか?
ログは部分的です。すべてのパケットを表示するわけではありません。特に、ハンドシェイクが完了していない場合、SSLに「アプリケーションデータ」レコードを含めることはできません。完全なハンドシェイク(省略形かどうか)には、必ずtwo「暗号仕様の変更」が含まれます。メッセージ。また、システムが複数の連続したハンドシェイクメッセージを送信する場合(サーバーでは一般的です。通常、ServerHello
の後にはCertificate
が続き、次にServerHelloDone
が続きます)、メッセージは通常、同じrecord内にラップされます。
バージョンについては、SSLには2つあります。ClientHello
とServerHello
でネゴシエートされたプロトコルバージョンと、レコードヘッダーで使用されるバージョンです。それらは必ずしも一致しません(ただし、少なくともhelloメッセージのペアの後には一致します)。これらのフィールドをより徹底的に検査する必要があります。
「暗号仕様の変更」の後、後続のレコードは暗号化されるため、Wiresharkはその内容を見ることができません。一般的なタイプ(ハンドシェイク、アラート、アプリケーションデータ...)のみが表示されます。これは、レコードヘッダーの一部であるためです。これが、「暗号化されたアラート」が表示される理由です。
一部のクライアントは、いくつかのバージョンを試します。最初は高いアナウンスバージョンから始めますが、表示された内容が気に入らないため、別のアナウンスされた最大バージョンでもう一度試す可能性があります。これはあなたが観察するものかもしれません。
この回答 は、SSL/TLSの詳細な紹介であり、記録されたハンドシェイクの分析に役立ちます。