web-dev-qa-db-ja.com

Diffie-Hellmanグループの値を保持する必要がありますか?

私は、Diffie-Hellmanに対するLogjam攻撃と、最近の調査結果に基づいてTLCベースのWebサーバーを保護する方法について読んでいます。

guide は、UniqueDiffie-Hellmanグループを作成することを提案しています。私がプロトコルを理解しているように、このグループは1つのTLS接続に対してのみ同じでなければなりません。つまり、プロトコルの観点からは、同じクライアントであっても、新しいTLS接続が確立されるたびにグループが生成される可能性があります。 (ただし、新しいプライムを作成するために必要な計算時間とリソースにより、これは実用的ではありません。)

これが意味することを確認したいと思います。

  1. 生成されたグループを永続化する必要はありません。サーバーが停止し、グループがサーバーとともに停止しても、損失はありません。
  2. ワイルドカード証明書を使用している場合でも、サブドメインが異なればグループも異なります。
  3. ブラウザは、このグループへの変更についてユーザーに警告しません。
1
David V

あなたの推論は正しいです。実際、それらは逆に表現されることがよくあります。各インスタンス(TLSハンドシェイク)は独自のグループを使用しますが、インスタンス間で同じグループを再利用することは可能です。それらが同じサーバー用であるか、別のサーバー用であるか。 Logjamのビジネスはすべて、weakグループを使用するクライアントとサーバーに関するものでした(モジュラスが短すぎるため)。多くのサーバーによるそのグループの再利用は、攻撃の範囲を拡大しただけです。

グループと証明書またはドメインの間には何の関係もありません。グループパラメータはハンドシェイクごとにサーバーから送信されるため、クライアントはそのグループについて何も覚えておく必要はありません。実際には、クライアントはグループについて何も覚えようとしないため、特別なことは何もしません。特定のグループが再利用されるか、再利用されません。

ただし、グループの生成には少々費用がかかることを考慮に入れる必要があります。 OpenSSLは「安全な素数」を使用することを主張しているため、必ずしもOpenSSLが行うほど長くはありません。これは、ここではやり過ぎです(そして、用語が単に従来型)。それでも、新しいグループの作成はCPUの数秒の問題であるため、着信接続ごとに作成する必要はありません。実行できるのは、サーバーの起動時に新しいDHパラメーターを生成することです。したがって、パラメーターをファイルに保存する必要はありません。

実用的には、既存のWebサーバー(Apacheなど)はファイルからパラメーターを読み取ることができ、リンクするガイドは、サーバーに固有のDHグループを生成することを提唱しています。独自のグループを生成する主な価値は、strongグループを生成できることです。つまり、十分に大きい係数を使用できます。グループが他のサーバーと共有されていないことは、二次的に重要です。

楕円曲線の場合、デプロイされた実装はその特定の曲線(*)に特化しているため、全員が同じグループ(つまり同じ曲線)で作業することに注意してください。他は処理できません。グループの再利用が本当に問題である場合は、楕円曲線をできるだけ早く非アクティブ化する必要があります。幸いなことに、再利用は問題ではありません。

(*)実際には2つの曲線、NISTのP-256とP-384、これらは NSA Suite B ;の一部です。何らかの理由で、このスイートは、ブラウザベンダーによって、手紙に従うために、ある種の福音としてますます取り上げられています。そうしないと、神々があなたを稲妻で襲うでしょう。

2
Tom Leek

すべての点で正しい。使用されている特定のグループは、サーバー(またはユーザー)のIDとは関係がなく、いつでも変更できます。

今のところ2048ビットのグループで十分です。独自のグループがある場合、コンピュータが2048ビットの速度で動作する場合でも、リソースを使用して攻撃に必要なすべての事前計算を行うことはほとんどありません。実行可能です。それは長い間非常に高価な攻撃になるでしょう。

したがって、作成した後で変更する必要はありませんが、何らかの理由で再生成する必要がある場合でも、害はありません。

SRPはパスワード認証されたDHスタイルのプロトコルであり、グループパラメータを変更すると、すべてのユーザーのベリファイアが無効になります(そのため、パスワードが機能しなくなります)。これはDHの動作方法ではありません(通常、DHグループから独立した別のメカニズムを使用して、サーバーのみが認証されます)。

0
Steve Peltz