TLS/SSL ルールを使用した復号の調整

次のトピックでは、TLS/SSL ルール条件を設定する方法の概要を示します。

TLS/SSL ルール条件の概要

デバイスで検査されるすべての暗号化トラフィックには、基本的な TLS/SSL ルールに基づいたアクションが適用されます。暗号化トラフィックをより詳細に復号化および制御するには、特定タイプのトラフィックの処理およびログ記録を制御するルール条件を設定します。各 TLS/SSL ルールには 0 個、1 個、または複数の条件を設定できますが、トラフィックに TLS/SSL ルールが適用されるのは、そのルールのすべての条件にトラフィックが一致する場合のみです。


（注）  

トラフィックがルールに一致すると、デバイスは設定されたルール アクションをトラフィックに適用します。ログの記録が指定されている場合、接続が終了した時点でトラフィックに関するログが記録されます。

各ルール条件には、照合するトラフィックのプロパティを 1 つまたは複数指定できます。たとえば、以下のプロパティを指定できます。

  • 通過するセキュリティ ゾーン、IP アドレスおよびポート、送信元または宛先の国、送信元または宛先の VLAN などのトラフィック フロー。

  • 検出された IP アドレスに関連付けられたユーザ。

  • トラフィックで検出されたアプリケーションなどのトラフィック ペイロード。

  • 接続の暗号化に使用された TLS/SSL プロトコル バージョン、暗号スイート、サーバー証明書などの接続暗号化。

  • サーバー証明書の識別名に指定された URL のカテゴリおよびレピュテーション。

復号の調整の要件と前提条件

モデルのサポート

NGIPSv を除くすべて。

サポートされるドメイン

任意

ユーザの役割

  • 管理者

  • アクセス管理者

  • ネットワーク管理者

サーバー証明書ベースの TLS/SSL ルール条件

TLS/SSL ルールでは、サーバー証明書の特性に基づいて暗号化トラフックを処理および復号できます。TLS/SSL ルールは、以下のサーバー証明書属性に基づいて設定することができます。

  • 識別名条件を設定すると、証明書所有者またはサーバー証明書の発行元 CA に応じて暗号化トラフィックを処理および検査できます。発行元の識別名を基準にすると、サイトのサーバー証明書を発行した CA に基づいてトラフィックを処理できます。

  • TLS/SSL ルールで証明書条件を設定すると、トラフィックの暗号化に使用されているサーバ証明書に応じて暗号化トラフィックを処理および検査できます。1 つの条件に 1 つまたは複数の証明書を設定でき、トラフィックの証明書がいずれかの条件の証明書と一致するとそのルールが適用されます。

  • TLS/SSL ルールの証明書ステータス条件では、トラフィックの暗号化に使用されたサーバ証明書のステータスに基づいて暗号化されたトラフィックを処理して、証明書が有効か、失効しているか、期限切れか、まだ有効でないか、自己署名済みか、信頼できる CA によって署名済みか、証明書失効リスト（CRL）が有効かどうか、証明書のサーバ名指定（SNI）が要求内のサーバと一致するかどうかなどの検査を行うことができます。

  • TLS/SSL ルールで暗号スイート条件を設定すると、暗号化セッションのネゴシエートに使用される暗号スイートに応じて暗号化トラフィックを処理および検査できます。

  • TLS/SSL ルールでセッション条件を設定すると、トラフィックの暗号化に使用されている SSL または TLS のバージョンに応じて暗号化トラフィックを検査できます。

複数の暗号スイートを 1 つのルールで検出したり、証明書の発行元や証明書ホルダーを検出したりする場合は、再利用可能な暗号スイートのリストおよび識別名オブジェクトを作成してルールに追加できます。サーバー証明書および特定の証明書ステータスを検出するには、ルール用の外部証明書と外部 CA オブジェクトの作成が必要です。

識別名（DN）のルール条件

このトピックでは、TLS/SSL ルールで識別名条件を使用する方法について説明します。よくわからない場合は、Web ブラウザを使用して証明書のサブジェクト代替名（SAN）と共通名を見つけ、それらの値を識別名条件として TLS/SSL ルールに追加できます。

SAN の詳細については、RFC 528、セクション 4.2.1.6 を参照してください。

ここでは、次の点について説明します。

DN ルールマッチングの例

