Logjam という名前の「新しい」TLS脆弱性があると聞きましたが、それは何をし、どのようにそれを防ぐのですか?
TL; DR
SSL/TLSクライアントとサーバーは、いくつかの弱い暗号を使用することに同意します。さて、弱い暗号はweakであることがわかります。
詳細
SSL/TLSプロトコルが実行されると、クライアントはサポートされている暗号スイートのリストを送信し、サーバーはそれを選択します。最初のハンドシェイクの最後に、いくつかのFinished
メッセージが交換され、新しくネゴシエートされた暗号アルゴリズムで暗号化/保護されます。これらのメッセージのcontentsは、先行するすべてのメッセージのハッシュです。
アイデアは、アクティブな攻撃者(a MitM attack )がクライアントから送信された暗号スイートのリストを操作して、すべての「強力な」暗号スイートを削除し、クライアントとサーバーの両方の最も弱いものだけを保持することです。サポート。ただし、これによりFinished
メッセージが壊れます。したがって、これらのメッセージは、(他の役割の中で)そのようなダウングレード攻撃を検出することを目的としています。
理論的には、それは問題ありません。クライアントとサーバーの両方が非常に弱い暗号スイートをサポートしていない限り、MitM攻撃者はそれを破ることができますすぐに、暗号化レイヤー全体を解明し、Finished
メッセージをリアルタイムで修正します。ここで何が起こるかです。
さらに詳しく
「DHE」暗号スイート(「Diffie-Hellman Ephemeral」など)を使用する場合、サーバーはクライアントとサーバーが実行する「DHパラメーター」(モジュラスとジェネレーター)を送信します Diffie-Hellman鍵交換 。さらに、サーバーはそのメッセージにプライベートキー(実際にはRSAを使用しているため、通常はRSAキー)を使用してメッセージに署名します。クライアントはその署名を検証し(公開鍵はサーバー証明書にあるものです)、DHパラメータを使用して鍵交換を完了します。
たまたま前世紀には、暗号に関する米国の厳格な輸出規制があり、これが「輸出暗号スイート」、つまりこれらの規制と互換性のある弱い暗号を促しました。多くのSSLサーバーは、依然としてこれらの「エクスポート暗号スイート」をサポートしています。特に、DHEを使用し、512ビット以下のDH係数を要求する一部の暗号スイート。さらに、SSLライブラリで提供されるものを使用する方が独自のSSLを生成するよりも簡単なので、サーバーのほとんどのSSLはsame係数を使用します。他の人と同じ係数を再利用することは大きな問題ではありません。 DHはそれを問題なく許容します。ただし、攻撃者が特定の係数を使用する1つのDHインスタンスを破壊するために多くの計算に投資する場合、pであれば、同じ攻撃者が同じことを使用する他のインスタンスを破壊するためにほぼすべての作業を再利用できることを意味します。係数p。
したがって、攻撃は次のように実行されます。
Finished
メッセージを修正します。Logjamアーティクル 作成者は、これを「プロトコルの欠陥」と呼んでいます。これは、エクスポートDHパラメータを含むServerKeyExchange
メッセージが「for export」としてタグ付けされておらず、識別できない(係数の長さを保存する)ためです。非エクスポートDHパラメータを含むServerKeyExchange
メッセージ。しかし、本当の欠陥はそこにはないと言います。実際の問題は、クライアントとサーバーがどちらも弱いことを知っていても、クライアントとサーバーが512ビットのDHモジュラスの使用を受け入れることです。
どうすればよいですか?
ええと、いつもと同じことです。ソフトウェアベンダーからパッチをインストールしてください。実際のところ、これは言うまでもありません。
クライアント側では、MicrosoftはInternet Explorerにパッチを適用して、小さすぎる係数の使用を拒否しています。 Mozillaによるプラグインの形でのFirefoxの修正が利用可能です here 現在。他のブラウザーベンダー(Opera、Chrome ...)が間もなく続くと予想されます。
サーバー側では、「エクスポート」暗号スイートのサポートを明示的に無効にして、独自のDHパラメータを生成できます。詳細は そのページ を参照してください。 IIS
は、これらすべての影響を受けないことに注意してください。これは、DSSサーバー証明書以外でDHE暗号スイートをサポートすることはなく、誰もDSSサーバー証明書。
[〜#〜] ecdhe [〜#〜]暗号スイートでは、「EC」は「楕円曲線」を意味しますが、ここではリスクがないことに注意してください。
そしてNSA?はどうですか?
Logjamの研究者たちは、「国家国家の資源を持つ攻撃者」がどのようにして1024ビットDHを突破できるかについてのいくつかの話を含んでいます。これはかなりストレッチです。私の経験では、国民国家には確かに多くのリソースがあり、それを使うのは得意ですが、それはハード暗号を解読することに成功したのと同じことではありません。
それにもかかわらず、1024ビットDHが「弱すぎる」と恐れる場合は、2048ビット(とにかくこれが推奨されるビット)またはECDHEを使用してください。
または、圧倒的なリソースを持つ人々が本当に圧倒的なリソースを持ち、単純な係数サイズに負けないことを単に受け入れてください。クラッキングマシンに数十億ドルを費やすことができる人は、数百ドルで子供に賄賂を渡して、コンピューターファイルと財布を調べることもできます。
Logjamは、実際には「新しい」脆弱性と呼ばれるべきではありません。これは、FREAKのリハッシュであり、輸出グレードのRSAではなく輸出グレードのDHを対象としています。
実際の悪用は、次の欠陥に依存しています。
攻撃は本質的に、攻撃者がDH実装のTLSサービスで使用されていることがわかっているターゲットプライムのデータセットを事前計算することを可能にします。 512ビットDHの場合、これには約1週間かかることが知られています。これが完了すると、攻撃者は1回の交換あたり約1〜2分でそのサービスとのDHキー交換を中断できます。交換が壊れると、攻撃者はセッションキーにアクセスできるようになり、すべてのトラフィックを解読できるようになります。
この問題は、次の方法で修正できます。
補足として、このバグの興味深い要素の1つは、TLSおよびIKE(VPN)トラフィックの復号化の分野でNSAが報告した機能と一致することです。大量のトラフィックのキャプチャと復号化の場合、既知の共有素数に関連付けられている可能性が高い大量のデータを利用できるため、事前計算攻撃は特に効率的で効果的です。
利用可能な詳細:
Logjamは暗号のダウングレード攻撃で、中間にいる人がエンドポイントをだまして弱い暗号を使用させることができます。暗号が弱いと、途中の男が傍受したトラフィックを簡単に解読できるようになります。
他のすべての暗号ダウングレード攻撃と同様に、それを防ぐ最善の方法は、最初に弱い暗号を無効にすることです。弱い暗号が使用できない場合、成功した暗号のダウングレードでも強力な暗号化が行われます。
Logjamを防ぐには、サーバー(Apache HTTPサーバー、nginx、IIS、Lighttpd、Tomcat、Postfix、Sendmail、Dovecot)を構成するのに役立つ TLSのDiffie-Hellmanの導入ガイド の推奨事項に従ってください。 、HAProxy、OpenSSH、Amazon Elastic Beanstalk):
Mozilla SSL Configuration Generator も優れた構成ツールです。