web-dev-qa-db-ja.com

Client HelloメッセージとServer Helloメッセージで示されているセッションIDパラメータとは

TLSハンドシェイクを深く理解しようとしていました。 Wiresharkをセットアップし、github.comトラフィックをキャプチャしました。 Client HelloとServer Helloを検査しているときに、パラメーターセッションIDを見つけました。

この記事 によると、大きなハンドシェイクなしで再接続する場合にセッションIDを使用できます。私が理解していることは、以前に接続したことがある場合、キャッシュされたセッションIDを最新のセッションに再び使用できることです。その場合、セッションIDをプレーンテキストとして送信します。これは攻撃者に捕らえられますか？

enter image description here

または、私はここで完全に間違っていますか？これは対称鍵とは異なりますか？

tlspublic-key-infrastructurewiresharkhandshake
2
Anonymous Platypus

これは攻撃者に捕らえられますか？

はい-しかし、それらはあまり使用されません。

これは、以前に（そして安全に）合意されたアルゴリズムとキーへの間接的な参照であり、サーバー/クライアントによって記憶されます。したがって、攻撃者がセッションを再開したいことをサーバーにアサートすると、サーバーは暗号化テキストで再開し、攻撃者のクライアントは復号化の方法を知りません。

（mayこれを単一のクライアントに対してDOSにエスカレーションするための範囲がありますが、それは私の側の推測です。そして、攻撃者がトラフィックを盗聴できる場合、接続を破壊する簡単な方法があります。）

TLSセッションはHTTPセッションとは何の関係もないため、攻撃者がデータを復号化できたとしても、アプリケーションのユーザーセッションを制御するには十分ではありません。

3
symcbean

最初のセッション識別子（RFC 5246）再開メカニズムはSSL 2.0で導入されました。これにより、サーバーは、以前に見た完全なTLSネゴシエーション中に、ServerHelloメッセージの一部として32バイトのセッション識別子を作成および送信できました。セッションIDを設定すると、クライアントとサーバーの両方で、以前にネゴシエートされたセッションパラメーター（セッションIDをキーとする）を保存し、後続のセッションで再利用できます。

具体的には、クライアントはClientHelloメッセージにセッションIDを含めて、以前のハンドシェイクでネゴシエートされた暗号スイートとキーをまだ記憶していて、それらを再利用できることをサーバーに示すことができます。次に、サーバーがアドバタイズされたIDに関連付けられたセッションパラメータをキャッシュ内で見つけることができる場合は、簡略化されたハンドシェイクを実行できます。それ以外の場合は、完全な新しいセッションネゴシエーションが必要です。これにより、新しいセッションIDが生成されます。

ソース： https://hpbn.co/transport-layer-security-tls/#tls-session-resumption

0
Anonymous Platypus