以下は、[復号しない（Do Not Decrypt）] ルールの DN ルール条件の例です。amp.cisco.com または YouTube に向かうトラフィックを復号しないようにしたいとします。次のように DN 条件を設定できます。

DN ルール条件の例

This image is not available in preview/cisco.com

前述の DN ルール条件は次の URL に一致するため、トラフィックは復号されません。以前のルールによって復号は防止されました。

  • www.amp.cisco.com

  • auth.amp.cisco.com

  • auth.us.amp.cisco.com

  • www.youtube.com

  • kids.youtube.com

  • www.yt.be

前述の DN ルール条件は、次の URL のいずれにも一致しないため、トラフィックは [復号しない（Do Not Decrypt）] ルールには一致しませんが、同じ SSL ポリシー内の他の TLS/SSL には一致する可能性があります。

  • amp.cisco.com

  • youtube.com

  • yt.be

上記のホスト名のいずれかと一致するには、ルールに CN を追加します（たとえば、CN=yt.be を追加すると、その URL に一致します）。

Firepower システムが SNI と SAN を使用する方法

クライアント要求の URL のホスト名部分は、サーバー名指定（SNI）です。クライアントは、TLS ハンドシェイクの SNI 拡張を使用して、接続するホスト名（たとえば、auth.amp.cisco.com）を指定します。次に、サーバーは、単一の IP アドレスですべての証明書をホストしながら、接続を確立するために必要な、対応する秘密キーと証明書チェーンを選択します。

SNI と証明書の CN または SAN が一致する場合、ルールにリストされている DN と比較するときに SNI を使用します。SNI がない場合、または証明書と一致しない場合は、ルールにリストされている DN と比較するときに、証明書の CN を使用します。

証明書の共通名とサブジェクト代替名を見つける方法

証明書の共通名を見つけるには、次の手順を使用します。これらの手順を使用して、自己署名証明書の共通名と SAN を見つけることもできます。

これらの手順は Firefox 用ですが、他のブラウザも同様です。次の手順では、例として amp.cisco.com を使用します。

  1. Firefox で amp.cisco.com にアクセスします。

  2. ブラウザのロケーションバーで、URL の左側にある をクリックします。

  3. [この接続は保護されています（Connection secure）] > [詳細情報（More Information）] をクリックします

    （セキュリティで保護されていない場合、または自己署名証明書の場合は、[この接続は保護されていません（Connection not secure）] > [詳細情報（More Information）] をクリックします）。

  4. [ページ情報（Page Info）] ダイアログボックスで、[証明書の表示（View Certificate）] をクリックします。

    [ページ情報（Page Info）] ダイアログボックスでは、サーバーの証明書に関する情報を表示できます。[ページ情報（Page Info）] ダイアログボックスでは、サーバーの証明書に関する情報を表示できます。

    This image is not available in preview/cisco.com

  5. 次のページには、証明書の詳細が表示されます。

    YouTube の証明書が興味深いのは、共通名が *.google.com であるためです。これは、ダイアログボックスに表示されるすべてのサブジェクト代替名と一致するため、ルール条件としてはおそらく不適切な選択です。ただし、ルール条件として youtube.com を使用できます。

次の点に注意してください。

  • CN=auth.amp.cisco.com を DN ルール条件として使用すると、そのホスト名（つまり、SNI）のみに一致します。SNI amp.cisco.com は一致しません。

  • できるだけ多くのドメイン名フィールドに一致させるには、ワイルドカードを使用します。

    たとえば、auth.us.amp.cisco.com と一致させるには、CN=*.*.amp.cisco.com を使用します。auth.us.amp.cisco.com と一致させるには、CN=*.*.amp.cisco.com を使用します。

    CN=*.example.com のような DN は www.example.com に一致しますが、example.com には一致しません。両方の SNI に一致させるには、ルール条件で 2 つの DN を使用します。

  • ただし、ワイルドカードは使いすぎないでください。たとえば、CN=*.google.com のような DN オブジェクトは、非常に多数の SAN に一致します。CN=*.google.com の代わりに、CN=*.youtube.com などの DN オブジェクトを DN オブジェクトとして使用して、www.youtube.com などの名前と一致させるようにします。

    CN=*.youtube.com、CN=youtu.be、CN=*.yt.be などの SAN に一致する SNI のバリエーションを使用することもできます。

  • 自己署名証明書も同じように機能するはずです。発行元 DN がサブジェクト DN と同じであるという事実によって、自己署名証明書であることを確認できます。

