3.7. TLS 設定のハードニング
TLS (Transport Layer Security)は、ネットワーク通信のセキュリティーを保護するために使用される暗号化プロトコルです。優先する 鍵交換プロトコル、認証方法、および 暗号化アルゴリズム を設定してシステムのセキュリティー設定を強化する場合は、サポートされるクライアントの範囲が広ければ広いほど、セキュリティーレベルが低くなることを認識しておく必要があります。反対に、セキュリティー設定によりクライアントとの互換性が制限され、システムからロックアウトされるユーザーが少なくなることがあります。可能な限り厳密な設定を目指し、互換性に必要な場合に限り、設定を緩めるようにしてください。
ほとんどのデプロイメントでは、Red Hat Enterprise Linux に含まれるライブラリーが提供するデフォルト設定が十分に安全であることに注意してください。
TLS 実装は、可能な場合は安全なアルゴリズムを使用しますが、レガシーのクライアントまたはサーバーへの接続は妨げません。セキュアなアルゴリズムまたはプロトコルをサポートしないレガシーなクライアントまたはサーバーが、接続が期待できない、または許可されないレガシーなセキュリティー要件がある環境では、このセクションで説明する強化された設定を適用します。
3.7.1. 有効にするアルゴリズムの選択
選択および設定が必要なコンポーネントが複数あります。以下のそれぞれは、設定の堅牢性（つまり、クライアントでのサポートレベル）や、ソリューションがシステムに持つ計算要件に直接影響します。
プロトコルのバージョン
最新バージョンの
TLS は、最高のセキュリティーメカニズムを提供します。古いバージョンの TLS（または SSL）のサポートが含まれるようなような理由がない限り、システムは最新バージョンの TLS のみを使用して接続をネゴシエートできるようにし ます。
SSL バージョン 2 または 3 を使用するネゴシエーションを許可しないでください。これらのバージョンにはいずれも重大なセキュリティー脆弱性があります。TLS バージョン 1.0 以降を使用するネゴシエーションのみを許可します。TLS 1.2 の現行バージョンは常に推奨する必要があります。
注記
現在、TLS の全バージョンのセキュリティーは、
TLS TLS 接続ピアは、セキュアな再ネゴシエーションインデックス(RFC 5746)を実装する必要があります。圧縮をサポートしない。また、CBCモード暗号（Lucky Thir 攻撃）に対するタイミング攻撃の緩和策を実装する必要があります。TLS v1.0 クライアントは、追加のレコード分割（BEAST 攻撃に対する回避策）を実装する必要があります。TLS v1.2 は、認証された暗号化と関連するデータ （）をサポートします。AEAD） AES-GCM、AES- CCM、Camellee- GCM などのモード暗号。既知の問題はありません。上記の軽減策はすべて、Red Hat Enterprise Linux に含まれる暗号化ライブラリーに実装されています。
プロトコルバージョンの概要と推奨される使用方法は 表3.1「プロトコルのバージョン」 を参照してください。
| プロトコルのバージョン | 使用に関する推奨事項 |
|---|---|
SSL v2 |
使用しないでください。深刻なセキュリティー上の脆弱性があります。
|
SSL v3 |
使用しないでください。深刻なセキュリティー上の脆弱性があります。
|
TLS v1.0 |
必要に応じて相互運用性の目的で使用します。相互運用性を保証する方法で軽減できない既知の問題があるため、デフォルトでは軽減策が有効になっていません。最新の暗号スイートには対応しません。
|
TLS v1.1 |
必要に応じて相互運用性の目的で使用します。既知の問題はありませんが、Red Hat Enterprise Linux のすべての
TLS 実装に含まれるプロトコルの修正に依存します。最新の暗号スイートには対応しません。
|
TLS v1.2 |
推奨されるバージョン。最新の
AEAD 暗号スイートに対応します。
|
Red Hat Enterprise Linux の一部のコンポーネントは、
TLS v 1.1 または v 1.2 のサポートを提供しますが、TLS v 1.0 を使用するように設定されています。これは、最新バージョンの TLS をサポートしない外部サービスとの最も高いレベルの相互運用性を実現することが目的です。相互運用性の要件に応じて、利用可能な TLS の最大値を有効にします。
重要
SSL v3 の使用は推奨されません。ただし、セキュアでないと見なされて一般的に使用できない場合は、SSL v3 を有効にしたままにする必要があります。暗号化に対応していないサービスを使用している場合や、古くなった暗号化モードのみを使用するサービスを使用する場合でも、s stunnel を使用して通信を安全に暗号化する 「stunnel の使用」 方法はを参照してください。
128 ビット未満のセキュリティーしか提供しない暗号化スイートでは直ちにセキュリティーが保護されなくなるというわけではありませんが、使用できる期間が短いため考慮すべきではありません。128 ビット以上のセキュリティーを使用するアルゴリズムは、少なくとも数年間は改ざんできないことが期待されるため、強く推奨されます。
3DES 暗号は 168 ビットを使用していることを公開していますが、実際には 112 ビットのセキュリティーを提供していることに注意してください。
PFS(Perfect )フォワード Secrecy(PFS) をサポートする暗号スイートを常に優先します。これにより、サーバーキーが危険にさらされた場合でも、暗号化されたデータの機密性が確保されます。これにより、高速
RSA 鍵交換は除外されますが、ECDHE および DHE を使用できます。この 2 つでは、ECDHE の方が高速であるため、推奨される選択肢となります。
ECDSA 証明書で ECDHE 鍵交換を使用すると、トランザクションは純粋な RSA 鍵交換よりもさらに高速になります。レガシークライアントに対応するには、サーバー上に証明書と鍵のペアを 2 つ（新しいクライアント用の ECDSA 鍵 と、レガシー用の RSA 鍵）インストールできます。
公開鍵の長さ
RSA 鍵を使用する場合は、SHA-256 以上で署名された鍵の長さが 3072 ビット以上推奨されます。これは、実際に 128 ビットのセキュリティーに対して十分な大きさです。
警告
システムのセキュリティーレベルは、チェーン内で最も弱いリンクと同じであることに注意してください。たとえば、強力な暗号化だけではすぐれたセキュリティーは保証されません。鍵と証明書も同様に重要で、認証局 (CA)が鍵の署名に使用するハッシュ機能と鍵も重要になります。
