web-dev-qa-db-ja.com

FREAK TLSの脆弱性に照らして、なぜそれほど多くのサーバーがRSA-EXPORTキーを提供するのですか？

Ars Technicaは reporting で、HTTPSに対する新しい攻撃に取り組んでいます。 FREAKと呼ばれる、脆弱であると報告されたデバイスには、iPhone、Androidデバイス、およびOS Xを実行しているMacが含まれます。攻撃は（以下で説明されているように、@ bonsaivikingに感謝します）、アクティブなMITMが変更する可能性があります。クライアントとサーバー間のTLSネゴシエーション。サーバーにEXPORT強度の暗号スイートのみを提供します。これにより、調節サーバーがEXPORT強度のキーを選択するように仕向けます。MITMは、クライアントへの返信が正常に見えるようにしますが、より低い値を使用します。強度キー。脆弱なクライアントは、交渉中にそのオプションを提供していなくても、この低い強度キーを受け入れます。これは明らかに十分に安全ではないため、ブルートフォースされる可能性があります。

これらのキーが非常に多くのデバイスとサービスでまだアクティブなのはなぜですか？特にAppleデバイス-私たちは皆、時代遅れのテクノロジーを迅速に削減する方法を知っています。米国からの暗号の輸出が緩和されると、これらの弱いキーは、ケースのようです。

さらに読む： Matthew Greenによるブログ投稿 、 公式ウェブサイト（投稿したとおりに表示されます） 、 Hacker Newsスレッド 。

tlsattacksman-in-the-middlebrute-force
9
JoltColaOfEvil

あなたの質問、なぜ輸出暗号群を提供する多くのサーバーが有効であるのかについては、問題の説明に誤りがあります。フリークは：

  • クライアント側のバグのクラス
  • サーバー側の設定により悪用可能。

リストする脆弱なデバイスはnotであり、エクスポートグレードの暗号スイートを使用するように設定されていますが、標準（「フル強度」）の暗号スイートでエクスポートグレードのキー長を使用するようにだまされる可能性があります。シナリオは次のように機能します。

  1. 脆弱なクライアントは、サポートされている暗号スイートを含むプレーンテキストのClientHelloメッセージを送信しますが、どれもEXPORTではありません。
  2. 攻撃者はClientHelloを傍受し、暗号スイートをEXPORTに置き換えます。
  3. サーバーは、EXPORT暗号スイートの1つを選択し、長さが短縮されたエクスポートキーで応答します。サーバーがEXPORT暗号スイートを使用するように構成されていない場合は、代わりに致命的なアラートが発行され、接続が停止します。
  4. 攻撃者は、ServerHello応答を変更して、EXPORT暗号スイートを非エクスポートバージョンに置き換えますが、弱いキーはそのままにしておきます。
  5. バグのため、クライアントはエクスポートキーを受け入れ、脆弱なTLS接続をネゴシエートします。

明らかにもっと微妙なことが関係しており、Matthew Greenはそれらを説明するのに素晴らしい仕事をしていますが、これらは基本的な事実です。

8
bonsaiviking

他の多くのものと同様に、後方互換性のためにWebが根本的に壊れているため、これらのキーはまだアクティブです。テクノロジーベンダーは、正しいことをすることと、すでにあるものをサポートすることのどちらを選択するかということに行き詰まっていることがよくあります。

GoogleとAppleがこれをサポートしていないWebブラウザーを出荷した場合の騒動を想像できますか？非難は、より新しいテクノロジの使用を拒否するサーバーにあるのではなく、非難はApple and Google。

90年代のネットスケープ/インターネットエクスプローラー戦争の際にも同様のことがありました。

4
Damian Nikodem

デフォルトの暗号セットに単純に、そして場合によっては（不可解なことに）それらを有効にし続けているという理由だけで、エクスポートグレードの暗号をサポートする多くのサーバーがあります。 TLS 1.1（セクションA.5） の変更点の1つは、エクスポートグレードの暗号をTLSv1.1で使用してはならないことを明記することでした。 TLS 1.0（セクションD.4） 必要なセキュリティレベルを決定するのは実装に任されています。

