Yngwe Pettersenは、脆弱性の問題を調査し、ウェブサーバーのギャップをテストしています。
先週、 OpenSSLの 新しい脆弱性の報告があり、これはライブラリのすべてのバージョンに公開されました。 CCSの脆弱性と呼ばれることも多いこの新しい脆弱性はMITMタイプ（Man In The Middle）であり、攻撃者はクライアントとサーバー間で送信されるデータを「盗聴」または変更し 、クライアントとサーバーの両方を偽装して、予測可能な暗号化キー。
CCSの問題
この脆弱性は次のように悪用されます：クライアントとサーバー間のトラフィックを接続および制御する能力を持つ攻撃者は、特定のTLSメッセージ（特に、 暗号仕様の変更 （CCS）メッセージ）をデータストリームに注入します。 確認メッセージの一部ではないCCSメッセージは、送信者から受信したすべての連続したTLSプロトコルエントリが新しく作成された暗号化キーで暗号化されていることを受信者に示します。
このメッセージは、当事者が暗号化キーを作成するのに十分な情報を交換した後に送信されることを意図しています。 残念ながら、OpenSSL（クライアント側とサーバー側の両方）は、すべての手順が完了し、確認信号を受信したかどうかを確認せず、クライアントから送信された秘密キーを使用せずに暗号化キーを作成し続けることが判明しました。 その結果、当事者は予測可能な暗号化キーを使用して承認を開始し、攻撃者は送信されたデータを解読および/または変更することができます。
この脆弱性を回避できますか？
この問題の主な理由は、OpenSSLでCCSメッセージを処理するときに、メッセージが予期した時間に到着したかどうかを確認するチェックが行われなかったためです。 代わりに、暗号化キーを作成および使用するための通常の一連の手順が簡単に実行されました。 おそらく、アクションのシーケンスをより徹底的にチェックし、必要な条件を遵守することで、問題を防ぐことができます。
実装エラーを考慮しない場合、この問題はRenegoと同じカテゴリに分類されます （最近のRenego トリプル確認応答の問題も同様です）：確認応答の信頼性を確認するために使用されるTLSメソッドに必要なすべてが含まれていなかったため、脆弱性が発生した可能性があります信頼できる接続を保証する情報。
この場合、私の意見では、TLSプロトコルの実装にCCSの問題を防ぐために十分な小さな変更がありました。 上で述べたように、CCSメッセージはパフォーマンス上の理由から確認プロトコルの一部ではありません。 CCSは確認応答メッセージには適用されません（ただし、確認応答プロセスの重要な部分ですが）。したがって、クライアントとサーバーがすべての確認応答メッセージを送受信し、これらのメッセージが変更されていないことを確認するように設計された確認応答整合性チェックプロセスには含まれません出荷中。 その結果、攻撃者はCCSメッセージを追加および削除できますが、当事者がメッセージの受信時間を制御しない場合、検出されるという脅威はありません。
確認応答の整合性を検証するために使用されるデータにCCSを含めることにより、問題を防ぐことができたと思います。 これが行われた場合、攻撃者がこの場合に使用する追加のCCSメッセージは整合性チェックに違反し、クライアントとサーバーは互いに異なる値を受け取ることができるため、正しい値を相互に送信できなくなります。コンプライアンス違反により接続し、脆弱性を排除します。
影響を受ける製品
この攻撃は、OpenSSL 1.0.1（-1.0.1h以前）を使用して脆弱なサーバーと通信する場合、OpenSSLを使用するどのバージョンのクライアントでも機能することが既に知られています。 バージョン1.0.1で実際に攻撃ホールが作成されたため、古いバージョンのOpenSSL（pre-0.9.8zaまたはpre-1.0.0m）を使用してサーバーに接続するOpenSSLクライアントが危険にさらされているかどうかはまだわかっていません。検証手順の簡素化。
OpenSSLクライアントは、組み込みブラウザーとアプリケーションの両方を備えたAndroidデバイスで広く使用されているため、これらのデバイスのソフトウェアを更新する必要があります。 さらに、Linux / KDEで人気のあるKonquerorベースのブラウザーでも、OpenSSLを使用して、メモリが適切に機能する場合にTLSをサポートします。 OpenSSL TLSスタックは、少なくとも電子メール、チャット、認証、SSLベースのVPNネットワーク、および以下を使用して記述されたさまざまなスクリプトで、サーバーおよびクライアントによって（特にLinuxで、他のプラットフォームでも）使用できます。 Pythonまたは他の言語。 ユーザーは、パッチが入手可能になり次第、このソフトウェアを更新する必要があります。
OpenSSLスタックに基づいていないクライアントは脆弱ではありません（Opera 12ブラウザーを含みます。Opera12ブラウザーは暗号プリミティブのみにOpenSSLを使用し、同時に独自のTLS実装を使用します）。
皮膚軟化剤
この脆弱性では、クライアントとサーバーの両方が脆弱であることが必要です。 したがって、問題を回避したいユーザーは、この脆弱性の影響を受けないクライアントまたはクライアントバージョンを使用していることを確認するだけで済みます。
この脆弱性はどれほど危険ですか？
この脆弱性はHeartbleedほど危険ではないと言えますが、 Renegoの問題よりも深刻だと思います。 Heartbleedは、秘密鍵を含むサーバー上の個人データへのアクセスを提供しましたが、Renegoは、接続の開始時にリクエストとデータの注入を「のみ」許可しました。 この新しい問題により、攻撃者は接続に接続できるため、この脆弱性は予備的なデータ注入よりも深刻ですが、サーバーからのデータ漏洩よりも深刻ではなく、接続が切断されていない秘密鍵またはユーザーデータを攻撃者に与える可能性があります。
影響を受けるサーバーの数
利用可能な情報、特にGoogleで働いているAdam Langleyの情報と例を使用して、TLS Testerスキャナーの新しいテストを追加し、540,000サーバーの通常の実験グループをスキャンして、この問題の影響を受けたサーバーの数を見つけました。
脆弱性が公開されてから1週間後に受け取ったデータによると、スキャンされたサーバーの17.3％はOpenSSL 1.0.1の脆弱なバージョンを使用しているため、明らかに脆弱でしたが、別の37.8％はOpenSSLバージョン1.0.0以前の脆弱なバージョンを使用しており、したがって、理論的に脆弱です。 合計で、選択したサーバーの約55％は信頼性が低く、修正する必要があります。
この問題が今後数週間または数か月でどれだけ早く修正されるかを見るのは興味深いでしょう。
Vivaldi.netの状況
ApacheとOpenSSLをTLSに使用するVivaldi.netのサーバーについて言えば、パッチが利用可能になった直後に修正され、現時点では問題の影響を受けないことに注意してください。
翻訳者から
実際、このトピックは私にはあまり似ていないので、おそらく翻訳の用語に矛盾があります。 元の記事を読むことに興味のある方全員を招待します。