SSL再ネゴシエーション攻撃から保護するために、Citrix Netscalerで何をする必要がありますか？
TLS/SSLの再ネゴシエーションハックが修正されたようです。ソフトウェアをサーバー側、クライアント側、またはその両方に展開する必要があるかどうかはわかりません。
このブログ に基づいて、TLS再ネゴシエーションは良いことですが、安全に行われた場合にのみ...そしてTLS再ネゴシエーションを無効にすることは、サーバー（およびクライアント??）にパッチが適用されるまでの一時的な回避策にすぎません。
この理解は正しいですか？
SSL Labsが私のネットスケーラーが「安全でない再ネゴシエーション」をサポートしていると言った場合、それを安全にするにはどうすればよいですか？
Citrixは、この脆弱性は ソフトウェアの新しいバージョン で「修正」されていると述べていますが、これを有効にするにはどうすればよいですか？
私を混乱させているのは、「クライアント」のオプションを使用してロードバランサーでこれを無効にする必要があるという内部の議論です。それが実際にどういう意味かはわかりません。
ここに、この「再交渉ハック」が何であるかについての説明があります。
SSL/TLS セッションは、「ハンドシェイク」と呼ばれる手順で始まります。接続直後、クライアントとサーバーが交換します暗号化が発生し、その後クライアントとサーバーが共有するセッション固有のシークレットを含むいくつかの管理メッセージには、後続のデータが暗号化されて整合性が保護されます。安全なトンネルが確立されます。
再ネゴシエーションはsecondハンドシェイクwithinトンネルを実行する機能です。次に、管理メッセージは暗号化されて整合性が保護され（最初のハンドシェイクによって確立された共有シークレットで）、2番目の共有シークレットが生成され、前のシークレットが置き換えられます。
なぜ誰もがそれをしたいと思うのでしょうか？主にHTTPSとWebブラウザ、特にInternet Explorerの結合された欠点を回避するためです。
ハンドシェイク中にサーバーが証明書を表示し（クライアントがサーバーを認証する）、クライアントが同じことを行うようにmay要求する、つまり証明書を提示して対応する秘密鍵を使用する。クライアントは要求を自由に拒否でき（つまり、証明書を送信しない）、これは名目上ハンドシェイクにとって致命的ではありません（サーバーがハンドシェイクを続行することを選択する場合があります）。クライアント証明書はまれですが、特にユーザーが選択したパスワードの問題を回避するため、気の利いたものと見なされます（独自の問題がありますが、同じではありません）。一部の銀行では、顧客に発行するクライアント証明書を使用しています。
現在、HTTPSはSSL内のHTTPです。クライアント（ブラウザ）はサーバーに接続し、SSLトンネルを確立してから、トンネル内でHTTPリクエスト（またはキープアライブを使用したいくつかの連続したHTTPリクエスト）を送信します。トリッキーな点は、HTTPリクエストの一部であるため、サーバーがtarget URLをその時点でしか認識しないことです。そしてそれは握手の後です。したがって、サーバーはクライアント証明書を要求するかどうかを決定する必要がありますbefore実際のターゲットURLを知っています。
残念ながら、クライアント証明書を要求すると、ブラウザによっては不便な動作が発生します。特に、Internet Explorer 6.0は、SSLサーバーからクライアント証明書のリクエストを受信すると、次の「役立つ」ポップアップを表示します。
このスクリーンショットはWindowsのフランス語バージョンのものですが、要点はわかります。空のリストの中からクライアント証明書を選択するように要求する、技術的に見えるポップアップです。確かに、IE 6.0はローカルマシンの証明書をスキャンして、サーバーからの要求と一致する証明書を探し、何もない場合でもポップアップを表示します。この種の動作はユーザーを混乱させる傾向があります。特に、銀行のWebサイトに初めてアクセスし、証明書ベースのクライアント認証システムに登録することを選択する可能性があるため、証明書を持たない銀行の顧客まだです。 、彼が怖がっていない場合。
IE 9.0はその点でより適切に動作しているように見えますが、考え方は変わりません。クライアント証明書はUIに関してWebブラウザーで適切に処理されないため、サーバーは、「トレーニング」されたサイトの特定の部分に対してのみクライアント証明書を要求します登録済み）ユーザーは到達しようとします。ただし、ハンドシェイクはターゲットURLの送信前に発生するため、再交渉が必要です。物事はそのように発生するはずです：
- クライアントが接続します。ハンドシェイクが実行され、サーバーはnotにクライアント証明書を要求します。クライアントはまだ認証されていません。
- クライアントは、新しく確立されたSSLトンネル内でHTTP要求を送信します。
- リクエストのターゲットURLは「登録済みエリア」の一部です（「
GET /registered/index.html"リクエスト）。サーバーはAha！ユーザーを登録する必要があります。もう一度SSLを実行しましょう。今回はクライアント証明書を使用します。 - サーバーは新しいハンドシェイク（再ネゴシエーション）を要求します。今回、サーバーはクライアント証明書を要求します。クライアントが準拠します。この再ネゴシエーションは、HTTP要求よりも「下位層」で発生することに注意してください。その時点でHTTP要求はまだ保留中です。
- サーバーがクライアントを確実に認証したので、サーバーはリクエストを許可し、最初のトンネルを置き換えた2番目のトンネル内でHTTP応答を送信できます。
それでは、ハックを見てみましょう。SSL再ネゴシエーションの重要な特性は次のとおりです。
- 新しいハンドシェイクはサーバーによって開始できますorクライアントはいつでも（上記のシナリオでは、サーバーが再ネゴシエーションをトリガーすることを前提としていますが、SSLではクライアントもトリガーできます）。
- ハンドシェイクビジネス全体は、トンネルで転送されるアプリケーションデータ（HTTP要求と応答）に関係なく、トンネルレベルで発生します。
- 再ネゴシエーションのハンドシェイクメッセージは、最初のハンドシェイクの場合と同じバイト単位です（再ネゴシエーションの場合、メッセージは最初のハンドシェイクによって確立された暗号化層を通過します）。
だから、今、攻撃。上記のようなサーバーを想定しています。さらに、サーバーに送信できるいくつかの要求には、クライアント認証を必要とする「影響」があり、攻撃者にとっては貴重です（例：送金の要求）。そのため、攻撃者は最初に 中間者 の状況に陥ります。クライアントとサーバー間で交換されるバイトを自由に傍受して変更できます。次のスキームは、攻撃の様子を示しています。
したがって、攻撃手順は次のとおりです。
- 正直なクライアントは接続を望んでいるため、最初のハンドシェイクメッセージ（「ClientHello」と呼ばれます）を送信します。
- 攻撃者はそのメッセージを一時的にブロックします。次に、攻撃者は、まるで通常のクライアントであるかのように、サーバーとの間に独自のSSLトンネルを確立します。攻撃者はMitMの立場にいるため、申し立てられたIPアドレスを含むすべての詳細でクライアントを模倣できます。サーバーはまだクライアント証明書を要求しないため、トンネルを正常に構築できます。
- 攻撃者は彼のトンネル（上記のスキーマの赤い部分）内で、送金のHTTPリクエストを送信します。
- サーバーは言う：「その考えを保持しなさい、クライアント、私は証明書であなたを認証する必要がある資金移動のために」。そして、サーバーは（HelloRequest）メッセージを（攻撃者に）送信することにより、再ネゴシエーションを開始します。
- 次に攻撃者は、正直なユーザー（その時点でまだ待機中）から送信された最初のClientHelloをトンネルで暗号化して転送します。
その時点で、クライアントは自分が最初のハンドシェイクを行っていると信じ、ハンドシェイクメッセージをクリアテキストとして交換します。攻撃者はそれらすべてを傍受し、サーバーで確立したトンネル内で暗号化します。また、攻撃者はサーバーからのハンドシェイクメッセージを復号化して、クライアントに送信します。クライアントの観点から見ると、これはこの接続で初めてのハンドシェイクです。サーバーの観点からは、これは再交渉です。ただし、ハンドシェイクメッセージは両方のタイプのハンドシェイクで同一であるため、これは機能します。正直なクライアントは、メッセージが攻撃者によって転送されていても、サーバーとのハンドシェイクを正常に完了します。サーバーはクライアントからの認証に満足しています...
...そしてサーバーは仮定攻撃者によるPOSTリクエストを含むfirstハンドシェイク以降に交換されたすべてに対してクライアント認証が有効であることを示しています。そしてthatはセキュリティの問題です。
それで、誰が責任を負うのか、そしてどのように修正するのですか？
問題は、TLS仕様が再ネゴシエーションの概念を記述している一方で、そのような状況で実現される実際のセキュリティプロパティの詳細を記述していないことです。大まかに言えば、再交渉はforward効果を持つ新しい暗号特性を確立します。上記のすべてにおいて、SSLの基本原則に違反していないことに注意してください。正直なクライアントはサーバーとハンドシェイクを行い、認証を行い、クライアントとサーバーが送信するものは何でもafter認証済み。
しかし、攻撃シナリオでは、サーバーは、再ネゴシエーションを通じて取得したクライアント認証を、受信したデータbefore再ネゴシエーション（POST要求）を介して転送したいと考えています。これはbackward効果であり、上記のように、これはSSL再ネゴシエーションが提供するものの一部ではありません。
だから私たちは非難することができます：
- 実際の再ネゴシエーションが明確でないため、TLS仕様does;
- 認証の逆方向の転送を想定したサーバー設計者。
STARTTLSコマンドを使用してSSLをHTTPに統合する代わりに、SSLトンネル内にHTTPを配置するためのHTTPSデザイナー。- webブラウザーのインプリメンター、クライアント証明書のひどい処理。
非難は楽しいが、建設的ではないので、修正を見てみましょう。上記の特定のシナリオでは、修正は RFC 5746 です。最初のハンドシェイクのメッセージと再ネゴシエーションのメッセージが互いに異なるように、いくつかのハンドシェイクメッセージを変更することで構成されています。これは、ハンドシェイクメッセージに固有の暗号バインディングと相まって（ハンドシェイクメッセージは、前のメッセージのハッシュ値に対して計算される検証メッセージで終了するため、MitM攻撃者はハンドシェイクメッセージの内容を変更できません）、これにより上記の問題が修正されます。より一般的なソリューションの場合、最大の困難は、本当に欲しいものを定義することです。しかし、それは、上位層（HTTPなど）がその下で発生する暗号化を認識することを伴うことを知っています。この件に関する議論については RFC 5056 をご覧ください。
別の可能な修正は、サーバーが認証を逆方向に転送しないようにアプリケーションプロトコルを変更することです。 HTTPコンテキストでは、これはHTTP一時リダイレクトで最初のリクエスト（サーバーに新しいハンドシェイクを作成するように促した非認証リクエスト）に応答する必要があるため、クライアントは今回HTTPリクエストを再度送信しますafter新しいハンドシェイク（つまり、サーバーはfirst新しいハンドシェイクを作成してから、リダイレクト応答を送信します）。
パスワードを使用したクライアント認証（SSLトンネル内のHTTP「基本」認証）でも同じ問題が発生しないことに注意してください。そのような認証では、サーバーがパスワードを要求し、クライアントがパスワードを送信した後repeatingターゲットURL。したがって、この問題は多くのWebサイトには当てはまりません。
どうやら、Citrixは修正を公開するのに適しているが、詳細はあまりないことを発見した。彼らは、サーバーが物事を尋ねる方法（サーバーのみの修正）を変更しただけなのか、クライアントが拡張機能もサポートしている限りの修正であるRFC 5746を実装したのかどうかについては述べていません。 Firefox は2010年2月8日からRFC 5746をサポートしています。 Internet Explorer の場合（=実際にはWindows、IEはWindowsのSSL/TLSコードを使用するため） ）、これは2010年8月10日に公開されたパッチの一部でした。
おそらく、Citrix Netscalerはまったく影響を受けていませんでしたが、Citrixの人々は、広報活動の一環として、セキュリティの問題について心配していることを示すために賢く、技術的というより心理的な「修正」を追加しました。
私のアドバイスは次のとおりです。Citrixによって公開されたパッチを適用し、クライアントソフトウェア（OS、ブラウザ...）が最新であることを確認します（とにかく必要なもの）。その後、あいまいなTLS再ネゴシエーションの問題から安全である必要があります。
TLS再ネゴシエーションのサービス拒否の問題 SSL Labsが自動SSLスキャンについて報告しているとおっしゃっていますか？もしそうなら、あなたが本当に懸念する特定のまれな状況がない限り、私は個人的にSSL Labsの警告を無視します。それは実際よりも深刻な問題として非常に過大評価されていると思います。私は彼らのツールで実行したスキャンの1つでもそれを見て、赤い警告が表示されて驚いた.
あなたが彼ら自身の詳細を読み、特にそれらが含まれているリンクをたどる場合、 Eric Rescorlaのブログ/ のトレードオフの非常に良い分析へのリンクがあれば、この脆弱性がなぜかもしれないか理解できれば幸いです。誇張してください。
いくつかの引用：
SSL Labsページ
これは実質的には全体的な助けにはなりませんが（DoS攻撃に対する防御は悪名高いほど困難で高価です）、この特定の手法に対する防御を強化します。
エリックレスコーラ
簡単に言うと、以前はネットワーク帯域幅によって制限されていた帯域幅をわずかに減らした攻撃（約2パケット/秒で、バイト数が10％未満）を行いましたが、計算量が大幅に増加しました。攻撃者のクライアントマシン上。攻撃マシンの正確な特性に応じて、これはより良い場合と悪い場合がありますが、いずれにせよ、それほど大きな改善ではありません。
私が解釈できる限り、分析の非常に簡単な要点は、サービス拒否の可能性のあるベクトルであるということです。実際には、サーバーへの多数のSSL接続を確立することを含む、はるかに単純なサービス拒否攻撃よりも攻撃者に大きなメリットはありません。後者は通常、実行がはるかに簡単です。
client-initiatedの再ネゴシエーションを防ぐためにSSLに微調整と修正が行われている可能性がありますが、攻撃者がDoSまだ可能であり、いくつかのボットネットを使用し、バジリオンSSL接続（またはより単純なSYNフラッド）を確立して、代わりにこれを達成する可能性が非常に高いです。