☰

SSLv3 固有の CBC 暗号の削除

tag-icon • tag-icon ssl openssl
SSLv3 固有の CBC 暗号の削除

SSLv3 を使用する必要があるレガシー アプリケーションがあるため、POODLE 脆弱性に対する一時的な解決策として、SSLv3 固有の CBC 暗号を無効にする必要があります。OPENSSL のドキュメントを参照したところ、SSLv3 と TLSV1 の間で次のような共有暗号があるようです。

  • SSL_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA
  • TLS_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA

私の質問は、例えば、無効にする方法はありますか？DHE-RSA-DES-CBC-SHASSLv3 専用ですが、このアクションは TLSv1 に影響しますか?

私はOpenSSLでnginx、Varnish、Apacheを使用しています

答え1

この設定はWebサーバーで行う必要があります。OpenSSLでは、この文書で述べられているように、暗号をプログラムで指定することしかできません。SEの回答。

Apache と nginx を使用しているとのことなので (Web キャッシュ Varnish は SSL をサポートしていません)、BEAST 向けではありますが、同じ問題について説明している次のページを見つけました。

  1. Apache-Nginx と OpenSSL の設定
  2. ウェブサーバーの OpenSSL 暗号スイートの強化

これはSSL終了これにより、varnish はコンテンツをキャッシュできるようになります。


非常に重要な追伸:

PS1 - 忘れずに使用してくださいHSTS
PS2 - 暗号化された接続内で生成された Cookie には常に「Secure」フラグを設定してください。これを忘れると、攻撃者に情報が漏洩する非常に簡単な方法になります。

答え2

標準的な答えはhttps://security.stackexchange.com/questions/70719/ssl3-poodle-脆弱性そして、プロトコル暗号ではなく SSLv3。

予備的に、あなたが挙げた2つの異なる暗号スイートは、オリジナルのDESとレトロニムを使用しています。シングルDES、そしてすべてのプロトコルバージョンで安全ではないオリジナルのDESは10年前に置き換えられ、撤回されました。（より正確には、FIPS46-3は2001年にFIPS197 AESに置き換えられ、その後2005年に撤回され、シングルDEAではなくトリプルDEAのみが2004年にSP800-67として承認されましたが、標準ではありませんでした。）これらはopensslの暗号構成でLOWに分類されており、EXPORT（さらに安全性が低い）およびeNULL（完全に安全でない）とともに一度もない古い火星着陸船のように、アップグレード、交換、またはフロントエンド化ができない、非常に時代遅れのシステムを扱う必要がない限り、構成は不要です。

あなたの質問に対して、SSLv3固有のCBC暗号は実際には存在しませんが、非-SSLv3のもの。opensslでは、許可された暗号スイートとプロトコルの設定は別々で、ほぼ独立しています。私の知る限り、唯一の制約は、新しいTLSv1.2機能（認証された暗号化GCMまたはSHA-2ハッシュ）を使用する暗号は、古いプロトコルでは選択できないことと、SSLv2で使用されていたが1996年にすでに安全でなかったためSSLv3+コードが割り当てられなかったいくつかの暗号は、SSL3+では使用できないことです。標準によれば、暗号の唯一の違いはSSL3 と TLS1 または 1.1 の違いは次のとおりです。

  • 40ビットのEXPORT暗号は1.1で正式に削除されましたが、opensslは1.1と1.2で拡張機能としてまだサポートしています。しかし、それらは安全ではなく、1990年代にタイムトラベルして1990年代の法的制限に従わない限り、使用すべきではありません。いくつかの場所は次のとおりです。

  • Fortezza鍵交換は、「暗号は武器」時代に米国政府をなだめるために追加され、おそらくNSA以外には誰も使用しなかったが、TLS1によって削除された。これはopensslでは実装されていない。どれでもプロトコル。

  • ECC暗号の最初のバッチhttps://www.rfc-editor.org/rfc/rfc4492TLS1+にのみ正式に適用されます。ClientHelloとhttps://www.rfc-editor.org/rfc/rfc3546拡張機能はSSL3を変更できませんでしたが、openssl >=1.0.0（または調整されている場合は0.9.8）では、拡張機能をデフォルトで「制限なし」として扱うことでSSL3に実装されています。ただし、ピアが同意した場合のみであり、意図的に変更された最近のopenssl以外のピアはおそらく同意しません。これはおそらく役に立つ唯一の暗号の違い。RSA 証明書と秘密鍵を想定すると、ECDHE-RSA を使用して、TLS1+ でのみ機能することを期待できます。

このため、コマンドラインopenssl ciphers -v [$cipherstring]ユーティリティでは、ほとんどの暗号の「バージョン」として SSLv3 が表示されます。これは、SSLv3 以上を意味します。

要約:SSL3のみのクライアントがECC暗号をネゴシエートしない場合（ほとんどの非常に古いクライアントはおそらくECC暗号をネゴシエートしませんが、新しいクライアントはそうするかもしれません）、そしてすべてのTLS1+クライアントする(これはあまり確実ではありませんが)、RSA 証明書と秘密鍵の一般的なケースを想定すると、ECDHE-RSA-(3DES または AES)-CBC を有効にして、DHE-RSA-anything-CBC と RSA-anything-CBC を無効にすることができます。これにより、Perfect Forward Secrecy も実現されます。

必要に応じて、PFS の有無にかかわらず、すべての SSL3+ に対して RC4 を有効にすることもできますが、ここでも懸念事項があります。

あなたの「レガシー アプリケーション」は Web ですか、それとも他のものですか? Web なら、そこそこまともなブラウザーを入手できないのですか? カスタム アプリが、攻撃者のデータの後に同じ機密データを繰り返し再送信できないのであれば、そもそも「攻撃可能」ではありません。

関連情報