3.7. TLS 設定の強化

TLS (トランスポート層セキュリティ) は、ネットワーク通信をセキュアにするために使用する暗号化プロトコルです。優先する鍵交換プロトコル認証方法、および暗号化アルゴリズムを設定することでシステムのセキュリティ設定を強化する際には、サポートするクライアントの範囲が広ければ広いほど、セキュリティのレベルが低くなることを認識しておく必要があります。反対に、セキュリティ設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性のために必要な場合にのみ、これを緩めるようにしてください。
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 Thirteen 攻撃) に対するタイミング攻撃を緩和する方法を実装する必要があります。TLS v1.0 クライアントはさらに、レコード分割 (BEAST 攻撃に対する回避策) を実装する必要があります。TLS v1.2 は、AES-GCMAES-CCM、または Camellia-GCM といった既知の問題のない 認証付き暗号 (Authenticated Encryption with Associated Data : AEAD) モードの暗号をサポートしています。ここに記載された緩和策はすべて、Red Hat Enterprise Linux に含まれる暗号ライブラリーに実装されています。
プロトコルのバージョンおよび推奨される使用方法についての概要は、表3.1「プロトコルのバージョン」 を参照してください。

表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 v1.1v1.2 に対応しているのに TLS v1.0 を使用する設定になっているものもあります。これは、最新バージョンの TLS に対応していない可能性のある外部サービスとの最高レベルの相互運用性を達成する目的でこのようになっています。相互運用性の要件に対応して、利用可能な最高レベルの TLS バージョンを有効にしてください。

重要

SSL v3 の使用は推奨されません。これはセキュアではなく一般の使用には適していませんが、SSL v3 をどうしても有効にする必要がある場合は、「stunnel の使用」 を参照してください。暗号化に対応していない、または旧式でセキュアでない暗号化モードの使用しかできないサービスを使用する場合でも、stunnel を使用して安全に通信を暗号化する方法が説明されています。
128 ビット未満のセキュリティしか提供しない暗号化スイートは直ちに不安というわけではありませんが、これらは短期間の使用に考慮すべきではありません。128 ビット以上のセキュリティを使用するアルゴリズムは少なくとも数年間は解読不可能であることが期待されているので、強く推奨されます。3DES 暗号は 168 ビットの使用を提供しますが、実際に提供されているのは 112 ビットのセキュリティであることに注意してください。
(perfect) forward secrecy (PFS) をサポートしている暗号化スイートを常に優先させてください。PFS は、サーバー鍵が漏れたとしても、暗号化されたデータの秘密性は確保されます。これにより、すばやい RSA 鍵の交換がなくなる一方、ECDHE および DHE の使用が可能になります。これら 2 つのうちでは、ECDHE の方がより速いため、優先される選択肢となります。
また、ECDSA 証明書を使って ECDHE 鍵交換を使用する際は、純粋な RSA 鍵交換よりも速くなります。レガシークライアント用のサポートを提供するには、サーバー上に証明書と鍵のペアを 2 つインストールします。ひとつは ECDSA 鍵 (新規クライアント用) で、もうひとつは RSA 鍵 (レガシークライアント用) です。

公開鍵の長さ

RSA 鍵を使用する際は常に、少なくとも SHA-256 で署名された 最低 3072 ビットの鍵の長さを優先させます。これは、真の 128 ビットのセキュリティでは十分な大きさです。

警告

システムのセキュリティ強度は、チェーンの中の最も弱いリンクが示すものと同じであるということを念頭に置いてください。たとえば、強力な暗号化だけではすぐれたセキュリティは保証されません。鍵と証明書も同様に重要で、認証機関 (CA) が鍵の署名に使用するハッシュ機能と鍵もまた重要になります。