web-dev-qa-db-ja.com

誰かがDHパラメータの生成によって正確に何が達成されるかを説明できますか？

私はnode.jsサーバーを設定しています：

https.createServer({
    ...
    ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
    honorCipherOrder: true
}, app).listen(443);

これは、SSLLabs Aレーティングを達成することができ、優れています。現在、ハンドシェイクシミュレーションのすべてのネゴシエーションはTLS_RSA_WITH_RC4_128_SHAを使用して実行されているようです。

RC4はBEASTに対して回復力があります。 BEASTに対して脆弱である場合、Aレーティングを取得できません。

クライアントでサポートされている場合は、PFS（転送秘密）をサポートしたいと思います。

私が読んだことに基づいて、Diffie-Hellmanパラメータを生成して「何らかのランダムさを生成する」必要があり、サーバーが転送秘密のためにECDHEを適切に実装する前に、それを何らかの方法で証明書に取り込みます。 ECDHEはDHEよりもCPU負荷が低いため、それはプラスです。

さて、私は多くの質問があります。しかし、最初の質問をします。

なぜ 「ランダム性」を生成する を証明書に追加する必要があるのか​​、それがどのような目的で機能し、コマンドが実際に何をするのか dhparamのOpenSSLページ では、実際に何が行われているのかはあまりわかりません。

私は この答え を見て、より明確な説明（または少なくとも関連する参考文献への参照！）を探しています。

OpenSSL Ciphers によると、ECDHEはTLS 1.2暗号のようです。 QualysのPFSページ ECDHEはすべての主要な最新のブラウザーでサポートされていると記載されていますが、TLS1.2を介して接続しているSSLLabsテストの結果にはiOS6しか表示されません。塩の粒で「ハンドシェイクシミュレーション」セクションを取ることができると思います。

別の質問は、暗号リストにHIGHエントリを残した場合、SSLLabsがAと評価する理由です。これにより、サーバーは接続をサポートします。 TLS_RSA_WITH_AES_128_CBC_SHA（レポートは多くを示しています）、これはBEASTに対して脆弱です！おそらく、RC4サポートを報告しない「クライアント」でテストしたことがないためです。

もう1つの質問：OpenSSL CiphersページのTLS 1.2暗号スイートの下のリストには、次のものが含まれます。

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256

これは、CBCの使用により、現在BEASTに対しても脆弱なECDHEと接続することを示していますか？例えば。私はこれをGoogleと同じように切り替える必要があります：ECDHE with RC4。ただし、[暗号]ページにはECDHE-RSA-RC4-SHAのような内容は含まれていません。ただし、ECDHE-ECDSA-RC4-SHAがあります。これはどう違うのですか？編集： this SO answer は、ECDSAがRSAとは別のものであることを言及しています。GoogleがECDHE_RSA + RC4 + SHAで行っていることを、そのように再現したいと思いますパフォーマンスとセキュリティの完璧な融合。

その他のメモ（特に、誤解していることがある場合は、質問として偽装されたステートメントを教えてください）：

BEASTの回復力は、対称暗号（RC4対AESなど）の選択によって制御されます。 CBCを使用しないAESのモードは多くのクライアントでサポートされていませんか？つまり、AESを完全に回避する必要があります...？ PFSは、Diffie-Hellman鍵交換を使用して取得でき、DHEまたはECDHEを含むモードのみがこれを満たします。 OpenSSLのみが完全転送秘密をサポートしています。 RC4はAESより高速です。 RC4はAESより優れています（BEASTのため）？

別の編集：見てみましょう... ここ は、BEASTがtooに現実的に懸念されるものではないことを示しています。 SSLLabsの評価に悪影響を及ぼします。その大きな "A"はとてもよく見えます...見てみましょう...他に理由がないので、RC4_128暗号を暗号チェーンの最初に配置する必要があります。 AESよりも一般的に高速です。とにかく、元のトピックであるECDHEから遠く離れています。また、DHパラメータをNode/Expressで適切に機能させるにはどうすればよいですか？

tlsaesopensslrc4diffie-hellman
35
Steven Lu

SSLにおける従来のRSAベースの交換は、ランダムなセッションキーが生成され、非対称暗号化を使用して送信されるため、秘密キーの所有者のみがそれを読み取ることができるという点で優れています。これは、会話が証明書の秘密鍵を持たない限り、誰も復号化できないことを意味します。しかし、第三者が暗号化されたトラフィックを保存し、最終的に秘密鍵を取得した場合、それを使用してSSL交換からセッション鍵を復号化し、それを使用してセッション全体を復号化できます。つまり、これはではなく完全な転送秘密です。