DN ルール条件を追加する方法

一致させる CN がわかったら、次のいずれかの方法で TLS/SSL ルールを編集します。

  • 既存の DN を使用します。

    DN の名前をクリックし、[サブジェクトに追加（Add to Subject）] または [発行元に追加（Add to Issuer）] をクリックします（[サブジェクトに追加（Add to Subject）] の方がはるかに一般的です）。DN オブジェクトの値を表示するには、マウスポインタをその上に移動します。

    [利用可能なDN（Available DNs）] フィールドから選択し、[サブジェクトに追加（Add to Subject）]（最も一般的なオプション）または [発行元に追加（Add to Issuer）] をクリックすることにより、通常は共通名で既存の DN オブジェクトを追加できます。

    This image is not available in preview/cisco.com

  • 新しい DN オブジェクトを作成します。

    [利用可能なDN（Available DNs）] の右側にある をクリックします。DN オブジェクトは、名前と値で構成されている必要があります。

  • DN を直接追加します。

    [サブジェクトDN（Subject DNs）] フィールドまたは [発行元DN（Issuer DNs）] フィールドの下部にあるフィールドに DN を入力します（[サブジェクトDN（Subject DNs）] のほうが一般的です）。DN を入力したら、[追加（Add）] をクリックします。

    [サブジェクトDN（Subject DNs）] または [発行元DN（Issuer DNs）] フィールドのいずれかの下部に DN オブジェクトを直接追加することもできます。

    This image is not available in preview/cisco.com

証明書の識別名による暗号化トラフィックの制御

手順

ステップ 1

SSL ルールエディタで、[DN] を選択します。

ステップ 2

[使用可能な DN（Available DNs）] で、追加する識別名を探します。

  • ここで識別名オブジェクトを作成してリストに追加するには（後で条件に追加できます）、[使用可能なDN（Available DNs）] リストの上にある をクリックします。

  • 追加する識別名オブジェクトおよびグループを検索するには、[使用可能なDN（Available DNs）] リストの上にある [名前または値で検索（Search by name or value）] プロンプトをクリックし、オブジェクトの名前またはオブジェクトの値を入力します。入力すると、リストが更新されて一致するオブジェクトが表示されます。

ステップ 3

オブジェクトを選択するには、そのオブジェクトをクリックします。すべてのオブジェクトを選択するには、右クリックして [すべて選択（Select All）] を選択します。

ステップ 4

[サブジェクトに追加（Add to Subject）] または [発行元に追加（Add to Issuer）] をクリックします。

ヒント 

選択したオブジェクトをドラッグ アンド ドロップすることもできます。

ステップ 5

手動で指定するリテラル共通名または識別名がある場合は、それらを追加します。[サブジェクト DN（Subject DNs）] または [発行元 DN（Issuer DNs）] リストの下にある [DN または CN の入力（Enter DN or CN）] プロンプトをクリックし、共通名または識別名を入力して [追加（Add）] をクリックします。

ステップ 6

ルールを追加するか、編集を続けます。

例

次の図は、goodbakery.example.com に対して発行された証明書および goodca.example.com によって発行された証明書を検索する識別名ルール条件を示しています。これらの証明書で暗号化されたトラフィックは許可され、アクセス コントロールにより制御されます。

サンプル SSL ルールの識別名条件

次の図は、badbakery.example.com および関連ドメインに対して発行された証明書および badca.example.com によって発行された証明書を検索する識別名ルール条件を示しています。これらの証明書で暗号化されたトラフィックは、再署名された証明書を使用して復号されます。

識別名オブジェクト、CN、および DN を使用した SSL ルールの識別名条件のサンプル

次のタスク

証明書の TLS/SSL ルール条件

証明書ベースの TLS/SSL ルール条件を作成するときにサーバー証明書をアップロードしたり、再利用可能な外部証明書オブジェクトとして保存してサーバー証明書の名前を関連付けたりできます。また、既存の外部証明書オブジェクトやオブジェクト グループを使用して証明書条件を設定することもできます。

ルール条件の [使用可能な証明書（Available Certificates）] フィールドでは、外部証明書オブジェクトやオブジェクト グループを証明書の識別名に関する以下の特性に基づいて検索できます。

  • 件名または発行元の共通名（CN）

  • 件名または発行元の組織（O）

  • 件名または発行元の部門（OU）