Apache httpdのデフォルトのSSLCipherSuite は、 "DEFAULT"という値で、openssl-1.0.2までは、コンパイルされたほぼすべてが含まれ、匿名認証の暗号セットのみが除外されますまたはnull暗号化。ただし、httpd-2.4.7（2013年11月）以降、エクスポートグレード（およびaNULL/eNULL）暗号は_mod_ssl_によって削除され、SSLCipherSuiteを使用して復元することはできません。この変更は2.2に移植されていません。 httpd-2.2.21（2011年9月）までは、デフォルトの構成ファイルで "LOW"暗号が明示的に有効になっており、 "EXPORT"（40）が暗黙的に有効になっており、 "EXPORT56"のみが無効（おそらく見落とし）になっています。

問題の原因として考えられるのは、Apache-2.2をかなり最新の状態で実行しているが、古い構成ファイルを使用している人です。

しかし、攻撃の説明は完全ではありません。 「Export grade」は、「128ビット未満」を意味する場合が多いと解釈されます。真の輸出グレードの暗号では、鍵交換でより短い輸出グレードの鍵/係数を使用する必要がある場合もあります。 SSL/TLS暗号には2つの異なるタイプのキーがあり、ほとんどの人は小さな（40ビットまたは56ビット）キーを使用するエクスポート暗号に慣れています。これは対称鍵サイズのみを参照し、RC4やDESなどの対称暗号にのみ使用されます。もう1つのキータイプは、対称キーを安全に交換するために使用される非対称キーです。

米国の輸出規制 は対称暗号鍵のサイズだけに影響するのではなく、非対称鍵のサイズにも影響します。

暗号化輸出管理：ライセンス例外ENCおよびマスマーケット適格性の修正、提出手順、報告要件、ライセンス申請要件、およびカテゴリー5、パート2への注記4の追加

[...]

a.1.a. 56ビットを超えるキー長を使用する「対称アルゴリズム」。または

a.1.b.アルゴリズムのセキュリティが次のいずれかに基づいている「非対称アルゴリズム」：

a.1.b.1。 512ビットを超える整数の因数分解（RSAなど）。

サーバーにRSA 1024ビット（またはそれ以上）の鍵がある場合、通常のRSAベースの鍵交換（暗号化操作）を持つすべてのエクスポート暗号では使用できません。なんらかの方法で512ビットの鍵にダウングレードする必要があります。 （ただし、署名鍵は512ビットを超える鍵を使用できます。）

_$ openssl ciphers -v "kRSA" | egrep "(512|1024)"
EXP1024-RC4-SHA         SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC4(56)   Mac=SHA1 export
EXP1024-DES-CBC-SHA     SSLv3 Kx=RSA(1024) Au=RSA  Enc=DES(56)   Mac=SHA1 export
EXP1024-RC2-CBC-MD5     SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC2(56)   Mac=MD5  export
EXP1024-RC4-MD5         SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC4(56)   Mac=MD5  export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
_

kx=RSA(512)は、key-exを意味します変更は固定サイズのRSA 512ビットであり、証明書のサイズ（より正確には、係数のサイズ）とは無関係です。 RSA 1024ビットエクスポート暗号（EXPORT56）はここではそれほど興味深いものではありませんが、2048ビット以上の証明書で使用すると潜在的な弱点となります（ただし、OpenSSLから長い間削除されています）。

ハッシュ出力や対称鍵とは異なり、非対称鍵（モジュラス）を単純に半分に切ることはできません（RSAアルゴリズムの背後にある数学はもはや成り立たなくなります）。そのため、代わりに 一時的なRSA鍵が使用されます 。このキーは、サーバーの実際のRSAキーで署名され、オプションの ServerkeyExchange （タイプ0x0C）メッセージで交換されます。 （RSA証明書だけでは交換を完了するために必要なデータが含まれていないため、DHE鍵交換でも同様のステップが発生します。）

