web-dev-qa-db-ja.com

2015年以降のエフェメラルDiffie-Hellman暗号の使用

私の会社のTLS標準を決定する際に、なぜすべての推奨事項がまだTLS_DHE_xxxで始まる一時的なDiffie-Hellman TLS暗号の使用を提案するのか不思議に思いました。

背景と研究

多くの研究をした後、私は以下を発見しました。

  • TLS_DHE_xxx暗号スイートは実際にはあまり使用されていません-Alexa.comの上位10サイトのうち1つのサイト（Wikipedia.org）のみが実際に使用しています。他のどれもせず、代わりにTLS_ECDHE_xxxまたはTLS_RSA_xxx暗号に依存します。このことから、これらの暗号を使用しないことによって影響を受けるブラウザーはそれほど多くないことが推測できます。それ以外の場合、これらの大規模なサイトはユーザーを遮断します。
  • 私が調べた「エンタープライズ」Webサーバー製品はTLS_DHE_xxx暗号スイートをサポートしていません。 Oracle iPlanet Webサーバー、Oracle HTTP Server（OHS）およびIBM HTTP Server（IHS）はこれらのスイートをサポートしていません。 （OHS/IHSはどちらもApacheに基づいていますが、どちらもOpenSSLではなく独自のTLS実装を使用します。）これらの暗号スイートのサポートが重要である場合、これらのエンタープライズ製品はそれらをサポートする必要があります。
  • 提案された暗号スイートの「事実上の」ソースはMozilla Server_Side_TLS guide のようですが、このドキュメントの目的は、Mozillaシステム管理者がさまざまなMozillaサイトを構成するのを助けることです。それは本来、その役割に分類されていたとしても、インターネット全体の一般的な標準になることを目的としていませんでした。また、このドキュメントではTLS_DHE_xxx暗号が必要な理由については触れていません。
  • LogJam攻撃が広まったため、システム管理者はDHパラメータが正しく調整されていることを確認する必要がありました。この暗号がreallyでない場合、これは無駄な作業です。単に暗号を削除するだけで、後で問題が発生する可能性がなくなります（たとえば、誰かが新しいTLSリスナーを作成し、DHパラメータを忘れたとします）。
  • 今後数年間で、インターネットはECDSA証明書に移行します。 ECDSA証明書をサポートするTLS_DHE_xxx暗号スイートはありません（TLS_ECDHE_xxx暗号スイートのみがサポートしています）。これを考えると、これらの暗号スイートはとにかくなくなると思われます。

  • Ssllabs.comのブラウザーでサポートされている暗号スイートを見ると、同等の楕円曲線よりもTLS_DHE_xxx暗号を選択する重要なブラウザーがないことが明らかです。 TLS_DHE_xxx暗号をサポートするWikipedia.org上のすべてのブラウザーは、代わりにTLS_RSAまたはTLS_ECDHE暗号スイートを選択します。

    これに対する注目すべき例外は、Android 2.3.7以下、IE 8、Java 6u45およびOpenSSL 0.9です。 8y。これらのうち、Android 2.3.7、OpenSSL 0.9.8yおよびJava 6u45はTLS_DHE暗号を選択し、さらにその後、後者は1024ビットを超えるDHパラメータをサポートしません（LogJam攻撃から推奨されます）IE 8 on XPは、 TLS_DHEは暗号化されているため、このコンテキストではブラウザは無効です。

    事実上、上記の段落の結果、TLS_DHE_xxx暗号化を有効にする唯一の利点は、Android 2.3.7およびOpenSSL 0.9.8yクライアントは、パーフェクトフォワード機密。これらのフリンジケースクライアントがこれらの暗号をサポートする唯一の理由であることが私の発見です。これが確かに事実である場合、将来的には、明示的に希望しない限り、これらの暗号スイートを含めることには意味がないようです。これらのブラウザのPFSをサポートします。これらのブラウザはすべて、正しい暗号が利用可能であればPFSなしでTLS_RSA_xxx暗号を使用して接続します。