1 つの証明書のルール条件で複数の証明書を照合することもでき、トラフィックの暗号化に使用されている証明書がアップロードされた証明書のいずれかと一致した場合、その暗号化トラフィックはルールに一致したと判定されます。

1 つの証明書条件で、[選択した証明書（Selected Certificates）] リストに最大 50 の外部証明書オブジェクトおよび外部証明書オブジェクト グループを追加できます。

次の点に注意してください。

  • [復号 - 既知のキー（Decrypt - Known Key）] アクションも選択すると、証明書条件を設定できなくなります。このアクションでは、トラフィック復号用のサーバー証明書の選択が必要であるため、トラフィックの照合はすでにこの証明書で行われていることになります。

  • 証明書条件に外部証明書オブジェクトを設定する場合、暗号スイート条件に追加する暗号スイートまたは [復号 - 再署名（Decrypt - Resign）] アクションに関連付ける内部 CA オブジェクトのいずれかが、外部証明書の署名アルゴリズム タイプと一致する必要があります。たとえば、ルールの証明書条件で EC ベースのサーバ証明書を参照する場合は、追加する暗号スイート、または [Decrypt - Resign] アクションに関連付ける CA 証明書も EC ベースでなければなりません。署名アルゴリズムタイプの不一致が検出されると、ポリシーエディタでルールの横に警告が表示されます。

  • システムが新しいサーバーへの暗号化セッションを最初に検出したときは、証明書データを ClientHello の処理には使用できません。これは復号されていない最初のセッションとなる可能性があります。最初のセッションの後に、管理対象デバイスは、サーバーの証明書メッセージからのデータをキャッシュします。同じクライアントからの後続の接続で、システムは証明書条件を含むルールに ClientHello メッセージを最終的に一致させ、メッセージを処理して、復号の可能性を最大化できます。

証明書による暗号化トラフィックの制御

手順

ステップ 1

SSL ルールエディタで、[証明書（Certificate）] を選択します。

ステップ 2

[使用可能な証明書（Available Certificates）] で、追加するサーバ証明書を探します。

  • ここで外部証明書オブジェクトを作成してリストに追加するには（後で条件に追加できます）、[使用可能な証明書（Available Certificates）] リストの上にある をクリックします。

  • 追加する証明書オブジェクトおよびグループを検索するには、[使用可能な証明書（Available Certificates）] リストの上にある [名前または値で検索（Search by name or value）] プロンプトをクリックし、オブジェクトの名前またはオブジェクトの値を入力します。入力すると、リストが更新されて一致するオブジェクトが表示されます。

ステップ 3

オブジェクトを選択するには、そのオブジェクトをクリックします。すべてのオブジェクトを選択するには、右クリックして [すべて選択（Select All）] を選択します。

ステップ 4

[ルールに追加（Add to Rule）] をクリックします。

ヒント 

選択したオブジェクトをドラッグ アンド ドロップすることもできます。

ステップ 5

ルールを追加するか、編集を続けます。

次のタスク

証明書ステータスの TLS/SSL ルール条件

証明書ステータスの TLS/SSL ルール条件では、各ステータスの有無を基準にしたトラフィックの照合ができます。1 つのルール条件で複数のステータスを選択でき、いずれかのステータスと証明書が一致すれば、ルールとトラフィックが一致したと判定されます。

複数の証明書ステータスの有無を単一の証明書ステータス ルール条件で照合するように選択できます（いずれか 1 つの基準に一致するだけで、その証明書はルールに一致します）。

このパラメータを設定するときは、復号ルールを設定するのか、ブロック ルールを設定するのかを検討する必要があります。通常、ブロック ルールでは [はい（Yes）]、復号ルールでは [いいえ（No）] をクリックします。次に例を示します。

  • [復号 - 再署名（Decrypt - Resign）] ルールを設定している場合、デフォルトの動作は、期限切れの証明書でのトラフィックを復号します。その動作を変更するには、[期限切れ（Expired）] で [いいえ（No）] をクリックし、期限切れの証明書を持つトラフィックが復号され、再署名されないようにします。

  • [ブロック（Block）] ルールを設定している場合、デフォルトの動作は、期限切れの証明書を持つトラフィックを許可します。その動作を変更するには、[期限切れ（Expired）] で [はい（Yes）] をクリックし、期限切れの証明書を持つトラフィックをブロックします。

