他のユーザーのセッションを撃墜したことに基づく、TLSプロトコルの新しいサービス拒否の脆弱性？
TLSに対する新しいサービス拒否攻撃があると思います。これが本当の脆弱性であるかどうかを確認してください。
私は最近、認証されたクライアントセッションをドロップする適切な方法について学びました（ この質問 を参照）。 RFC 5246 ＆ RFC 5077 によると、これは致命的なアラートを送信することで行われます。しかし、そのようなドロップに完全なセッション再開が本当に必要かどうかについては何も言われていません。つまり、実際にanyクライアントが他のクライアント、セッションIDのみを知っている。
手順は次のとおりです。
- サーバーに接続してclient_helloをターゲットセッションIDで送信する
- server_hello、change_cipher_spec、およびfinishedを含むサーバーの応答を待ちます
- uNENCRYPTEDの致命的なアラートを任意の値で送信する
致命的な警告メッセージを送信または受信すると、両者は直ちに接続を閉じます。サーバーとクライアントは、失敗した接続に関連付けられたセッション識別子、キー、およびシークレットをすべて忘れる必要があります。したがって、致命的なアラートで終了した接続は再開してはなりません。
これは、NULLを含むすべての接続および暗号化状態で完全に機能します。
私は実際のOpenSSL実装を確認しました。脆弱性（脆弱性の場合）が存在します。コミュニティは何と言いますか？私はこの問題を本当の脆弱性としてプッシュしますか、それともそれは本来あるべき状態であり、心配する必要はありませんか？
要約する：
- サーバーがセッションパラメータのキャッシュを管理する方法に応じて、機能する場合と機能しない場合があります。
- RFCは一貫していません。
- 「実際の」脆弱性ではありません。
TLS sessionsは当初、クライアントとサーバーが接続ごとに「重い非対称暗号」を使用して完全なハンドシェイクを行わないようにするためのものでした（そのような暗号の実際のコストは過大評価されることが多いですが、ポイント）。既存の展開されたクライアントとサーバーはしばらくの間セッションを記憶する傾向があり、覚え続けるのが不便になったときにそれらを忘れます（通常、サーバー側でRAM専用ストレージが古い、完全なセッションは削除されます。クライアントとサーバーは必要に応じて透過的に完全なハンドシェイクを行うことができ、セッションの再開は日和見的です。
配備されたシステムの中には、セッションの再開を利用して、より確実に機能するものがあります。特に、スマートカードを使用したクライアント認証を使用するWebベースのアプリケーション：スマートカードを使用すると、計算コストが小さく（たとえば1秒）、ユーザーコストが高い（人間のユーザーは、タイプa PINコード）。ただし、これらの場合でも、セッションパラメータはRAMのみに格納されるため、クライアントのブラウザが閉じている場合）その後、再度開くと、セッションは再開されず、完全なハンドシェイクが発生します。
RFC 5246 、 セクション7.2.2 に次の段落が含まれています。
TLSハンドシェイクプロトコルでのエラー処理は非常に簡単です。エラーが検出されると、検出側は相手にメッセージを送信します。致命的な警告メッセージを送信または受信すると、両者は直ちに接続を閉じます。サーバーとクライアントは、失敗した接続に関連付けられたセッション識別子、キー、およびシークレットをすべて忘れる必要があります。したがって、致命的なアラートで終了した接続は再開してはなりません。
これは、非公式に、攻撃者が多くのセッションの再開を「試行」することに依存する、まだ特定されていない総当たり攻撃を阻止することを意味する包括的な声明です。その処方箋についてなされなければならないいくつかの啓発的なポイントがあります：
歴史的に、接続は（明示的な
close_notify）。ただし、既存のWebサーバーは突然接続を閉じるため、Webブラウザは、TLS-1.0が不快になるような方法でセッションが終了した場合でも、セッションを「生きたまま」に保つことで適応しました。セッションチケット が使用されている場合、致命的なアラート時にセッションを忘れるというこの概念はサーバー上では機能しません。これは、セッションチケットを持つサーバーが自身のメモリを管理しないためです。その点で、RFC 5077とRFC 5246には一貫性がありません。この「再開してはいけません」は、セッションチケットを使用するサーバーでは強制できません。
ほとんどのSSL実装は、RFCに準拠するために物理法則を破ることに消極的です。
アラートを送信しなくても、攻撃者は常に「致命的な状態」を強いられる可能性があります。攻撃者が自分で接続を開き、正規のクライアントが使用している接続と同じセッションIDを再利用すれば十分です。サーバーはセッションの再開を試み（
ServerHello、ChangeCipherSpec、Finished）、クライアントからのChangeCipherSpec、次にFinishedを期待します。クライアントは攻撃者であり、攻撃者は再開しようとしているセッションのマスターキーを知らないため、Finishedメッセージは適切に復号化されず、bad_record_macサーバーから。セクション7.2.2に従う場合、サーバーはセッションを忘れます。前の段落で説明した「失敗した
Finishedでセッションを強制終了」攻撃は、観察のみを含むため、説明している攻撃よりも簡単に引き抜くことができることを指摘しておきます。 = modifyingではなく、（セッションIDを取得するための）真の接続。
上記の3番目のポイントは重要です。適切に暗号化され、MAC化されたFinishedメッセージをクライアントから受信するまで、サーバーは実際のクライアントと実際に通信している証拠がありません。間違いなく、セッションはその時点まで「再開」されないため、その時点より前に発生したエラー状態（クライアントからの明示的なアラート、MAC障害、またはその他）に対して「無効化」してはなりません。ただし、RFCについても明確ではないため、実際に何が発生するかは、サーバーの実装者の気まぐれでサーバーがキャッシュを管理する方法に依存します。
この脆弱性は「本物」ではありません。たとえば、クライアント接続をいじる立場にあるすべての攻撃者は、たとえば、クライアントのClientHelloメッセージに合成アラートメッセージまたは単にランダムな迷惑メールで応答し、反対側に有効なSSL/TLSサーバーがないことをクライアントに納得させる-より包括的なサービス拒否サーバーとクライアントに完全なハンドシェイクのために数ミリ秒のCPUを費やすだけです。
提案どおりに機能していることを経験的に確認した場合は、 OpenSSLセキュリティチームに通知 する必要があります。
このバグの影響は、サービス拒否の範囲に影響を与える可能性があります。基本的に、クライアント/サーバーのペアが毎回完全なネゴシエーションを実行するように強制できます。これにより、より多くのサーバーリソースが消費されます（これが、最初から再開が存在する理由です）。そして、可用性のスケールでは、これはおそらくそれほど大きくありません。再開が使用されない場合に予想される基本レベルにパフォーマンスを低下させるだけであり、これは受け入れられる最悪のシナリオ**です。
現時点では、機密性や整合性に対する脅威はありません（ただし、マイナー問題Xとマイナー問題Yを組み合わせてメジャー問題Zを作成した例が履歴に散らばっています）。
これまでに説明したように、これは実装の問題であるか、プロトコルの問題である可能性があります。あなたが言うように、「完全なセッションの再開がそのようなドロップのために本当に必要であるかどうかについて、[RFC]で何も言われていません。」したがって、さまざまなSSL実装がこのケースを異なる方法で処理する可能性があります。すでにOpenSSLを検討しているので、これらの行に沿って説明を続けます。概念実証コードがある場合は、他のSSL実装をテストして、それらの処理方法を確認できます。
それがより広範なプロトコルの問題であることが判明し、すでにOpenSSLセキュリティチームと協力している場合は、アドバイザリを拡大する方法についてアドバイスを求めます。
*エスカレーションする前に、概念実証を考案することをお勧めします***。まず、実際に問題があることを確認します。第二に、問題を再現できるようにするエクスプロイトコードがある場合、問題はより注意深くなります。 「実際のOpenSSL実装を確認したばかり」という意味が明確ではないため、現時点でコードレビューを完了していると想定します。
**このバグの重大度はかなり低いです。おそらく「サービスの低下」は「サービスの拒否」よりも良い言葉でしょう。このため、この問題を公開したことについて心配する必要はありません...機密性を要求したり、「 倫理的開示 」の慎重な手順を踏んだりするだけの影響はありません。 （これは問題を最小限に抑えるためではありません。標準の言語のあいまいさが望ましくない動作の侵入を可能にした魅力的な場所のようです。）
*** @Trueblackerは概念実証を作成し、 OpenSSLチームに問題を公開しました -コメントは一時的なものであるため、ここに文書化します。
いいえ、それは本当の脆弱性ではありません。攻撃計画のギャップは次のとおりです。他のユーザーが使用するセッションIDをどのように学習する予定ですか？
セッションIDは推測しにくいため、他のユーザーが使用するセッションIDを予測したり推測したりすることはできません。セッションIDがわからなければ、攻撃を行うことはできません。したがって、実際に攻撃者がこの攻撃を実際にどのように実行するかは明確ではありません。
特に、オフパスの攻撃者はセッションIDを見たり推測したりできないため、おそらくこの攻撃を実行することはできません。中間者攻撃または盗聴を考えている場合、攻撃者がそれを行う立場にあると、可能性に対してはるかに悪い攻撃が可能になります-そのシナリオはあまり興味深いものではありません。このような攻撃は、取るに足らないものと考えられます。