web-dev-qa-db-ja.com

SSLを使用してサーバーに接続するクライアントが、最小ビット数の暗号を使用するのはなぜですか？

2つの異なるApache2セットアップをテストしました。

最初のケースでは、無料の証明書を提供する http://letsencrypt.org/ が提供するリストを使用しました。リストは次のようになります。

SSLHonorCipherOrder     on
SSLCompression          off
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256
               :ECDHE-ECDSA-AES128-GCM-SHA256
               :ECDHE-RSA-AES256-GCM-SHA384
               :ECDHE-ECDSA-AES256-GCM-SHA384
               :DHE-RSA-AES128-GCM-SHA256
               :DHE-DSS-AES128-GCM-SHA256
               :kEDH+AESGCM
               :ECDHE-RSA-AES128-SHA256
               :ECDHE-ECDSA-AES128-SHA256
               :ECDHE-RSA-AES128-SHA
               :ECDHE-ECDSA-AES128-SHA
               :ECDHE-RSA-AES256-SHA384
               :ECDHE-ECDSA-AES256-SHA384
               :ECDHE-RSA-AES256-SHA
               :ECDHE-ECDSA-AES256-SHA
               :DHE-RSA-AES128-SHA256
               :DHE-RSA-AES128-SHA
               :DHE-DSS-AES128-SHA256
               :DHE-RSA-AES256-SHA256
               :DHE-DSS-AES256-SHA
               :DHE-RSA-AES256-SHA
               :AES128-GCM-SHA256
               :AES256-GCM-SHA384
               :AES128-SHA256
               :AES256-SHA256
               :AES128-SHA
               :AES256-SHA
               :AES
               :CAMELLIA
               :DES-CBC3-SHA
               :!aNULL
               :!eNULL
               :!EXPORT
               :!DES
               :!RC4
               :!MD5
               :!PSK
               :!aECDH
               :!EDH-DSS-DES-CBC3-SHA
               :!EDH-RSA-DES-CBC3-SHA
               :!KRB5-DES-CBC3-SHA

警告：サイファーのリストはApache2では1つの長い行であると想定されていますが、ここで読みやすくするために、1行に1つの暗号で分割しました。

そのリストをテストすると

https://www.ssllabs.com/ssltest/analyze.html?d=<domain.tld>

私は得ます：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112

これで、DHEとECDHEを最初にするという概念が理解できました。これらは、「秘密」を意味する「FS」で明確にマークされています（つまり、ハッカーが何らかの方法で秘密鍵を入手できたとしても、メッセージは今後も秘密のままです。少なくともキュービットが現実になるまでは。）

私が疑問に思っているのは、「128」、次に「256」という数字の列です。暗号化ビットの少ない暗号を最初に置くのはなぜですか？暗号化は安全ですか？データを暗号化するために必要なビットが少ないため、高速になりますか？または、最初に256をすべて配置し、次に128、最後に112を配置する必要があります（醜いものを保持する場合は...）

それとも私はその数を完全に誤解しており、順序はすでに可能な限り良いですか？

後で、サーバーでPCIコンプライアンスチェックを実行して得られたセットアップでテストし、そのリストを生成するセットアップを考え出しました。セットアップは次のようになります。

SSLCipherSuite          HIGH:MEDIUM:!ADH:!MD5:!aNULL:!eNULL:!LOW:!EXP:!RC4

ものすごく単純！ただし、そのセットアップはSSLHonerCipherOrderオプションをサポートしていません。そのオプションがonであるかどうかに関係なく、順序はサーバーによって指定されていないと言われています（これはおそらく正しい）。

その場合、Qualys SSL LabsのWebサイトは、暗号を次のように並べ替えます。すべての最小値が最初（112）、次に最大値が最後（256）。それはブラウザが行うことでしょうか？暗号化を続行するために最小ビット数を取得しようとしていますか？それは、データを送信する最も安全な方法ではないでしょうか？

TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     (0x16)   DH 2048 bits    FS  112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA   (0xc012) ECDH sect571r1  FS  112 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_SEED_CBC_SHA             (0x96)                       128
TLS_DHE_RSA_WITH_SEED_CBC_SHA         (0x9a)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
apachecipher-selectionciphers
1
Alexis Wilke

SSLHonorCipherOrderについて誤解しているようです。 Doc は、「通常client'sプリファレンスが使用されます。このディレクティブが有効になっている場合、server'sプリファレンス代わりに使用されます。」したがって、オプションの名前は間違っています。PICK_THE_CIPHER_PER_SERVER'S_ORDERING_AND_DONT_RESPECT_THE_CLIENT'S_ORDERINGのような名前にしてください。

重要な情報は、デフォルトのTLS/SSLv3暗号ネゴシエーションが、Apache docが通常主張するように機能しないことです。まあそれはキューバが米国と交渉するのと同じくらい「交渉」です。 [〜＃〜] rfc [〜＃〜] は、最初のメッセージでクライアントが可能な暗号のリストを送信することを示します。順序付きリストですか？本当にサーバーに依存します。暗号の1つがサーバーによって選択されます。サーバーが決定します。クライアントは、セッション全体を続行または再開することしかできません。 サーバーは完全なリストを表示しないため、クライアントがそこから何かを選択することはできません。

SSLHonorCipherOrder off（通常のApache）は、サーバーが放棄し、自身のSSLCipherSuiteを順序付けられていないリストとして扱い始め、代わりにクライアントの命題を信頼できる順序付けされたリストとして扱います。最初にサポートされる暗号は盲目的に使用されます。 onを使用すると、サーバーはクライアントの命題を順不同として扱います。サーバーの設定（常に内部）はSSLCipherSuiteリストです。

したがって、SSLHonorCipherOrderなしのssllabsテストは、ssllabsの優先順位が何であるかを単に示すだけなので、役に立ちません。オプションがHIGH:MEDIUM:etcでサポートされていないというのは真ではない：私のサイトでは問題なく動作し、ssllabsはHIGHスイートを最初に表示します。レポートには、当然のことながら、サーバーコマンドopenssl ciphers 'HIGH:MEDIUM:etcxxx'とまったく同じ暗号順序が表示されます。

そして最後のポイント。 「弱い-強い-強い」暗号スイートは意味をなさず、不均衡です。 RSA 2048は弱い。ウィキペディアによれば、これは112ビットと推定されています。そして、RSAが壊れている場合は、さようならhttps、さようならman-in-the-middleです。したがって、非常に弱いRSA 2048を備えた、途方もなく強力なAES256に参加することはほとんど意味がありません。CPUの浪費です。 RSA証明書の破棄を開始し、できるだけ早くECDSAとして証明書を再発行する必要があります。これにより、最初のプロセッサーフレンドリーでバランスのとれた安全な暗号スイート（つまり、ECDHE-ECDSA-AES128-GCM-SHA256）を作成できます。

3
kubanczyk

私はあなたの質問をこれらの質問に減らすことができると思います：

  • サーバーはビット数の少ない暗号を好むのですか？
    サーバーが暗号を使用することを優先することはサーバー側で理にかなっています。これまでのところ、これらが十分に安全である限り、より高速である場合は、より少ないビットの暗号を優先することが理にかなっています。ただし、暗号の強度とパフォーマンスはビットだけでなくアルゴリズムにも依存することに注意してください。
  • クライアントはビット数の少ない暗号化を好みますか？つまり、サーバーがクライアントの暗号化順序を尊重する場合？
    これはクライアントによって異なります。 SSLLabsには 特定のクライアントの動作 に関する詳細情報があります。たとえば、現在ChromeとFirefoxの両方が256ビットよりも128ビットのAESを優先しているのに対し、Edgeはその反対です。
1
Steffen Ullrich