Perfect Forward Secrecyの鍵は Diffie-Hellman鍵交換 です。 DHは、2つのパーティ間で共有キーを生成するための非常に優れたアルゴリズムであり、すべて-2つのパーティ間の完全なやり取りを見るオブザーバーは、ワイヤーを介して送信されたものからのキー。導出された秘密鍵は一度だけ使用され、保存されたり送信されたりすることはなく、誰も二度と操作することはできません。言い換えれば、完全な前方秘密です。

IDも認証もないため、中間者でプレーするのは簡単なので、DHだけでは保護できません。したがって、認証に引き続きRSAを使用し、Diffie-Hellmanを使用してセッションキーを生成できます。それはDHE-RSA-*、たとえば：DHE-RSA-AES128-SHA1は、Diffie-Hellmanを使用してキーを生成する暗号仕様で、認証にはRSA、暗号化にはAES-128、ダイジェストにはSHA1を使用します。

ただし、Diffie-Hellmanでは、最初にいくつかのセットアップパラメータが必要です。これらは秘密ではなく、再利用できます。さらに、生成に数秒かかります。ただし、攻撃者から提供されていないことがわかるように、ユーザーが生成した「クリーン」なものでなければなりません。 dhparamステップは、事前にDHパラメータ（ほとんどの場合、単一の大きな素数）を生成し、それをサーバーが使用できるように保存します。

最近のいくつかの調査では、DH交換を「解読」すること（つまり、トラフィックからキーを導出すること）は困難ですが、その困難な作業のかなりの量を素数に基づいて事前に実行できることが示されています。これは、同じDH素数がどこでも使用されている場合、それらが計算を実行するための十分な資金のある機関の「素数」ターゲットになることを意味しています。これは、独自の素数を（ソフトウェアに付属する素数に依存するのではなく）生成し、おそらくそれらを再生成するときに、ある程度の安全性の向上があることを示唆しています。定期的にプライムします。

おもしろいのは 楕円曲線Diffie–Hellman は、従来のRSAスタイルの大きな素数の代わりに楕円曲線暗号を使用する修正Diffie-Hellman交換であるということです。したがって、必要なパラメータがある場合はそれがどのようなものかはわかりませんが、生成する種類が必要だとは思いません。

以下も参照してください。

BEASTに関して
BEAST攻撃は、古いバージョンのSSLのAESで使用されるブロックチェーン方式のいくつかのアーティファクトに依存しています。 SSLの新しいバージョンは適切に機能するため、心配する必要はありません。 RC4はブロック暗号ではないため、ブロックチェーンはありません。 BEAST攻撃を引き離すのは非常に難しいので、その実際の影響は明らかに存在しません。実際、RC4にはいくつかの弱点があります。特に、BEAST攻撃が行う方法を悪用した場合はそうです。したがって、実際にはより良いセキュリティを得られない可能性があります。

TLS 1.2を強制すると、理論上のセキュリティ問題がすべて解決すると同時に、多くの訪問者が実際に接続することができなくなります。 ECDHEを使用することとまったく同じではありません。

37
tylerl

「DHE」暗号スイートでは、サーバーはオンザフライで新しい Diffie-Hellman 鍵ペアを生成し、RSAまたはDSAまたはECDSA秘密鍵で公開鍵に署名し、それをクライアント。 DHキーは「エフェメラル」です。つまり、サーバーはそれをディスクに保存しません。それはRAMにSSLハンドシェイクの期間中保持し、その後完全に忘れます。保存されないため、後で盗むことはできません。それが [〜＃〜] pfsです。 [〜＃〜] の由来です。このDHビジネスは証明書を入力しないことに注意してください。サーバー証明書には、RSA、DSA、またはECDSAタイプのサーバーの永続公開鍵が含まれています、および署名にのみ使用されます。

Diffie-Hellmanは一般的に、計算が簡単である 有限グループ で計算されるアルゴリズムですが、 離散対数 は困難です。 「プレーンな」DHでは、グループは大きな素数pを法とする整数で構成され、乗法はグループ法則です。 DHパラメータは、そのグループの定義、つまりビッグプライムpと従来のジェネレータg。セキュリティ上の理由から、他のユーザーと同じDHパラメーターを使用するなど、いくつかのキーペアに同じパラメーターを再利用しても問題はありません。必要なのは、パラメータが「公平」であること、つまり素数pがランダムに生成され、素数を法として離散対数を簡単にできるように特別に作成されていないことです。

