私は「SSL 2.0非推奨プロトコル」についてクラスにプレゼンテーションを行っていますが、このエクスプロイトがどのように使用されるのか、または攻撃者がこの脆弱性をどのように使用できるのか、私にはまったくわかりません。この脆弱性の影響を理解していますが、この脆弱性がどのように機能するか、および攻撃者が中間者攻撃を実行したり、影響を受けるサービスとクライアント間の通信を解読したりするための手順について完全に説明する必要があります。可能であれば、攻撃者が使用できるプロセスを具体的な説明で説明してください。
SSL 2.0は脆弱性ではありません。これはprotocolであり、構造的な脆弱性が含まれているため、許可されるべきではありません。
[〜#〜] rfc [〜#〜] があり、SSL 2.0の既知の主な欠点を示しています。
SSL version 2.0 [SSL2] deficiencies include the following: o Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. o Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would normally choose. o Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm. o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.
4つのうち、最後のものだけがreallyプロトコルの構造上の深刻な問題です。確かに:
MD5はcollisionsに関しては壊れていますが、整合性を保護するためにSSL 2.0でどのように使用されるかなど、他の使用法では依然として非常に強力です。
攻撃者がクライアントとサーバーをだまして弱い暗号スイートを使用する場合、本当の問題は攻撃者がクライアントとサーバーをだますことができるということではありません。それは、クライアントとサーバーが実際に弱い暗号スイートを使用するagreeであることです。
暗号化と整合性に同じキーを使用する点は、クライアントとサーバーが弱い暗号化を使用することに同意した場合にのみ意味があります。これは、米国の輸出規制に準拠しているため、昔は発生する可能性がありましたが、2000年以降はすべてなくなりました。
検証済みの終了がないことは、SSLを使用してメッセージが自己終了しないプロトコルを伝達する場合の問題です。典型的なケースはHTTP 0.9です。サーバーが接続を閉じるため、クライアントは完全なファイルを取得したことを認識します。 SSL 2.0では、アクティブな攻撃者が早期に接続を強制終了する可能性があり、クライアントはこれが本物のファイルの終わりか、悪意のある切り捨てかを知る方法がありません。
最近のHTTPでは、この問題は当てはまらないと主張する人もいます。
したがって、実際には、クライアントとサーバーが現在SSL 2.0を使用している場合(2014年5月)、これは実際の問題ではない(または、少なくとも、最大のセキュリティ問題ではない)可能性があります。 SSL 2.0が禁止されている本当の理由は、SSLが長い間(1996年以降、SSL 3.0の発明以来)廃止されているためです。 SSL 2.0の問題は、関連するソフトウェアの一部が少なくともその期間アップデートされていないことを示しています---それが問題です。 SSL 2.0は栄光 canary です。
または、別の言い方をすると、SSL 2.0を使用または許可すると、ずさんな、時代遅れの無能なシステム管理者であることがわかります。