次の表は、暗号化用のサーバー証明書のステータスを基準に、システムが暗号化トラフィックを評価する方法を示しています。

表 1. 証明書ステータスのルール条件の基準

ステータスの確認

[はい（Yes）] を設定

[いいえ（No）] を設定

失効（Revoked）

ポリシーは、サーバ証明書を発行した CA を信頼しており、ポリシーにアップロードされた CA 証明書にはこのサーバ証明書を失効させる CRL が含まれています。

ポリシーは、サーバ証明書を発行した CA を信頼しており、ポリシーにアップロードされた CA 証明書にはこのサーバ証明書を失効させる CRL が含まれていません。

自己署名（Self-signed）

検出されたサーバ証明書が、同じサブジェクトと発行元の識別名を含んでいます。

検出されたサーバ証明書が、異なるサブジェクトと発行元の識別名を含んでいます。

有効（Valid）

以下のすべてを満たしています。

  • ポリシーが証明書を発行した CA を信用できる。

  • 署名は有効である。

  • 発行元は有効である。

  • ポリシーの信頼できる CA のいずれも証明書を失効させていません。

  • 現在の日付が証明書の有効期間の開始日と終了日の範囲内にある。

以下の 1 つ以上を満たしています。

  • 証明書を発行した CA をポリシーが信頼していない。

  • 署名が無効である。

  • 発行元が無効である。

  • ポリシーの信用できる CA の 1 つが原因で証明書が失効している。

  • 現在の日付が証明書の有効期間の開始日より前です。

  • 現在の日付が証明書の有効期限の終了日より後です。

署名が無効（Invalid signature）

証明書の内容に対して証明書の署名が適切に検証されません。

証明書の内容に対して証明書の署名が適切に検証されます。

発行元が無効（Invalid issuer）

発行元の CA 証明書が、ポリシーの信頼できる CA 証明書のリストに登録されていません。

発行元の CA 証明書が、ポリシーの信頼できる CA 証明書のリストに登録されています。

期限切れ

現在の日付が証明書の有効期限の終了日より後です。

現在の日付が証明書の有効期限の終了日であるかそれより前です。

まだ無効（Not yet valid）

現在の日付が証明書の有効期間の開始日より前です。

現在の日付が証明書の有効期間の開始日であるかそれより後です。

無効な証明書

証明書が有効ではありません。以下の 1 つ以上を満たしています。

  • 証明書の拡張子が無効であるか一貫していません。つまり、証明書の拡張子に無効な値（たとえば間違ったエンコーディング）が含まれているか、他の拡張子と矛盾する値がいくつか含まれています。

  • 指定された目的に証明書を使用できません。

  • 基本的制約のパス長パラメータを超過しています。

    詳細については、RFC 5280、セクション 4.2.1.9 を参照してください。

  • 証明書の発行日付または有効期限の値が無効です。これらの日付は、UTCTime または GeneralizedTime としてエンコードできます。

    詳細については、RFC 5280、セクション 4.1.2.5 を参照してください。

  • 名前制約の形式が認識されていません。たとえば、電子メールアドレス形式のフォームは RFC 5280、セクション 4.2.1.10 で言及されていません。これは、不適切な拡張子や、一部の新機能が現時点でサポートされていないことが原因で発生する場合があります。

    サポートされていない名前制約タイプが見つかりました。OpenSSL では、ディレクトリ名、DNS 名、電子メール、および URI タイプのみがサポートされています。

  • 指定された目的に関してルート認証局を信頼できません。

  • ルート認証局が指定された目的を拒否しています。

証明書は有効です。以下のすべてを満たしています。

  • 有効な証明書の拡張子。

  • 指定した目的に証明書を使用できる。

  • 有効な基本的制約のパス長。

  • 有効な発行日付または有効期限の値。

  • 有効な名前制約。

  • 指定された目的に関してルート証明書を信頼できる。

  • ルート証明書が指定した目的を受け入れている。

無効な CRL

証明書失効リスト（CRL）のデジタル署名が有効ではありません。以下の 1 つ以上を満たしています。

  • CRL の [次回の更新（Next Update）] または [最後の更新（Last Update）] フィールドの値が無効である。

  • CRL がまだ有効ではない。

  • CRL の期限が切れている。

  • CRL パスを確認する際にエラーが発生した。拡張 CRL の確認が有効になっている場合にのみ、このエラーが発生する。

  • CRL が検出できない。

  • 検出できた唯一の CRL が証明書の範囲と一致しなかった。

