web-dev-qa-db-ja.com

HTTP2のブラックリストに載っている暗号について

私はしばらくの間、NginxサーバーでHTTP2サポートを実行するよう取り組んでいます。この時点で、サポートする暗号の選択に行き詰まっています。うまくいけば、あなたが私がこれを理解するのを助けることができます。

HTTP2の動作を始める前に、大多数のブラウザーのサポートを維持しながら、 SSLlabs で最高のスコアを取得することを趣味にしました。したがって、私は256ビットの暗号のみをサポートし、128ビットの暗号はリストしませんでした。

HTTP2を有効にしてから、Windows上のFirefox（およびおそらく他のブラウザー/プラットフォーム）のサポートを失いました。これはプライベートサーバーであるため、Javaのサポートを失っても問題ないことに注意してください。SSLlabsブラウザーシミュレーションによると、XPおよびAndroid 2.3です。

SSLlabsによると、Windows上のFirefoxバージョン45および46はサーバーへの接続に失敗します。表示されるメッセージは次のとおりです：サーバーはブラックリストに登録されたスイートとHTTP/2をネゴシエートしました。結果によると、Firefoxのこれらのバージョンでは、暗号TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAが選択されています。クイック検索の結果、ServerFaultで このトピック が表示され、RFCで ブラックリスト の暗号が指定されていることが説明されました。

これは私が設定した暗号リストです：

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:kEDH+AESGCM:CAMELLIA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!CAMELLIA+RSA:!AES128:@STRENGTH;

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAは、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256をssl_ciphersディレクティブに追加すると、Nginxの優先順位が高くなるため、@STRENGTH（現在の構成でFirefoxによって使用されます）よりも強力であると私は信じています。それでも、最初のリストはブラックリストに記載されており、2番目のリストは記載されていません。

最良のサポートを得るためにどの暗号を選択する必要があるかについて、いくつかのトピックがすでにここにあることを認識しています。ただし、この投稿では、なぜをよりよく理解しようとしているのですか？.

tlsciphershttp2
3
Evy Bongers

として あなたがリンクしたrfc4880付録 は言う

  Note: This list was assembled from the set of registered TLS
  cipher suites at the time of writing.  This list includes those
  cipher suites that do not offer an ephemeral key exchange and
  those that are based on the TLS null, stream, or block cipher type
  (as defined in Section 6.2.3 of [TLS12]).  Additional cipher
  suites with these properties could be defined; these would not be
  explicitly prohibited.

TLSで使用される唯一のストリーム暗号はRC4であり、RC4に対する攻撃は過去数年間で事実上爆発しているため、ストリームスイートはブラックリストに登録されています。 rfc 7465 を参照してください。

CBCスイートはTLS-nee-SSLとして認識されるため、ブラックリストに記載されています MAC-then-encryptの使用は不適切な選択でした （これが最初に明確に認識される前に、Asiacrypt 2000のBellare＆Namprempreが一部）オンラインプロトコルでMTEとCBC（パディングが必要）を組み合わせてすると、POODLEやLucky13などのパディング-Oracle攻撃が可能になるためです。 POODLEはSSL3を大幅に破壊しますが、SSL3はすでに公式に廃止されており、POODLEはついにそれを排除するよう動機付けました。 Lucky13は正確なタイミングを必要とし、現在はあまり実用的ではありませんが、かなり改善される可能性のあるアプローチを示しています。 （SSLおよびTLS1.0でCBCの公開されたIVを使用することもBEASTを許可しましたが、その部分は1.1および1.2で修正されています。）

Null暗号はブラックリストに登録されます。これは、それらの望ましくないことは明らかであるためです。

これにより、少なくとも現時点ではAEADスイートのみ、実際にはGCMのみが残ります。 AEADにはTLS1.2が必要ですが、これはまだ普遍的に実装されていないため、SSLLabsなどの一般的なテストでは、CBCモードを受け入れてサーバーやクライアントが1.1と1.0を使用できるようにします（ただし、上記のSSL3は使用できません）。 Chromeは、1.2以外のものをAEADおよび一時鍵交換で「廃止された暗号」として説明するために使用され、security.SXはそれについてかなりの数のQを持っていますが、再テスト（51.0.2704.84） TLS1.2とAEADがすでに導入されているはずのHTTP/2はすでに導入されているはずですが、それよりも要求が厳しい場合があります。

私たちが実用的な量子コンピューターを得ない限り-人々が今心配しているのでなければ非常に大きい-AES-128とAES-256の間の強度の違いは無意味です。それは、「私たちの銀河では壊れませんが、何十億年もの間宇宙全体を制御している誰かによって壊れる可能性がある」と「宇宙全体でさえ壊れない」の違いです。猫の動画のコレクションがどれほどひどくても、長い間死んでいて、すべての子孫が死んでいて、すべての人間が死んでいて、私たちの惑星と太陽系がもはや存在しなくなった後で、復号化されていても気にしないでください。

（HTTP/2で追加された他のすべてのメディア機能を考えると、猫のビデオを禁止したり、少なくとも深刻に制限したり、低下させる機能を追加しなかったことに失望しています。まあ、常にX-があります。）

4
dave_thompson_085

暗号化アルゴリズムは、キーを知らなくても元の入力を出力から隠すことを目的としています。理想的には、キーの任意のビットを変更すると、出力のいくつかのビットが変更され、明らかに予測できないパターンで変更されるはずです。ブラックリストに記載されたアルゴリズムは慎重に分析され、かなりの数のキービットに対してこの特性が欠けていることがわかりました。これが、特定のアルゴリズムの「有効ビット強度」がよく表示される理由であり、通常はキーのビットよりも小さくなります（多くのアルゴリズムは常にいくつかのビットをリークするため）。つまり、出力がランダムであるほど、効果的です。

たとえば、特定のアルゴリズムの256ビットキーでは56ビットのセキュリティしか得られない可能性がありますが、別のアルゴリズムの128ビットキーでは96ビットのセキュリティが得られる可能性があります。このように分解すると、サイズが半分であるため、128ビットキーが256ビットキーよりも優れていることが簡単にわかるため、2128 可能な値の観点からsmaller。これが "xor暗号化" が弱いと見なされる理由の1つです。特定の条件が満たされない限り、簡単に関数を出力に適用し、キーと入力を推測できます。

HTTP/2が特定のアルゴリズムをブラックリストに載せる理由は、近い将来に実行可能な強力な暗号のベースから始めるためです。アルゴリズムを継続的にブラックリストに載せることはできず、すべてのサーバーとクライアントがリアルタイムでリストに追いつくことを期待できます。したがって、すでに破られているか、近い将来破られる危険性のある暗号を拒否することで、コンピューティングの指数関数的成長に対処する時間が増えます。

1
phyrfox