TLS再ネゴシエーション表示拡張機能の脆弱性
RFCのTLS Renegotiation Indication Extensionを理解しようとしています。再ネゴシエーションが暗号化されたストリームの下で送信されるという事実に関連していることは理解できますが、アイデアとエクスプロイトを理解することはできません。
これを理解し、RFCを読むことができるように、簡単な言葉で私に説明していただけませんか？
Marsh Rayのブログは間もなくダウンしているようです 、しかし Eric Rescorlaのブログ （ここでは同じサンプルアプリケーションデータを使用しています）または-で詳細を読むことができます このPDF （ archive.orgのコピー ）。
正規のクライアントは
Client Hello（GenCH）をサーバーに送信しますが、これはMITMによってインターセプトされます。MITMはそれを保持し、
Client Hello（MitmCH）をサーバーに送信することで独自のハンドシェイクを開始します。ハンドシェイクが正常に完了し、アプリケーションデータが送信されます。例えば：GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This:MITMは、最初の
Client Hello（GenCH）をサーバーに転送するようになりました。クライアントに関する限り、これは再ネゴシエーションではなく、最初のネゴシエーションです。それは違いを見分けることができません。ハンドシェイクが完了し、独自のリクエストを送信します。
GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookieサーバーに関する限り、2番目の
Client Hello（GenCH）の受信は、Client Helloで開始された最初のハンドシェイクに続く再ネゴシエーション（いずれかの当事者が任意の時点で開始できた）にすぎません（MitmCH）。アプリケーション層は連続として扱われます。これはサーバーが見るものです：GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie
このようにして、攻撃者は、正規のクライアントのCookieを保持したまま、要求行（およびクエリパラメータ）を変更し、独自のヘッダーを挿入することができます。 MITMは、クライアントが送信するものを表示または変更することはできませんが、前にコンテンツを追加することができます。これは、アプリケーション層で同じ要求の一部として扱われます。
概要。これは、数年前に発見された SSLの再ネゴシエーションに関連する設計上の弱点 を指します。拡張機能は脆弱性を閉じるように設計されています。
背景。SSLを使用すると、サーバーとのSSLセッションが確立されているクライアントは、セッションスイートの再ネゴシエーションを要求できます（暗号スイートなどのセキュリティパラメーター）。再ネゴシエーションは基本的に新しいSSLセッションを作成しますが、まったく新しいSSL接続を最初から作成するよりも潜在的に効率的です。最も重要なのは、再交渉されたセッション中に、クライアントが最初に証明書を提供していなくても、クライアントがクライアント証明書を提供できることです。
したがって、クライアントが再ネゴシエーションを開始する場合、SSL接続のタイムラインを、再ネゴシエーション前と再ネゴシエーション後の2つのフェーズに分割できます。
攻撃の前提条件。サーバーは、特定の条件下でのみこの攻撃に対して脆弱です。簡単な例として、サーバーアプリケーションが再ネゴシエートされたセッションでクライアント証明書をチェックするようにコーディングされていて、見つかった場合、SSL接続全体をそのクライアントからの接続として信頼されているものとして扱います。再ネゴシエーションの前にSSL接続を介して送信されたもの。表面的には、これはサーバーアプリケーションが行うにはかなり怪しいことのように思われますが、サーバーアプリケーションがこれを行うようにコード化されているとします。再交渉フェーズ。また、クライアントがサーバーに接続し、クライアント証明書でサーバーを認証するとします。
攻撃。これらの前提条件が満たされている場合、再交渉攻撃は中間者（MITM）攻撃です。攻撃は、攻撃者によって送信されたいくつかのバイトの起源についてサーバーをだますつもりです：サーバーは、実際には攻撃者から来たのに、クライアントから来たと思い込ませられます。
攻撃は、攻撃者がサーバーへのSSL接続を開いてサーバーにデータを送信することから始まります（攻撃者はサーバーをだまして、それらのバイトがクライアントからのものであると考えようとします）。さて、ある時点でクライアントはサーバーに接続しようとしますが、これはMITM攻撃であるため、攻撃者はそれを傍受します。攻撃者は、サーバーとの接続を介して再ネゴシエーションを開始します。再ネゴシエーション中に、攻撃者はメッセージを変更することなく、クライアントとサーバーから相互にデータを中継します。サーバーは、既存の接続を介してセッションを再ネゴシエートしていると見なします。クライアントは、新しい接続と新しいセッションを完全に開いていると考えます。しかし、どちらも彼らの見解でこの矛盾を検出しません。この間、クライアントはクライアント証明書を使用して認証します。
攻撃の最後に、何が起こるか見てみましょう。再交渉は成功した。サーバーはクライアントのIDを正常に検証し、クライアントのIDがクライアント証明書に対応していることを認識しています。クライアントは、SSL接続が正常に完了したと考えており、何も問題がないという手掛かりはありません。サーバーは、再ネゴシエーションが成功したSSL接続を認識し、再ネゴシエーション後の部分はクライアントの証明書によって認証されます。
サーバーがSSL接続全体をクライアント証明書によって認証されたものとして処理することを間違えると（上記の前提条件で想定したように）、サーバーは再ネゴシエーション前の段階で送信されたバイトが正直なクライアントから送信されました。しかし実際には、これらのバイトは攻撃者によって送信および制御されました。そのため、攻撃者はこれらのメッセージの送信元についてサーバーをだましました-認証の重大な失敗。
Eric Rescorlaが言うように、「 明らかにこれは良くありませんが、それは世界の終わりではありません。 "
解釈。この時点で、誰が責任を負うべきかについて議論することができます。プロトコルの欠陥は、クライアントとサーバーがイベントの見解が一致しない状況に陥ることを可能にするためですか？多分。あるいは、実際には再ネゴシエーション後のものだけが実際に認証されたときに、再ネゴシエーションプロセス中に発生した認証プロトコルによって認証されたものとして再ネゴシエーション前のバイトを扱うような愚かなことをするので、これはサーバーの障害であると言えるでしょうそれによります。
したがって、可能な修正は3つあります。サーバーアプリケーションを慎重にコーディングして、この間違いを犯さないようにします。サーバー側のSSLコードを変更して、すべての再ネゴシエーション要求を拒否します。または、プロトコルを変更して、サーバーアプリケーションがどのように設計されていても発生しないようにします。 TLS Renegotiation Indication Extensionは、後者のアプローチに従います。もちろん、サーバーアプリケーションにこの問題がない場合は、拡張子は関係ありません。
問題の範囲。RFC 5746 は、これが発生する可能性がある状況についていくつかの議論があります。たとえば、クライアント証明書以外に、サーバーアプリケーションがクライアントが送信する秘密情報（HTTPS Cookieなど）に基づいてクライアントを認証済みとして扱う場合にも発生する可能性があります。
私の知る限り、この拡張機能は現時点では広く導入されていませんが、サーバーは再交渉を拒否するだけで問題を回避できます。
もっと読む。ここでもっと読むことができます：
サーバーが脆弱かどうかを確認するには、 SSL Labsの自動SSL構成テスター を試してください。彼らのテスターは この問題を自動的にテスト します。
（この脆弱性は、中間者、つまりMITMを持っていることを前提としています。これはMITMがクライアントの秘密鍵なしでサーバーへの双方向SSL接続を確立する方法であると考えています。MITM状況をどのようにして取得したかは、別の問題です。
クライアントはClient helloを送信し、サーバーが応答するのを待ちます。クライアントは、後でセッションキーを確立するために使用されるランダムな値を含む、いくつかの情報を送信します。これは常に起こります。
Client HelloはMITMによって受信されます。 MITMは同じClient Helloを使用してSSLセットアップを完了します自分で。 MITMはクライアントに戻ることなくServer helloに応答します。その間、クライアントはサーバーが応答するのをまだ待っています。クライアントをだますことを思い出してください。彼はMITMがサーバーだと思っています。
したがって、この時点で次のようになります。
- サーバーが
Server helloで応答するのを待っているクライアント - サーバーへの完全なSSL一方向接続を持つMITM
MITMがSSL再ネゴシエーションをトリガーするか、サーバーが要求して、おそらく双方向SSLを実現します。どちらの方法でも、MITMは再ネゴシエーション要求を処理します。クライアントがずっと待っていたServer Helloを送信します。しかし、今ではMITMがすべてを制御します。サーバーが送信したチャレンジが何であれ、MITMは再生できるため、クライアントは自分の（クライアントの）秘密鍵を使用して必要な値を計算します。
今、この時点で：
- MITMとの双方向SSLセッションを持ち、サーバーが応答したと考えるクライアント
- クライアントの通信チャネルにデータを挿入できるMITM。
再ネゴシエーションを無効にすることにより、サーバーはServer helloメッセージでクライアント認証を要求します。 MITMは、それ自体ではハンドシェイクを完了できません。