DROWNとは何ですか？
攻撃を理解するには、20世紀後半のブライヘンバッハーの攻撃を思い出す必要があります。その攻撃では、攻撃者はターゲットサーバーをOracleとして使用します。 RSAベースの鍵交換を使用する場合、クライアントは PKCS＃1 v1.5パディングを使用してサーバーの公開鍵で暗号化された秘密値（「プレマスターシークレット」）を送信することになっています「タイプ2」）。ブライヒェンバッハーの攻撃は、適切に暗号化されたメッセージの代わりに注意深く作成された値を送信し、サーバーの反応を観察することに依存していました。サーバーは（ほとんどの場合）「処理しましたが、適切なPKCS＃1 v1.5タイプ2パディングを生成しませんでした」というエラーで応答する場合があります。しかし、場合によっては、復号化が機能しているように見え、サーバーは取得したものを続行します。攻撃者はその動作の違いを理解しているため、秘密鍵に関する情報を少し得ています。 100万回程度の接続の後、攻撃者は任意の復号化を実行し、以前に記録されたセッションを破壊するのに十分知っています。
この攻撃は同じ種類ですが、SSL 2.0の特異性に依存する新しい手法が使用されています。 SSL 2.0は古いプロトコルバージョンであり、重大な欠陥がいくつかあるため、使用しないでください。 15年以上にわたって非推奨になっています。それは正式にさえ 禁止 2011年にありました。それにもかかわらず、一部の人々はまだSSL 2.0をサポートしています。さらに悪いことに、暗号化強度が約40ビットに低下している、いわゆる「エクスポート」暗号スイートでサポートされています。
したがって、攻撃は次のように機能します：
攻撃者は、RSAキー交換を使用する暗号化されたSSL/TLSセッション（最新の堅牢なセッション、たとえばTLS 1.2）を観察し、それを復号化したいと考えています。説明されているように、すべてのSSL/TLSセッションが攻撃の影響を受けやすいわけではありません。攻撃が機能する確率は約1/1000です。したがって、攻撃者は約1000の暗号化されたセッションを収集する必要があり、最終的にそれらの1つを突破します。著者は、CRIMEとBEAST（バックグラウンドで目に見えない接続をトリガーする敵意のあるJavascript）のような設定では、このコレクションを自動化できると主張しています。
サーバーは、SSL 2.0システムに同じRSA秘密キーを不注意に使用します（同じサーバー、または別のプロトコルを実装する可能性のある別のソフトウェアシステム、たとえばメールサーバー）。攻撃者は、他のシステムと通信を試みる可能性があります。
攻撃者はそのシステムとSSL 2.0ハンドシェイクを開始し、
ClientMasterKeyメッセージとして、攻撃者が復号化したい値から派生した値を使用します。彼はまた、40ビットのエクスポート暗号スイートの使用を求めています。攻撃者はサーバーの応答を監視し、サーバーが攻撃者から送信された値を解読したときに得た40ビットの値を総当たりします。その時点で、攻撃者は自分の細工された値をサーバーが秘密鍵で処理した結果の一部を知っています。これにより、攻撃者が本当に関心を持っている暗号化されたメッセージに関する情報が間接的に得られます。
攻撃者は、ターゲットセッションから暗号化されたプレマスターシークレットを復元するために、ステップ3および4を数千回程度実行する必要があります。
数学的詳細については、 記事 を参照してください。
アプリケーションの条件：
接続はRSA鍵交換を使用する必要があります。説明したように、この攻撃は、DHEまたはECDHE鍵交換を使用する接続に対してはあまり効果がありません（いずれにしても forward secrecy に推奨されます）。
SSL 2.0を実装し、攻撃者がアクセスでき、さらに「エクスポート」暗号スイートのネゴシエーションを受け入れるシステムでは、同じ秘密鍵を使用する必要があります。
注：OpenSSLが使用され、 CVE-2015-3197にパッチされていない の場合、 "export "暗号スイートが無効になっている場合でも、悪意のあるクライアントは、無効にされた暗号スイートとの交渉とハンドシェイクを完了できます。攻撃者は、SSL 2.0システムに数千程度の接続を確立し、それぞれに40ビットのブルートフォースを実行できる必要があります。総計算コストは約250 オペレーション。
それはよく理解されなければならない50 攻撃者が解読しようとする各接続のための努力です。たとえば、観察した接続からクレジットカード番号を読み取る場合は、クレジットカード番号ごとに無視できない量の作業を行う必要があります。攻撃は非常に深刻ですが、CCNを取得する設定では実際には実用的ではありません。
解決策：SSL 2.0を使用しないでください。 Dammit。以前のミレニアムでは、SSL 2.0の使用を停止する必要がありました。 「使ってはいけない、弱い」と言ったら、本当の意味です。目を覚ましてあなたの仕事をする時が来ました。
弱い（「エクスポート」）暗号スイートをサポートすることも賢明なことではありませんでした。何だと思う ？弱い暗号は弱いです。
SSL 2.0を非アクティブ化することが、問題を修正する唯一の正しい方法です。その間、 SSL 3. も非アクティブ化します。
（そして、攻撃にすべて大文字の頭字語を使用するその方法は本当にばかげています。）
トーマスの答えは素晴らしいです。控えめに思われることが1つだけあります。電子メールサーバーは、セキュリティの観点から壊れています...デフォルトで、設計上。
- default：たとえば、デフォルトの
postfix構成を確認するだけです（ヒント：SSLv2と40〜56ビットの暗号は依然として重要であり、「暗号化なし」でもあります）。 設計による：
StartSSL不思議について聞いたことがありますか？まあ、それはSMTP（「電子メール」プロトコル）で暗号化を実現する唯一の非推奨の方法ではありません。StartSSLのすばらしい点は、誰も聞いていないときは通常強力ですが、誰かが読みたい場合はデフォルトでclear textに簡単に設定できることです...または、誰かが代わりにHTTPSを読みたい場合はSSLv2...¯\ _（ツ）_ /¯
SMTPレルムの人々の心の状態といくつかの設定の垣間を見るには there を参照してください。 postfixにSSLv2を無効にする単一のフラグなどは存在しないことに注意してください（まあ、1つありますが、サーバーがSSLv2を受け入れて後で応答しても、驚かないでください）。
それは質問とどのように関連していますか？
必要なだけWebサーバーを強化できます。有効な証明書でSMTPサーバーを実行している場合、同じ "DROWN"攻撃に対して脆弱である可能性が高くなります。さらに悪いことに、あなたのWebサーバーも多すぎます...ふつう：いくつのSMTPサーバーが共有しているかに驚かれるでしょうHTTPサーバーの証明書。また、いくつかの「スタンドアロン」SMTP証明書の有効性ドメインにも驚かれるでしょう。
ソリューション？
SMTPサーバーを適切に構成します（そしてsslyzeなどの外部ツールで構成を確認します）- または、
SMTPを完全に無効にします。 - または、
SMTPを使用して自己署名/サブドメイン固有の証明書を使用します。