CRL が無効です。以下のすべてを満たしています。

  • [次回の更新（Next Update）] と [最後の更新（Last Update）] フィールドの値が有効である。

  • CRL の日付が有効である。

  • パスが有効である。

  • CRL が検出された。

  • CRL が証明書の範囲と一致する。

サーバーの不一致

サーバ名がサーバのサーバ名指定（SNI）名と一致しません。これは、サーバ名を偽装しようとする試みを示している可能性があります。

サーバ名は、クライアントがアクセスを要求しているサーバの SNI 名と一致します。

1 つの証明書が複数のステータスに一致する場合でも、ルールがトラフィックに行うアクションは一度に 1 つだけであることに注意してください。

CA が証明書を発行したか失効したかを確認するには、ルートおよび中間 CA 証明書とその関連 CRL をオブジェクトとしてアップロードする必要があります。その後で SSL ポリシーの信頼できる CA 証明書のリストに、これらの信頼できる CA のオブジェクトを追加します。

外部認証局の信頼

SSL ポリシーでルートおよび中間 CA 証明書を追加することで信頼できる CA が設定され、トラフィックの暗号化に使用されているサーバー証明書の検証に、これらの信頼できる CA を使用できるようになります。

信頼できる CA 証明書の中にアップロードされた証明書失効リスト（CRL）が含まれている場合は、信頼できる CA により、暗号化証明書が失効されているかどうかも確認できます。

手順
ステップ 1

SSL ルールエディタで、[信頼できるCA証明書（Trusted CA Certificates）] を選択します。

ステップ 2

次のように、[使用可能な信頼できる CA（Available Trusted CAs）] で追加する信頼できる CA を見つけます。

  • ここで信頼できる CA のオブジェクトを作成してリストに追加するには、[使用可能な信頼できるCA（Available Trusted CAs）] リストの上にある をクリックします。

  • 追加する信頼できる CA オブジェクトおよびグループを検索するには、[使用可能な信頼できる CA（Available Trusted CAs）] リストの上にある [名前または値で検索（Search by name or value）] プロンプトをクリックし、オブジェクトの名前またはオブジェクトの値を入力します。入力すると、リストが更新されて一致するオブジェクトが表示されます。

ステップ 3

オブジェクトを選択するには、そのオブジェクトをクリックします。すべてのオブジェクトを選択するには、右クリックして [すべて選択（Select All）] を選択します。

ステップ 4

[ルールに追加（Add to Rule）] をクリックします。

ヒント 

選択したオブジェクトをドラッグ アンド ドロップすることもできます。

ステップ 5

ルールを追加するか、編集を続けます。

次のタスク
信頼できる外部認証局の設定

検証されたサーバー証明書には、信頼できる CA によって署名された証明書が含まれます。TLS/SSL ポリシーに信頼できる CA 証明書を追加した後は、トラフィックと照合する証明書ステータス条件を SSL ルールに設定することができます。


ヒント

信頼できるルート CA の信頼チェーン内にあるすべての証明書を、信頼できる CA 証明書のリストにアップロードしますが、これにはルート CA 証明書およびすべての中間 CA 証明書が含まれます。これを行わないと、中間 CA から発行された信頼できる証明書の検出が困難になります。また、ルート発行者 CA に基づいてトラフィックを信頼するように証明書ステータス条件を設定する場合、信頼できる CA の信頼チェーン内のすべてのトラフィックは、復号する必要はなく、復号せずに許可することができます。

SSL ポリシーを作成すると、[信頼できる CA 証明書（Trusted CA Certificates）] タブにデフォルトの信頼できる CA オブジェクト グループ Cisco Trusted Authorities が入力されます。

このグループ内の各エントリは変更が可能で、SSL ポリシーにこのグループを含めるかどうかを選択できます。このグループを削除することはできません。システムによる更新によりこのリストのエントリが変更されることがありますが、ユーザーによる変更は保持されます。

証明書ステータスでのトラフィックの照合

始める前に

  • 信頼できる CA オブジェクトまたはグループを SSL ポリシーに追加します。詳細については、外部認証局の信頼を参照してください。

手順

ステップ 1

Firepower Management Center で、[ポリシー（Policies）] > [アクセス コントロール（Access Control）] > [SSL] を選択します。

ステップ 2

新しいポリシーを追加するか、既存のポリシーを編集します。
ステップ 3