これは、_EXP-EDH-RSA-DES-CBC-SHA_のようなエクスポート暗号で確認できます。

_$ openssl ciphers -v EXP-EDH-RSA-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
^^^^^^^
_

ここで興味深いのは_EXP-EDH_です。追加のServerKeyExchangeには、短い（512ビット）EDHキーが含まれています。 DHも問題かどうかは Matthew Greenの議論 からは明らかではありません。 RSA Kx is 問題です。セッションをキャプチャして ssldump を実行するとどうなるかを確認できます。

_$ Sudo tcpdump -s1520 -c 18 -w insecure-rsa.pcap Host www.insecure.com and port 443 &
$ openssl s_client -showcerts -connect www.insecure.com:443 -cipher EXP-RC4-MD5 -msg
[...]
$ ssldump -VAN -r insecure-rsa.pcap
[...]
1 4  0.0245 (0.0000)  S>CV3.1(205)  Handshake
  ServerKeyExchange
    params
      RSA_modulus[64]=
        b4 3c e4 c5 f2 9b 8b 8e ef 6e 29 4e 5d 80 78 1c 
        1d e8 80 0f 65 32 a0 a6 be d4 35 a6 09 6b 2c 15 
        f2 80 e7 cd 22 9b 01 21 1e 7b 13 12 95 34 03 16 
        7b 9a 66 79 4e d1 6d 15 28 3d 73 45 91 85 a0 c1 
      RSA_exponent[3]=
        01 00 01 
    signature[128]=
      c6 09 b9 14 88 94 6d 06 82 84 e6 af eb af 72 fc 
      fd c6 d5 09 63 a8 f5 f8 e7 3a 79 69 14 9f 24 0e 
      ed dd 71 4b c4 8d 99 51 7c e6 1f aa af ea b2 b9 
      05 04 3c db 31 40 8d 11 f8 94 73 26 a5 5c 2f 28 
      84 49 77 62 3c 27 90 51 52 9f ab 61 6c 12 cd 49 
      9e ab ad f5 bf 2b f7 9c 1b 1e 05 a2 40 f6 7c 60 
      b3 8b 1d 8a 2f 4c bb 1e b0 04 ed 42 a8 14 95 55 
      7c b1 54 ff a2 3e e2 98 f4 15 96 7a 48 c4 a6 8c 
_

（ssldumpは少し古く、いくつかの問題がありますが、これには問題ありません。）

ここでの64バイトのRSA係数は「512ビット」の問題であり、RSA鍵交換の証明書と同等ですが、ブルートフォース分解が可能です。

実行可能な攻撃には、特定のサーバーとクライアントの動作が含まれます。

  1. サーバーは、RSAを使用してエクスポートグレードの暗号をサポートする必要があります（デフォルトで有効になっている可能性があります）。これを使用する場合、サーバーは弱い（<= 512ビットモジュラス）キーも使用できる必要があり、実際の（強力な）鍵で署名することにより、モジュラスを保護します。
  2. リアルタイムの分解は実行できないため、サーバーは中長期の一時的なRSAエクスポートキーを使用する必要があります（Apacheがこれを行います）。
  3. 攻撃者は、エクスポートグレードの接続を確立して弱いRSAパブリックモジュラスを取得し、モジュラス（約8時間、100ドル）を因数分解してから、新しいモジュラスに置き換える必要があります。攻撃者はこれを使用してサーバーになりすますことはできませんが、クライアントが使用する場合、サーバー向けのデータを解読できます。

  4. 攻撃者は、誤ってエクスポートグレードキー（RSAモジュラス）を受け入れるクライアントをMITMする必要があります。これは、エクスポート暗号が有効でなく、クライアントハンドシェイクになかった場合（OpenSSLおよび=が壊れている場合） Appleクライアントがこれを行います）。

    • 攻撃者は、RSAエクスポート暗号のみを含めるようにClientHelloを変更する必要があります（TLSでは、サーバーはクライアントリストから暗号を選択します）。エクスポート（一時）キーは、実際の（長期）サーバーキーによって署名されている必要があります（攻撃者持っていない）。
    • 攻撃者は、ServerHelloを変更して、クライアントの期待に応える（つまり、元のRSA非エクスポート暗号の1つを使用する）必要があります。
    • 攻撃者は、弱い512ビットモジュラスで（状態から）ServerKeyExchangeを送信します。実際のサーバーキーで署名されているため、クライアントはこれを信頼します
    • エクスポートグレードのRSAキーはハンドシェイクの正しい段階で表示されるため、クライアントはエクスポートグレードのRSAキーを受け入れます。 TLS状態マシンが欠陥のためにそれを処理します 、その後、証明書の実際のキーではなくそれを使用します。
  5. 攻撃者はプレマスターシークレットを取得し、一時的なRSAキーで暗号化されてクライアントから送信されます。その後、攻撃者はマスターシークレットを計算できます（プレマスター、およびハンドシェイクで以前に交換された他のデータを使用）。
  6. これで攻撃者はマスターシークレットを取得し、有効な「終了」メッセージを計算して送信できます。どちらの側も接続の干渉を検出できません。ゲームオーバー。

