SSL / TLS展開のベストプラクティス、パート2。構成

SSL / TLSのデプロイに関する記事の翻訳の第2部に注目してください。第1部はここで読むことができます。



2.設定



TLSサーバーで正しく構成すると、サイトのデータがサイト訪問者に対して正しく表示され、安全なアルゴリズムのみが使用され、すべての既知の脆弱性が修正されることを確認できます。



2.2。 安全なプロトコルを使用する



SSL / TLSファミリには、SSL v2、SSL v3、TLS v1.0、TLS v1.1およびTLS v1.2の5つのプロトコルバージョンがあります。 それらの：

•SSL v2は安全ではないため、使用しないでください。

•SSL v3は、HTTPで使用する場合は安全ではなく、他のプロトコルで使用する場合は脆弱です。 このバージョンも古いため、使用しないでください。

•TLS v1.0は依然として安全なプロトコルです。 HTTPで使用する場合、このプロトコルはセキュリティを提供しますが、慎重な構成が必要です。

•TLS v1.1およびv1.2には、既知のセキュリティ問題はありません。



TLS v1.2がメインプロトコルになります。 このバージョンは、以前のバージョンでは利用できなかった重要な機能をサポートするため、より優れています。 サーバー（または中間デバイス）がTLS v1.2をサポートしていない場合、加速モードでアップグレードすることを計画してください。 サービスプロバイダーがTLS v1.2をサポートしていない場合は、システムのアップグレードを依頼してください。



古いクライアントをサポートするには、TLS v1.0およびTLS v1.1をしばらくサポートし続ける必要があります。 いくつかの回避策を使用すると、これらのプロトコルはほとんどのWebサイトで非常に安全であると見なされます。



2.3。 安全な暗号化アルゴリズムを使用する



データを安全に交換するには、まず、適切な人と直接通信していることを確認する必要があります（盗聴する人を介してではありません）。 SSLおよびTLSは、暗号化アルゴリズムを使用して、データの交換方法を決定します。 それらはさまざまな構成要素で構成されています。 ビルディングブロックの1つのセキュリティが低い場合、別のブロックに切り替えることができるはずです。

目標は、128ビット以上の認証と暗号化を提供する暗号化アルゴリズムのみを使用することです。 他のすべては避けるべきです：

•弱い暗号化アルゴリズム（通常40〜56ビット）を備えたキットは簡単に解読できます。

•RC4も現在脆弱と見なされています。 このアルゴリズムのサポートをできるだけ早く削除する必要がありますが、これは互換性への潜在的な悪影響を確認した後でのみです。

•3DESは約112ビットのセキュリティを提供します。 これは推奨される最小128ビットを下回っていますが、それでもかなり強力なアルゴリズムです。 大きな実用上の問題は、3DESが他の選択肢よりもはるかに遅いことです。 したがって、パフォーマンスを向上させるために推奨しません。



2.4。 暗号化アルゴリズムの選択の制御



SSLバージョン3以降のプロトコルでは、クライアントはサポートする暗号化アルゴリズムのリストを送信し、サーバーはそれらのいずれかを選択して安全な通信チャネルを編成します。 一部のサーバーはリストから最初にサポートされているアルゴリズムを選択するため、すべてのサーバーがこれを実行できるわけではありません。 したがって、適切な暗号化アルゴリズムを選択することはセキュリティにとって重要です。



2.5。 Forward Secrecyをサポートします。



Forward Secrecyは、安全なデータ交換を提供するプロトコル機能であり、サーバーの秘密キーに依存しません。 Forward Secrecyをサポートしない暗号化アルゴリズムを使用すると、サーバーの秘密キーを使用して、以前に暗号化された会話を復号化できます。 ECDHE（略語ECDHEは「楕円曲線を使用した一時的なDiffie-Hellmanアルゴリズム」の略）暗号化アルゴリズムをサポートし、優先する必要があります。 幅広い顧客をサポートするには、ECDHEの後のフォールバックとしてDHEも使用する必要があります。



2.6。 カスタマーイニシアチブの再交渉を無効にする



SSL / TLSでは、再ネゴシエーションにより、関係者はデータの交換を停止して、セキュリティのためにデータを再開始できます。 サーバーによって再ネゴシエーションを開始する必要がある場合もありますが、クライアントが再ネゴシエーションを開始できるようにする必要はありません。 さらに、サーバーに対するDDoS攻撃の組織化を促進できます。



2.7。 既知の問題の削減



ある時点で、どの製品でもセキュリティの問題が発生する場合があります。 さて、情報セキュリティの世界で常に最新の出来事があるなら。 少なくとも、使用する製品のセキュリティリリースを追跡し、利用可能になったらすぐにインストールする必要があります。



セキュリティの世界で何が起こっているかを追跡し、必要なときに状況に適応します。 少なくとも、検出された脆弱性が利用可能になり次第、すぐにパッチをインストールする必要があります。 次の質問に注意してください。



-TLS圧縮を無効にする



2012年、CRIME攻撃は、攻撃者がTLS圧縮を使用して機密データの詳細（セッションCookieなど）を特定する方法を示しました。 その時点で（そして現在）TLS圧縮をサポートしているクライアントは非常に少ないため、サーバーでTLS圧縮を無効にした後にパフォーマンスの問題が発生することはほとんどありません。



-RC4を無効にする



RC4アルゴリズムは安全ではないため、無効にする必要があります。 現在、RC4のハッキングには数百万のリクエスト、多くの帯域幅と時間が必要であることを知っています。 したがって、リスクはまだ比較的小さいですが、攻撃が将来より大きくなる可能性があります。 RC4を削除する前に、既存のユーザーが影響を受けるかどうかを確認してください。 つまり、RC4のみをサポートするクライアントがあるかどうかを確認します。



-BEAST攻撃を常に把握する



成功したBEAST攻撃は、ハッキングセッションのようなものです。 残念ながら、サーバーの脅威を緩和するにはRC4が必要ですが、これは推奨されません。 このため、またクライアント側でのBEAST攻撃が大幅に削減されたため、RC4を使用したサーバーでの軽減を推奨しなくなりました。 BEAST攻撃に対して脆弱な古いクライアントが多数存在する状況では、TLS 1.0およびプロトコルの以前のバージョンでRC4を使用する方が安全です。 この決定は、環境とその脅威のモデルを完全に理解してから慎重に行う必要があります。



-SSL v3を無効にする



SSL v3は、2014年10月に発見されたPOODLE攻撃に対して脆弱です。POODLE攻撃の脆弱性を修正する最善の方法は、ほとんどのサイトで安全に実行できるSSL v3を無効にすることです。