新しい TLS/SSL ルールを追加するか、既存のルールを編集します。

ステップ 4

[ルールの追加（Add Rule）] または [ルールの編集（Editing Rule）] ダイアログボックスで [証明書ステータス（Cert Status）] を選択します。
ステップ 5

各証明書ステータスには次のオプションがあります。

  • 該当する証明書ステータスが存在するときに照合する場合は、[はい（Yes）] を選択します。

  • 該当する証明書ステータスが存在しないときに照合する場合は、[いいえ（No）] を選択します。

  • ルールが一致する場合、[任意（Any）] を選択して条件をスキップします。つまり、[任意（Any）] を選択すると、証明書ステータスの有無に関わらずルールは一致します。

ステップ 6

ルールを追加するか、編集を続けます。

例

組織は Verified Authority という認証局を信頼しています。組織は Spammer Authority という認証局を信頼していません。システム管理者は、Verified Authority の証明書および、Verified Authority の発行した中間 CA 証明書をアップロードします。Verified Authority が以前に発行した証明書の 1 つを失効させたため、システム管理者は Verified Authority から提供された CRL をアップロードします。

次の図は、有効な証明書をチェックする証明書ステータスのルール条件を示しています。これにより、Verified Authority から発行されたが CRL には登録されておらず、現状で有効期間の開始日と終了日の範囲内にあるかどうかがチェックされます。この設定では、これらの証明書で暗号化されたトラフィックはアクセス コントロールにより復号および検査されません。

有効な日付を持つ CRL にない有効な証明書に一致するルール条件を持つ SSL ポリシーの例

次の図は、ステータスが存在しないことをチェックする証明書ステータスのルール条件を示しています。この設定では、期限切れになっていない証明書を使用して暗号化されたトラフィックと照合し、そのトラフィックをモニターします。

ステータスが存在しない条件に一致するルール条件を持つ SSL ポリシーの例

次の図は、さまざまなステータスの有無に一致する証明書ステータスのルール条件を示しています。この設定でルールが一致するのは、着信トラフィックを暗号化した証明書が無効なユーザが発行元、自己署名、無効、または期限切れであった場合で、そうしたトラフィックを既知のキーで復号します。

いくつかの基準を使用する、SSL ポリシールールのマッチングの例

次の図は、要求の SNI がサーバー名に一致する、または CRL が有効でない場合に一致する証明書ステータスのルール条件を示しています。この設定のため、ルールがいずれかの条件に一致する場合に、トラフィックがブロックされます。

サーバー SNI 名または無効な CRL に一致する SSL ポリシールールの例

次のタスク

暗号スイートの TLS/SSL ルール条件

暗号スイートのルール条件に追加できる、システム定義の暗号スイートが提供されています。複数の暗号スイートを含む、暗号スイートのリストのオブジェクトを追加することもできます。


（注）  

新しい暗号スイートを追加することはできません。定義済みの暗号スイートは変更も削除もできません。

1 つの暗号スイート条件で、[選択した暗号スイート（Selected Cipher Suites）] リストに最大 50 の暗号スイートおよび暗号スイート リストを追加できます。暗号スイート条件に追加できる暗号スイートとして、次のものがサポートされています。

  • SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

  • SSL_RSA_FIPS_WITH_DES_CBC_SHA

  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA

  • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256

  • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA

  • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

  • TLS_DHE_RSA_WITH_DES_CBC_SHA

  • TLS_DH_Anon_WITH_AES_128_GCM_SHA256

  • TLS_DH_Anon_WITH_AES_256_GCM_SHA384

  • TLS_DH_Anon_WITH_CAMELLIA_128_CBC_SHA

  • TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256

  • TLS_DH_Anon_WITH_CAMELLIA_256_CBC_SHA

  • TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_NULL_SHA

  • TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_NULL_SHA

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA

  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_256_CBC_SHA256

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

  • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256

  • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

  • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256

  • TLS_RSA_WITH_DES_CBC_SHA

  • TLS_RSA_WITH_NULL_MD5

  • TLS_RSA_WITH_NULL_SHA

  • TLS_RSA_WITH_RC4_128_MD5

  • TLS_RSA_WITH_RC4_128_SHA