この問題は2つのことの組み合わせです。

  • エクスポートグレードの暗号化サポートを備えた誤って構成されたサーバー。これには、弱い一時的なRSAキーの使用が必要になります。
  • ハンドシェイクで示されたエクスポート暗号を使用する接続を開始していなくても、それを受け入れる欠陥のあるクライアント。 （クライアントは暗号を提供するように構成する必要はありませんが、クライアントのSSL/TLSライブラリーは実装が存在している必要があります。）

（別の問題もあります。エクスポートグレードの暗号が使用されているため、各クライアント接続は40ビットまたは56ビットなのでブルートフォースになる可能性がありますが、RSA部分を壊す方がより便利で興味深いものです。）

歴史的に、RSAキーの素数の生成には時間がかかりました。これがおそらく、Apacheが起動時に一度だけ生成する理由です。最新のハードウェアでは、最大で数ミリ秒しかかかりません。 古いApache-sslソース （Apache-1.3.x時代、mod_ssl-2.0より前）には、このユーモラスなリファレンスがあります。

_#if SSLEAY_VERSION_NUMBER >= 0x0920
/* FIXME: This ought to generate a new key from time to time - why make the
Feds' life easy? */
static RSA *TmpRSACallback(SSL *pSSL,int nExport,int nKeyLength)
{
static RSA *pRSA512=NULL;
static RSA *pRSA1024=NULL;

ap_log_error(APLOG_MARK,APLOG_DEBUG|APLOG_NOERRNO,
         SSL_get_ex_data(pSSL,EX_DATA_SERVER_REC),
         "Generating %d bit key",nKeyLength);
_

このFIXMEは修正されませんでした。Apache-1.3でも mod_ssl-2.8 を使用して、鍵の再利用/再生成に関するTLS仕様の推奨を自由に引用（および無視）しました。最後に、エクスポートRSAサポートは、2013年9月にdevブランチ（httpd-2.5になる）で 完全に削除されました でした。

3
mr.spuratic

エクスポート暗号のサポートなどの古い残骸を取り除くことは、コードを維持する必要がないため、多くの場合、コスト削減策と見なされます。このような古いコードは、しばしば潜水艦のようです。それ自体が知られていない限り、または誰かが特にそれを探しているのでない限り、検出は困難です。付録のようになります。比較的役に立たず、なくても簡単に暮らすことができますが、削除するのは手間がかかります。それを保つことは努力を必要としません。誰かが問題について積極的に考えていない限り、通常は努力が勝ちません。問題が存在する場合でも、知識が必要です。

この時点で、下位互換性のトレードオフは本質的に存在しません。米国の暗号輸出法はほぼ20年前の1996年に撤廃されました。サーバーは長年にわたって強力な暗号をサポートしており、この脆弱な暗号のみをサポートするサーバーの数は確かに非常に少ないです。

1
Steve Sether