web-dev-qa-db-ja.com

nginxとTLS 1.3で完璧なSSLラボのスコアは？

Qualsys SSL LabsでTLS v1.2のみを使用して完全なスコアを取得するnginx構成を作成しました。TLSv1.2とv1.3の両方を使用して完全なスコアを取得したいと考えています。

A +および100％スコアの一部であるnginx.confのバージョンの次のスニペットを検討してください：

ssl_protocols TLSv1.2;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;

いくつかの暗号スイートについて文句を言いますが、それでも、それ以外の点では完璧なスコアが得られます。

enter image description hereenter image description here

さて、TLS v1.3をonly構成変更としてミックスに追加すると、スコアが変更されます

ssl_protocols TLSv1.2 TLSv1.3;

暗号強度は90％としてスコアリングされます： enter image description here

私はそれがそれらの弱いCBC暗号について怒っていると思います：

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp384r1 (eq. 7680 bits RSA)   FS   WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp384r1 (eq. 7680 bits RSA)   FS   WEAK    256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 4096 bits   FS   WEAK   256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 4096 bits   FS   WEAK

CBCモードの暗号を完全に削除するための良い方法は実際にはありませんが、SHA1、SHA256、SHA384を除外しても機能する可能性があります。構成行は次のようになります。

ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL:!SHA1:!SHA256:!SHA384;

新しいスコアを見てみましょう： enter image description here

暗号スイートの強度は依然として90％です。

暗号スイートの強さにもう怒っていません： enter image description here

しかし、どうやら以前に機能していたハンドシェイクの失敗については不幸なようです： enter image description here

これにより、古いデバイス/アプリのハンドシェイクを成功させるために必要な同じ暗号スイートが「弱い」としてリストされ、TLS 1.2のみが有効になっている場合に合格します。どういうわけかTLS 1.3を有効にすると、失敗する前に通過する同じ弱い暗号が作成されます。

選択のようです：TLS 1.2onlyを有効にして完全なスコアを取得するか、TLS 1.3も有効にして必要な暗号スイートを無効にしますか？ 小林丸 です。

NginxとTLS 1.2および1.3を有効にして完全な100％スコアを取得することは可能ですか？

nginxsecuritysslopenssldebian-stretch
3
GojiraDeMonstah

Qualys SSL Labs テストツール自体に関する実際の質問については、評価システムがどのように機能するかを詳しく調べる必要があります。
幸いなことに、Qualysは SSLサーバー評価ガイド を公開しています。これは、SSL/TLS構成の評価方法を説明しています。

あなたの質問は、提案された構成の1つが他の構成よりも Cipher Strengthカテゴリ のスコアがわずかに低い理由についてなので、そのカテゴリに特に焦点を当てましょう。

暗号強度

通信セッションを破壊するために、攻撃者は通信の大部分に使用されている対称暗号を破ろうとする可能性があります。強力な暗号化により、強力な暗号化が可能になり、暗号を解読するために必要な労力が増加します。サーバーはさまざまな強度の暗号をサポートできるため、弱い暗号の使用にペナルティを課すスコアリングシステムに到達しました。このカテゴリのスコアを計算するには、次のアルゴリズムに従います。

  1. 最強の暗号のスコアから始めます。
  2. 最も弱い暗号のスコアを追加します。
  3. 合計を2で割ります。

表5.暗号強度評価ガイド

Cipher strength               Score
0 bits (no encryption)        0%
< 128 bits (e.g., 40,56)      20%
< 256 bits (e.g., 128, 168)   80%
>= 256 bits (e.g., 256)       100%

質問に含まれているより詳細な結果を振り返ると、TLS1.2のみの構成では、TLS1で256ビットの暗号のみが使用されていたことがわかります（一部の暗号スイートは推奨されていませんでした）。 2 + TLS1.3構成では、128ビットと256ビットの暗号を組み合わせて使用​​していました。
評価システムに基づいて、「暗号強度」のスコアが減少した理由を説明します。

さて、これはこのツールが非常に有用なリソース（特に実際の不適切な構成を指摘するためのリソース）である一方で、レポート全体を見るのではなく、正確なスコアリングに重点を置くのは良い考えではないことを強調しています。


実際に妥当なTLS設定とは何かについて、必要なものについての強い考えがない限り、Mozillaの運用セキュリティとエンタープライズによって維持される Server Side TLS ガイダンスを確認することをお勧めします情報セキュリティチーム。
特に「中間」構成は、幅広い互換性とセキュリティのバランスが取れており、推奨設定を実際のサーバー構成に簡単に変換するための一般的なTLSサーバー用の構成ジェネレーターがあります。

5
Håkan Lindqvist

OpenSSLを構成してTLS 1.3を使用するために一部の暗号を除外することにより、TLS1.3への準拠を犠牲にして可能です。

ここに短いハウツーを書いた：

TLS ALL The Things！ それを達成する方法の詳細に加えて、残りのOSで112ビット相当の最小使用を有効にします。

ここでは、実行例 here の結果を確認できます。

https://i.imgur.com/0g9B8cP.png

CBC暗号の使用に注意してください。通常、これらも削除し、GCMのみを実行します。ただし、訪問する人の数が多いため、全員に常緑樹を実行させるのではなく、そのリスクを冒すかもしれません。 （常緑樹に行こう！）

とにかく、あなたが本当に興味を持っている部分は：

暗号スイート= TLS_AES_256_GCM_SHA384：TLS_CHACHA20_POLY1305_SHA256
オプション= ServerPreference、PrioritizeChaCha

それらをOpenSSL構成に追加することで、128ビットパラメーターを効果的に削除できます... Nginxは、TLS 1.2構成などを引き続き実行します。これは、バイナリがOpenSSLの代わりにこれらの設定を制御するためです。 OpenSSLの設定に依存しているOSの残りの部分も、これらを使用します！ （温かく推奨）

2
Angelique Dawnbringer