次の点に注意してください。

  • 展開でサポートされていない暗号スイートを追加すると、設定を展開できません。たとえば、パッシブ展開では、一時 Diffie-Hellman（DHE）および一時的楕円曲線 Diffie-Hellman（ECDHE）暗号スイートを使用したトラフィックの復号がサポートされません。それらの暗号スイートを使用してルールを作成すると、アクセス コントロール ポリシーを展開できなくなります。

  • 暗号スイート条件に暗号スイートを設定する場合は、証明書条件に追加する外部証明書オブジェクト、または [復号 - 再署名（Decrypt - Resign）] アクションに関連付ける内部 CA オブジェクトが、暗号スイートの署名アルゴリズム タイプと一致している必要があります。たとえば、ルールの暗号スイート条件で EC ベースの暗号スイートを参照する場合、追加するサーバ証明書または [復号 - 再署名（Decrypt - Resign）] アクションに関連付ける CA 証明書も EC ベースである必要があります。署名アルゴリズム タイプの不一致が検出されると、ポリシー エディタでルールの横に警告アイコンが表示されます。

  • SSL ルールの暗号スイート条件に匿名の暗号スイートを追加できますが、次の点に注意してください。

    • ClientHello 処理中に自動的に匿名の暗号スイートが削除されます。ルールを使用するシステムでは、ClientHello の処理を防止するために TLS/SSL ルールを設定する必要があります。詳細については、SSL ルールの順序を参照してください。

    • システムでは、匿名の暗号スイートで暗号化されたトラフィックは復号できないため、ルールに [復号 - 再署名（Decrypt - Resign）] または [復号 - 既知のキー（Decrypt - Known Key）] アクションを使用できません。

  • 暗号スイートをルール条件として指定する際、ルールを ClientHello メッセージで指定された暗号スイートの完全なリストではなく、ServerHello メッセージのネゴシエートされた暗号スイートと照合することを検討してください。ClientHello の処理中に、管理対象デバイスは ClientHello メッセージからサポートされていない暗号スイートを削除します。ただし、これにより指定されたすべての暗号スイートが削除されることになる場合、システムでは元のリストを保持します。システムがサポートされていない暗号スイートを保持する場合、後続の評価は復号されていないセッションになります。

暗号スイートによる暗号化トラフィックの制御

手順

ステップ 1

SSL ルールエディタで、[暗号スイート（Cipher Suite）] を選択します。

ステップ 2

[使用可能な暗号スイート（Available Cipher Suites）] で、追加する暗号スイートを探します。

  • ここで暗号スイートリストを作成してリストに追加するには（後で条件に追加できます）、[使用可能な暗号スイート（Available Cipher Suites）] リストの上にある をクリックします。

  • 追加する暗号スイートおよびリストを検索するには、[使用可能な暗号スイート（Available Cipher Suites）] リストの上にある [名前または値で検索（Search by name or value）] プロンプトをクリックし、暗号スイートの名前または暗号スイートの値を入力します。入力を開始するとリストが更新され、一致する暗号スイートが表示されます。

ステップ 3

暗号スイートをクリックして選択します。すべての暗号スイートを選択するには、右クリックして [すべて選択（Select All）] を選択します。

ステップ 4

[ルールに追加（Add to Rule）] をクリックします。

ヒント 

選択した暗号スイートをドラッグ アンド ドロップでリストに追加することもできます。

ステップ 5

ルールを追加するか、編集を続けます。

次のタスク

暗号化プロトコル バージョンの TLS/SSL ルール条件

SSL バージョン 3.0 または TLS バージョン 1.0、1.1、1.2 のいずれかで暗号化されたトラフィックとの照合を選択できます。デフォルトでは、ルールの作成時にすべてのプロトコルのバージョンが選択されます。複数のバージョンが選択されている場合、いずれかのバージョンと一致する暗号化トラフィックがルールに一致したと判定されます。ルール条件を保存するには、最低 1 つのプロトコル バージョンを選択する必要があります。

バージョンのルール条件で SSL バージョン 2.0 を選択することはできません。これは、SSL バージョン 2.0 で暗号化されたトラフィックの復号化がサポートされていないためです。復号できないアクションを設定すれば、それ以上のインスペクションなしで、これらのトラフィックを許可またはブロックできます。

暗号化プロトコルのバージョンによるトラフィックの制御

手順

ステップ 1

SSL ルールエディタで、[バージョン（Version）] を選択します。

ステップ 2

照合するプロトコル バージョンを選択します。

ステップ 3

ルールを追加するか、編集を続けます。

次のタスク