編集：

MikeとMichałからいくつかの素晴らしいフィードバックを受けた後、この質問に答えるときに考慮したい点を私の研究にさらにいくつか追加することにしました。

どちらも有効な点を提起しましたが、私の意見では、今日私たちが知っているように、インターネット上で一般的に考えると、どちらもやや「フリンジ」なケースを指しています。

  • EC暗号の信頼問題。

    私は最初の調査でこれを検討しましたが、元の質問に追加するのを忘れていました。一部の人々は、RFC 4492で定義されている標準のEC曲線を信頼していません。これは、私の質問に多くの可能な結果を​​もたらす可能性があります。

    1。サーバーの所有者はECDHE暗号を信頼しませんが、DHE暗号とともに有効のままにします（Mozilla TLSガイドによる）。この場合、DHE暗号は上記のフリンジケースブラウザー以外では使用されません。

    2。サーバーの所有者はECDHE暗号の信頼性について何の見解もなく、クライアントがECDHEを信用しない場合に備えて、DHE暗号をそこに残します。この場合、ECDHEを無効にする唯一のユーザーは、NSAの関与のためにそれらを信頼しない上級ユーザーである可能性があります。また、そのようなユーザーは完全転送秘密を必要とするため、 DHE暗号のみを使用するように制限されています。ただし、インターネット上のWebサーバーの半分はDHE暗号を使用していないため、これらのユーザーはほとんど何もするのに苦労します（そして、彼らは上級ユーザーなので、Googleやスタック交換または最も上位のサイトにアクセスします）。

    これは、「典型的な」Webサイトで検討する必要がないユーザーのフリンジケースのようです。

    。サーバーの所有者がECDHE暗号を完全に信用しない場合は、DHE暗号のみを有効にするのではなく、単に有効にする必要があります。これは、DHE暗号を使用するのに適したシナリオです。ただし、DHEのみをサポートしてECDHEをサポートしていないサイトはまだ見つかりません。

    これにより、これは「フリンジケース」のように見え、通常のTLS設定には適用されません。 ECDHEの信頼性が問題である場合は、代わりにDHEを検討する必要があるということは、どのような規格でも確かに主張できます。

  • 曲線の互換性の問題

    「Supported Elliptic Curves Extension」がどのように機能するかについて学習したので、これがDHE暗号を使用する際の考慮事項であることがわかります。しかし、これはまだフリンジケースだと感じています。次のシナリオを検討してください。

    1。サーバーの所有者は、一般的なブラウザでは広くサポートされていないカスタム曲線を使用したいと考えています。彼女は、カスタム曲線を指定し、標準曲線もそのままにしておくTLS構成を使用します。この場合、カスタム曲線をサポートしないブラウザーは、引き続きECDHEと標準曲線を使用して接続します。上記の旧式のフリンジケースクライアントを除き、どのブラウザもDHEを使用して接続しないため、それらを指定する必要はありません。

    2。サーバーの所有者はonly一般的なブラウザで広くサポートされていないカスタム/非標準曲線を使用したいと考えています。彼女は、標準曲線ではなくECDHEのカスタム/非標準曲線を指定するTLS構成を使用します。現在のほとんどのブラウザーはカスタム/非標準曲線をサポートしておらず、PFSを維持するためにDHEにフォールバックする必要があります。これは、優れたECDHE曲線をサポートしないもののフォールバックとしてDHE暗号をサポートするための良いシナリオです。一般的なTLSサーバーではそのような構成が（まだ）許可されていないため、これはまだ周辺的な問題だと感じています。

    今後、より多くのサーバーが、使用する曲線を指定するオプションをサポートし始めるようになれば、これはフリンジケースとは言えなくなります。

概要：

私はこれらの暗号を含める、または除外する理由でしばらく探していましたが、自分で行った自分の研究以外には何も思いつきませんでした。私は何かが欠けているに違いないと感じざるを得ないので、私の質問はこれです：

  • 上記を踏まえ、2015年以降の一般的な使用のために、現代のTLS構成でTLS_DHE_xxx暗号を使用する必要があるという有効かつ現在の理由はありますか？
