強度が必要ない場合のNginxの最速のSSL暗号実装？
ほとんどの逆のユースケースがあります。パフォーマンスの名目で非常に弱いSSL暗号を実装し、クライアントが要求した場合に強力な暗号にフォールバックするオプションを付けたいと思います。
経歴：私は、数千のリモートクライアントから大量のPOSTトラフィックを受信する公開Webサーバーを持っていますが、各POSTはかなり小さいです。Aクライアントはペイロードを1回実行し、切断します。サーバーは1分あたり数千の接続を行うため、SSLネゴシエーションのオーバーヘッドが増加します。
問題のデータは安全である必要はありません。 HTTPSを使用する理由は、トラフィックが特定のWebサイトのJavaScriptタグから発信されているためです。そのサイトがHTTPSを使用している場合、安全なコンテンツと安全でないコンテンツの混合に関する警告を防ぐために、補足トラフィックもHTTPSを使用する必要があります。繰り返しになりますが、「親」サイトが何らかの理由でSSLで保護されている場合でも、この接続のデータのセキュリティはまったく重要ではありません。
このため、ブラウザとの完全な互換性を維持しながら、クライアントに可能な限り弱い暗号を提示することは私にとって理にかなっています。また、必要に応じてセキュリティを完全なECDHEに上げるオプションを提供したいと思います。これは、セキュリティを重視するクライアントを満足させるためだけですが、間違いなく2番目のオプションです。
数年前は、RC4のいくつかの亜種が法案に適合していましたが、今日では一般的に安全ではないものとしてパンされているため、ブラウザーの互換性が問題になるのではないかと心配しています。それをきっかけに、どの暗号が私が上で探している機能を最高の速度で提供してくれるでしょうか？
問題のデータは安全である必要はありません...安全な混合に関する警告を防ぎます
これらの警告をできるだけ無視しようとするのではなく、おそらくこれらの警告の理由を理解する必要があると思います。安全なサイトのコンテンツが安全でないサイトから含まれている場合、元のサイトのセキュリティに影響を与える可能性があります。
サーバーは1分あたり数千のこれらの接続を引き受けるため、SSLネゴシエーションのオーバーヘッドが増加します。
高速暗号は通常、SSLネゴシエーションのオーバーヘッドを大幅に削減することはありません。暗号は主に使用されます後ネゴシエーションが行われ、パフォーマンスへの影響はわずかです。暗号の一部はハンドシェイク（キー交換）に関連していますが、非常に遅いキー交換（以下を参照）を選択しない限り、パフォーマンスへの主な影響は、ネゴシエーションに必要な内部の複数のラウンドトリップから生じます。これらは、セッションの再利用をサポートしている場合にのみ減らすことができるため、完全なハンドシェイクは最初の要求にのみ必要であり、同じクライアントが次に接続するときに、より安価なセッション再開を実行できます。 HTTPキープアライブも大いに役立ちます。もちろん、これらの最適化は両方とも、同じクライアントから実際に複数のリクエストがある場合にのみ機能します。
鍵交換が非常に遅い暗号がいくつかありますが、この場合はおそらく使用したくないでしょう。すべてのDHE- *暗号はパフォーマンスに大きな影響を与えますが、転送秘密を提供するという利点があります。今日のハードウェアのパフォーマンスにあまり影響を与えることなく、ECDHE暗号で同じ利点を得ることができますが、オーバーヘッドは依然として存在します。 AES128-GCM-SHA256のような暗号を使用することは、パフォーマンスとセキュリティの両方の観点から良い選択です。
最後に、暗号の選択は、使用するクライアントによっても異なります。 RC4-SHAは高速ですが、安全でないと見なされ、ますます多くのクライアントがそれを無効にしています。したがって、ブラウザが安全でない暗号を無効にしているため、高速サーバーでは誰も使用できない可能性があります。
絶対最速はeNullです。 ssl_ciphersにeNullを含めるには、暗号文字列にaNULL:eNULL:MD5:LOW:HIGHを試してください。ただし、通常は、サポートされている最高の暗号をネゴシエートします。したがって、!HIGHを使用して上限を設定することもできますが、必ずこれを徹底的にテストしてください。ほとんどのブラウザはnullおよびmd5暗号の使用をまったく拒否すると私は信じているので、少なくともLOWを維持する必要があります。
https://discussions.qualys.com/thread/16005 は、バルク暗号化操作と鍵交換の両方のベンチマークを示しています。バルク暗号の場合、aes128-ccmが最速のようであり、鍵交換の場合、ecdhe（nist p256を使用）は2048ビットdheよりもかなり高速ですが、rsa鍵交換はわずかに高速です。 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5551094/ は、鍵交換方法の比較を示しています。Curve25519（別名X25519）の鍵交換はnist p256よりも大幅に高速です）
これらすべてをまとめると、最新のプロセッサとsslライブラリを使用すると、おそらくTLS_ECDHE_ECDSA_WITH_AES_128_CCM（GCMスイートはほぼ同じくらい高速で、より広く使用されています）と鍵交換用のX25519が最適です。クライアントの互換性のために、RSAキー交換を使用するTLS_RSA_WITH_AES_128_CBC_SHAを提供することもできます。 RC4スイートを提供することもできますが、ブラウザーがそのアルゴリズムを拒否し始める場合があります。最終的にはサーバーのハードウェアに依存するため、いくつかの暗号スイートのベンチマークを試して、1秒あたりに実行できる接続数を確認することをお勧めします。