独自のDHパラメーターを生成することは、適切にランダムなDHパラメーターを使用することを「確認」する方法です。ただし、科学的というよりは儀式的です。SSLサーバーライブラリにはデフォルトのDHパラメータが付属しているはずであり、すでに定義上、悪質なトリックを行わないことをSSLライブラリに信頼しています。

[〜＃〜] ecdhe [〜＃〜]は同じ行に従いますが、別のグループ、つまり ellipticカーブ 。楕円曲線には計算上の利点がありますが、（まだ）あまりサポートされていません。独自のDHパラメータを生成するのと同様に、独自のランダム曲線を選択します。次の理由により、実際にそうする人はいません。

  • 適切な特性を持つランダム曲線を生成することは、複雑で費用のかかる作業です。
  • 楕円曲線の計算上の利点は、特定の曲線用に最適化されている両方の部分（クライアントとサーバー）から部分的にもたらされます。独自のランダムカーブを生成すると、それは無効になります。

BEASTについては、あまり気にしないでください。これはサーバーではなくclientに対する攻撃であり、最近のクライアントには回避策（特に「1/n-1分割」）が含まれています。ニース攻撃ですが、動作しなくなりました。サーバーがそれについてできる唯一のことは、認識されていない古いクライアントにRC4を強制的に使用させることでした（これは構造的に脆弱ではありません）。

BEASTはSSL 3.0およびTLS 1.0にのみ適用されることに注意してください。 TLS 1.1および1.2では、対称暗号がCBCモードのブロック暗号であっても、BEASTはまったく機能しません。

11
Thomas Pornin

RC4はBEASTに対して回復力があります。

ストリーム暗号を使用するとBEASTとPOODLEを回避できることは事実ですが、RC4にはそれ自体の問題があります。キーストリームには既知のバイアスがあり、情報が漏洩する可能性があります。

RC4は、獣が発見された後、RC4のキーストリームバイアスの問題がいかに深刻であるかが認識されるまでの間、一時的に推奨されました。

BEASTに対して脆弱である場合、Aレーティングを取得できません。

これは、ある時点で本当だったかもしれませんが、もうありません。

良質な人たちは、獣をRC4よりも害が少ないと判断します。

証明書に追加する「ランダム性」を生成する必要があるのはなぜですか。証明書の目的は何ですか。また、コマンドは実際には何をするのですか。 dhparamのOpenSSLページでは、実際に何が行われているのかはあまりわかりません。

dhparamは、従来のdiffie-hellman（ECDHではない）に使用されるパラメーターを生成します。これらのパラメータは秘密ではありませんが、DHが安全であるためには、いくつかの条件を満たす必要があります。独自のパラメーターを生成する必要がある理由はいくつかあります。

  1. ソフトウェアに付属のパラメーターが短すぎる可能性があります。 1024ビットdhは公表されていませんが、資金のある攻撃者が破壊した可能性があります。
  2. Dhをクラックする作業の多くは、セッションごとではなく、パラメータのセットごとです。したがって、他のすべてのユーザーと同じパラメータを使用すると、攻撃者は自分の作業を再利用して、さまざまなサーバーからの多くのセッションをクラックできます。
  3. パラメータを生成したエンティティによって簡単にクラックされる可能性があるが、他の人には問題なく見えるバックドアパラメータを作成することが可能です。より偏執的な人は、ソフトウェアに付属するパラメータがバックドアされていることを心配するかもしれません。

Afaict RC4を使用するDHE暗号スイートはありません。したがって、構成でこれが問題になるのは、クライアントが明示的に識別した暗号スイートのいずれもサポートせず、代わりに「HIGH」リストの従来の「DHE」暗号スイートのいずれかを使用することになる場合です。

クライアントでサポートされている場合は、PFS（転送秘密）をサポートしたいと思います。

前方秘密を取得するには、DHEまたはECDHE暗号スイートを使用する必要があるため、前方秘密を優先する場合は、これらを他の暗号スイートよりも優先する必要があります。最高の互換性とパフォーマンスを得るには、対応するDHE暗号スイートの前にECHDE暗号スイートを配置する必要があります。

最後に、暗号スイートリストをソフトウェアにハードコーディングする前に、慎重に検討してください。どのオプションが最適であると考えられるかは、時間とともに変化します。

0
Peter Green

NSAは、PRNG（乱数のもの）ノブブルを攻撃しました。それだけではない公正な賭けですPRNGここでは、調査する価値がある米国以外のハードウェアベースのランダムジェネレーターを示します。 http://www.entropykey.co.uk/

0
anon