tlsdiffie-hellman
6
Tom17
  1. 一部のサーバーは、Curve25519、Curve448、またはP-521のような曲線を使用する場合があります。それをサポートしないクライアントは、代替の鍵交換方法を必要とします。
  2. 一部の人々は、P-256やP-384などのNSAに恵まれたNIST曲線を信頼せず（ SafeCurves で理由を確認してください）、より安全な曲線が採用されるまでECDHEをブロックしたいと思うかもしれません。
  3. 一部の人々はECCをまったく信用しておらず、DHEは（SFAIK）ECCなしのPFSを持つ唯一の実行可能な代替手段です。
  4. LogJamは、弱いdhparamを使用した結果であり、DHE自体の問題ではありません。
  5. ECDSAがRSAシグニチャーを置き換えるか（あるいはすべきか）はよくわかりません。 RSA署名の作成は低速ですが、署名検証はECDSAの場合よりも高速です。また、ECDSA実装に関連するいくつかの失敗があり、秘密鍵の開示（PS3、OpenSSL、Android）が発生しました。科学的な観点からの問題ではありませんが、現実の世界では、考慮すべきテクノロジー関連のリスクです。

PS ECDHEとDHEはどちらもポスト量子の世界では役に立たないため、キーを検討するときは [〜＃〜] sidh [〜＃〜] （ポスト量子暗号のPFS）のようなソリューションを検討する必要がありますもう少し遠い将来にメソッドを交換します。

5
Michał Staruch

NSAまたは他の機関によって侵害されたと信じて、ECDHEに使用される曲線を信頼しない人もいます-たとえば このコメント を参照） Bruce Schneier氏は、ECCではなく従来の離散ログ暗号を優先するようになったと述べています。ECDHEを信頼できない場合は、DHEが完全な前方秘密を提供する唯一のアルゴリズムであるため、推奨される選択肢です。

2
Mike Scott

最初に、暗号スイートの選択がどのように機能するかについてのメモ。

  • クライアントは、優先順位の高い暗号スイートのリストを送信します。
  • サーバーはそのうちの1つを選択して、セッションに使用します。

標準によると、サーバーはクライアントの好みを尊重することになっています。実際には、サーバーは、サーバー管理者が（正しいか誤っているかを問わず）サーバーよりもクライアントの方がよく知っていると信じているため、クライアントの設定を無視する傾向があります。

私が次の目標を持つサーバー管理者であるとします。

  1. 私はそれをサポートするすべてのクライアントに転送機密性を求めています。
  2. クライアントがサポートする最高の対称暗号化が必要です。
  3. サーバーで1つの証明書を使用したいのですが、個別のRSA証明書とECDSA証明書を混ぜて使用するのではありません。

プライバシーを重視するサーバー管理者にとって、これらの目標は珍しいとは思いません。

これらの基準が与えられ、SSLラボによると、DHEはいくつかのギャップを埋めます。

  • 何らかの奇妙な理由でIE 11には、いくつかの暗号の組み合わせがありません。RSAベースの認証（通常の証明書を使用できるようにするため）をサポートしています。AESGCMをサポートし、ECDHEをサポートしています。しかし、いくつかの奇妙な理由により、3つの組み合わせをサポートしていないようです。
  • Andriod 2.x（まだ憂鬱なほど一般的）はDHEをサポートしていますが、ECDHEはサポートしていません。

素数が十分に大きいDHEは安全ではないと考える理由はないので、サポートされている場合は有効のままにしておきます。

有効になっている場合は、十分に大きい素数を使用する必要があります。私の一般的なガイドラインは、DSAをRSAキーと同じサイズにすることです。

通常、DHE暗号スイートは、対応するEDHE暗号スイートのすぐ下に優先順位で配置します。

1
Peter Green