管理対象デバイスが暗号化されたトラフィックを処理する場合にのみ、[復号 - 再署名（Decrypt - Resign）] または [復号 - 既知のキー（Decrypt - Known Key）] のルールをセットアップします。復号ルールには、パフォーマンスに影響を及ぼす可能性があるオーバーヘッドの処理が必要です。

パッシブまたはインライン タップ モード インターフェイスを使用するデバイスでトラフィックを復号化することはできません。

RC4 暗号スイーツはサポートされていません

Rivest Cipher 4（RC4 または ARC4 ともいう）暗号スイーツは脆弱性があることで知られており、安全でないと見なされています。SSL ポリシーでは RC4 暗号スイートをサポート対象外として識別しています。組織の要件と一致するようにポリシーの [復号不可のアクション（Undecryptable Actions）] ページの [サポート対象外の暗号スイート（Unsupported Cipher Suite）] のアクションを設定する必要があります。詳細については、復号できないトラフィックのデフォルト処理オプションを参照してください。

パッシブおよびインライン タップ モードのインターフェイスはサポートされていません。

TLS/SSL トラフィックはパッシブまたはインライン タップ モードのインターフェイスでは復号できません。

ルール名でサポートされていない文字

TLS/SSL ルール ルール名にアクセント付き文字（Comunicación など）を使用しないでください。使用すると、ポリシーが管理対象デバイスに展開されません。

TLS 1.3 はサポートされません

Firepower システムは現在、TLS バージョン 1.3 の暗号化または復号化をサポートしていません。ユーザーが TLS 1.3 暗号化をネゴシエートする Web サイトにアクセスすると、Web ブラウザに次のようなエラーが表示されることがあります。

• ERR_SSL_PROTOCOL_ERROR

• SEC_ERROR_BAD_SIGNATURE

• ERR_SSL_VERSION_INTERFERENCE

この動作を制御する方法の詳細については、Cisco TAC にお問い合わせください。

次によって禁止されている場合は、トラフィックを復号してはいけません。

• 法律：たとえば、一部の法域では、財務情報の復号化が禁止されています

• 会社のポリシー：たとえば、会社によって特権的な通信の復号化が禁止されている場合があります

• プライバシー規制

• 証明書のピン留め（TLS/SSL ピニングとも呼ばれる）を使用するトラフィックは、接続の切断を防ぐため、暗号化されたままにする必要があります

特定の種類のトラフィックで復号をバイパスする場合、トラフィックの処理は行われません。暗号化トラフィックは最初に SSL ポリシーによって評価され、次にアクセス コントロール ポリシーに進みます。この場合、最終的な許可またはブロックの決定が行われます。暗号化されたトラフィックは、次のものを含むがこれらに限定されない任意の TLS/SSL ルール条件で許可またはブロックできます。

• 証明書のステータス（期限切れまたは無効な証明書など）

• プロトコル（セキュアでない SSL プロトコルなど）

• ネットワーク（セキュリティ ゾーン、IP アドレス、VLAN タグなど）

• 正確な URL または URL カテゴリ

• ポート

• ユーザー グループ

[Decrypt - Resign] アクションには、1 つの内部認証局（CA）証明書と秘密キーを関連付けることができます。トラフィックがこのルールに一致した場合、システムは CA 証明書を使用してサーバー証明書を再署名してから、中間者（man-in-the-middle）として機能します。ここでは 2 つの TLS/SSL セッションが作成され、1 つはクライアントと管理対象デバイスの間、もう 1 つは管理対象デバイスとサーバの間で使用されます。各セッションにはさまざまな暗号セッションの詳細が含まれており、システムはこれを使用することでトラフィックの復号化と再暗号化が行えます。

ベスト プラクティス

次の点を推奨します。

• [Decrypt - Known Key] ルールアクションを推奨する着信トラフィックとは対照的に、発信トラフィックの復号化に対しては [Decrypt - Resign] ルールアクションを使用します。

  [復号 - 既知のキー（Decrypt - Known Key）] の詳細については、TLS/SSL 復号化：既知のキーのガイドラインを参照してください。

• [復号-再署名（Decrypt - Resign）] ルールアクションを設定する場合は、必ず [キーのみを置換（Replace Key Only）] チェックボックスをオンにします。

  ユーザーが自己署名証明書を使用する web サイトを参照すると、web ブラウザにセキュリティ警告が表示され、セキュリティで保護されていないサイトと通信していることに気付きます。

  ユーザーが信頼できる証明書を使用する web サイトを参照すると、セキュリティ警告は表示されません。

詳細

[復号 - 再署名（Decrypt - Resign）] アクションをルールに設定すると、ルールによるトラフィックの照合は、設定されている他のルール条件に加えて、参照する内部 CA 証明書の署名アルゴリズム タイプに基づいて実施されます。各 [復号 - 再署名（Decrypt - Resign）] アクションにはそれぞれ 1 つの CA 証明書が関連付けられるので、異なる署名アルゴリズムで暗号化された複数のタイプの発信トラフィックを復号化する TLS/SSL ルールは作成できません。また、ルールに追加する暗号スイートと外部証明書のオブジェクトのすべては、関連する CA 証明書の暗号化アルゴリズム タイプに一致する必要があります。

たとえば、楕円曲線暗号（EC）アルゴリズムで暗号化された発信トラフィックが [復号 - 再署名（Decrypt - Resign）] ルールに一致するのは、アクションが EC ベースの CA 証明書を参照している場合だけです。証明書と暗号スイートのルール条件を作成する場合は、EC ベースの外部証明書と暗号スイートをルールに追加する必要があります。

同様に、RSA ベースの CA 証明書を参照する [復号 - 再署名（Decrypt - Resign）] ルールは、RSA アルゴリズムで暗号化された発信トラフィックとのみ一致します。EC アルゴリズムで暗号化された発信トラフィックは、設定されている他のルール条件がすべて一致したとしても、このルールには一致しません。

注意事項と制約事項

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

匿名の暗号スイートはサポート対象外

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 の付録 F.1.1.1 を参照してください。（TLS 1.3 では、代わりに RFC 8446 付録 C.5 を参照してください。）

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

[復号 - 再署名（Decrypt - Resign）] ルールアクションと証明書署名要求

[復号-再署名（Decrypt - Resign）] ルールアクションを使用するには、証明書署名要求（CSR）を作成し、信頼された証明機関によって署名する必要があります。（FMC を使用して CSR を作成できます：[オブジェクト（Objects）] > [オブジェクト管理（Object Management）] > [PKI] > [内部CA（Internal CAs）]。）

[復号-再署名（Decrypt - Resign）] ルールで使用するには、認証局（CA）に次の拡張機能の少なくとも 1 つが必要です。

• CA: TRUE

  詳細については、RFC3280、セクション 4.2.1.10 にある、基本制約に関する説明を参照してください。

• KeyUsage=CertSign

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

CSR または CA に前述の拡張機能の少なくとも 1 つがあることを確認するには、openssl のドキュメントなどの参考資料で説明されている、openssl コマンドを使用できます。

これが必要なのは、[復号化-再署名（Decrypt - Resign）] インスペクションが機能するために、TLS/SSL ポリシーで使用された証明書がオンザフライで証明書を生成し、中間者として機能し、すべての TLS/SSL 接続をプロキシするようにそれらに署名するためです。

一致しない暗号スイート

証明書と一致しない暗号スイートで TLS/SSL ルールを保存しようとすると、次のエラーが表示されます。この問題を解決するには、TLS/SSL 暗号スイートの確認 を参照してください。

Traffic cannot match this rule; none of your selected cipher suites contain a 
signature algorithm that the resigning CA's signature algorithm

信頼できない認証局

サーバー証明書の再署名に使用する認証局（CA）をクライアントが信頼していない場合、証明書が信頼できないという警告がユーザーに出されます。これを防止するには、クライアントの信用できる CA ストアに CA 証明書をインポートします。または組織にプライベート PKI がある場合は、組織の全クライアントで自動的に信頼されるルート CA が署名する中間 CA 証明書を発行して、その CA 証明書をデバイスにアップロードすることもできます。

HTTP プロキシの制限

クライアントと管理対象デバイスの間に HTTP プロキシがあって、クライアントとサーバーが CONNECT HTTP メソッドを使用してトンネル TLS/SSL 接続を確立する場合、システムはトラフィックを復号化できません。システムによるこのトラフィックの処理法は、ハンドシェイク エラー（Handshake Errors）の復号できないアクションが決定します。

署名済み CA のアップロード

内部 CA オブジェクトを作成して証明書署名要求（CSR）の生成を選択した場合は、オブジェクトに署名付き証明書をアップロードするまで、この CA を [復号 - 再署名（Decrypt - Resign）] アクションに使用できません。

信頼ルールによるトラフィックブロック

場合によっては、アクセス制御の信頼ルールアクションが一致する TLS/SSL トラフィックをブロックすることがあります。この問題は、ASA 5555-X デバイスなど、FirePOWER サービスを備えた ASA を実行できるすべての ASA デバイスに限定されます。

次の注意事項に従ってください。

• [Decrypt - Resign] または [Do Not Decrypt] のルールのアクションのいずれかと一致する TLS/SSL トラフィックの場合は、アクセス制御の許可ルールのアクションが信頼ルールのアクションよりも前に配置されていることを確認します。

• SSL ポリシーがない場合は、アクセス制御の信頼ルールのアクションに問題はありません。

FirePOWER サービスを備えた ASA を実行できるデバイスのリストについては、Cisco ASA の互換性の「ASA and ASA FirePOWER Module Compatibility」の項を参照してください。

特定のルール条件の使用

（注）	[暗号スイート（Cipher Suite）] と [バージョン（Version）] のルール条件は、[ブロック（Block）] または [リセットしてブロック（Block with reset）] のルールアクションが使用されているルールでのみ使用します。これらの条件をルールで他のルールアクションとともに使用すると、システムの ClientHello 処理に干渉し、予測できないパフォーマンスが生じる可能性があります。

[復号 - 既知のキー（Decrypt - Known Key）] アクションを設定した場合は、1 つまたは複数のサーバー証明書と秘密キー ペアをアクションに関連付けることができます。トラフィックがルールに一致して、トラフィックの暗号化に使用された証明書とアクションに関連付けられた証明書が一致した場合、システムは適切な秘密キーを使用してセッションの暗号化と復号キーを取得します。秘密キーへのアクセスが必要なため、このアクションが最も適しているのは、組織の管理下にあるサーバーへの入力トラフィックを復号する場合です。

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

匿名の暗号スイートはサポート対象外

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 の付録 F.1.1.1 を参照してください。（TLS 1.3 では、代わりに RFC 8446 付録 C.5 を参照してください。）

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

識別名または証明書が一致しない

[復号 - 既知のキー（Decrypt - Known Key）] アクションを指定して TLS/SSL ルールを作成した場合は、[識別名（Distinguished Name）] や [証明書（Certificate）] 条件による照合はできません。ここでの前提は、このルールがトラフィックと一致する場合、証明書、サブジェクト DN、および発行元 DN は、ルールに関連付けられた証明書とすでに一致済みであることです。

署名アルゴリズムの不一致

[復号 - 再署名（Decrypt - Resign）] アクションをルールに設定し、1 つまたは複数の外部証明書オブジェクトまたは暗号スイートで署名アルゴリズムタイプの不一致が生じた場合、ポリシーエディタでルールの横に[情報（Information）]（ ）が表示されます。すべての外部証明書オブジェクトまたはすべての暗号スイートで署名アルゴリズムタイプの不一致が生じた場合、ポリシーのルールの横には警告アイコンが表示され、SSL ポリシーに関連付けたアクセス コントロール ポリシーは適用できなくなります。

証明書のピン留め

ブラウザが証明書ピニングを使用してサーバー証明書を確認する場合は、サーバー証明書に再署名しても、このトラフィックを復号できません。このトラフィックを許可するには、サーバー証明書の共通名または識別名と一致させるために、[復号しない（Do not decrypt）] アクションを使用して TLS/SSL ルールを設定します。

特定のルール条件の使用

（注）	[暗号スイート（Cipher Suite）] と [バージョン（Version）] のルール条件は、[ブロック（Block）] または [リセットしてブロック（Block with reset）] のルールアクションが使用されているルールでのみ使用します。これらの条件をルールで他のルールアクションとともに使用すると、システムの ClientHello 処理に干渉し、予測できないパフォーマンスが生じる可能性があります。

[インタラクティブ ブロック（Interactive Block）] または [リセット付きインタラクティブ ブロック（Interactive Block with reset）] アクション付きのアクセス コントロール ルールと復号化トラフィックが一致する場合、システムは応答ページを表示します。

ルールでロギングを有効にすると、（[分析（Analysis）] > [イベント（Events）] > [接続（Connections）] で）2 つの接続イベントが表示されます。インタラクティブ ブロックのイベントと、ユーザーがサイトの継続を選択したかどうかを示す別のイベントです。

一部のアプリケーションでは、アプリケーション自体に元のサーバー証明書のフィンガープリントを埋め込む、ピニングまたは証明書ピニングと呼ばれる技術が使用されます。TLS/SSL そのため、[復号 - 再署名（Decrypt - Resign）] アクションで TLS/SSL ルールを設定した場合は、アプリケーションが管理対象デバイスから再署名された証明書を受信すると、検証が失敗し、接続が中断されます。

TLS/SSL のピン留めは中間者攻撃を避けるために使用されるため、防止または回避する方法はありません。次の選択肢があります。

• そのアプリケーション用に、[復号-再署名（Decrypt - Resign）] ルールよりも順序が前の、[復号しない（Do Not Decrypt）] ルールを作成します。

• Web ブラウザを使用してアプリケーションにアクセスするようユーザに指示します。

ルールの順序の詳細については、SSL ルールの順序を参照してください。

アプリケーションが TLS/SSL のピン留めを使用しているかどうかを判断するには、TLS/SSL ピニングのトラブルシューティングを参照してください。

一部のアプリケーションでは、RFC6520 で定義されている Transport Layer Security（TLS）および Datagram Transport Layer Security（DTLS）プロトコルに対して、TLS ハートビート エクステンションが使用されます。TLS ハートビートは、接続がまだ有効であることを確認する方法を提供します。クライアントまたはサーバが指定されたバイト数のデータを送信し、応答を返すように相手に要求します。これが成功した場合は、暗号化されたデータが送信されます。

ネットワーク分析ポリシー（NAP）で [最大ハートビート長（Max Heartbeat Length）] を設定して TLS ハートビートの処理方法を決定できます。詳細については、SSL プリプロセッサを参照してください。

詳細については、TLS ハートビートについてを参照してください。

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 の付録 F.1.1.1 を参照してください。（TLS 1.3 では、代わりに RFC 8446 付録 C.5 を参照してください。）

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

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

インライン正規化プリプロセッサで [余剰ペイロードの正規化（Normalize Excess Payload）] オプションを有効にすると、プリプロセッサによる復号トラフィックの標準化時に、パケットがドロップされてトリミングされたパケットに置き換えられる場合があります。これで TLS/SSL セッションは終了しません。トラフィックが許可された場合、トリミングされたパケットは TLS/SSL セッションの一部として暗号化されます。

ユーザーとグループ

ルールにグループまたはユーザを追加した後、そのグループまたはユーザを除外するようにレルムの設定を変更すると、ルールは適用されなくなります。（レルムを無効にする場合も同様です。）レルムの詳細については、レルムおよびレルムディレクトリの作成を参照してください。

TLS/SSL ルールのカテゴリ

SSL ポリシーに [復号-再署名（Decrypt - Resign）] アクションがあるにもかかわらず Web サイトが復号されない場合は、そのポリシーに関連付けられているルールの [カテゴリ（Category）] ページを確認します。

場合によっては、認証などの目的で Web サイトが別のサイトにリダイレクトされ、リダイレクト先のサイトの URL カテゴリが復号を試みているサイトとは異なることがあります。たとえば、gmail.com（[Webベース電子メール（Web based email）] カテゴリ）は認証のために accounts.gmail.com（[インターネットポータル（Internet Portals）] カテゴリ）にリダイレクトされます。関連するすべてのカテゴリを必ず SSL ルールに含めます。

（注）	URL カテゴリに基づいてトラフィックを完全に処理するには、URL フィルタリングも設定する必要があります。URL フィルタリングの章を参照してください。

ローカル データベースにない URL のクエリ

[復号-再署名（Decrypt - Resign）] ルールを作成し、ローカル データベースにカテゴリとレピュテーションがない Web サイトをユーザが参照すると、データが復号されないことがあります。一部の Web サイトはローカル データベースで分類されません。分類されない場合、その Web サイトのデータはデフォルトでは復号されません。

この動作は [システム（System）] > [統合（Integration）] > の設定を使用し [Cloud Services]、[不明 URL を Cisco Cloud に問い合わせる（Query Cisco cloud for unknown URLs）] を使用して制御できます。

このオプションの詳細については、シスコ クラウドを参照してください。

暗号化セッションの特性に基づいた暗号化トラフィックの制御および暗号化トラフィックの復号には、再利用可能な公開キー インフラストラクチャ（PKI）オブジェクトの作成が必要です。この情報の追加は、信頼できる認証局（CA）の証明書の SSL ポリシーへのアップロード時、SSL ルール条件の作成時、およびプロセスでの関連オブジェクトの作成時に、臨機応変に実行できます。ただし、これらのオブジェクトを事前に設定しておくと、不適切なオブジェクトが作成される可能性を抑制できます。

証明書とキー ペアによる暗号化トラフィックの復号化

セッション暗号化に使用するサーバー証明書と秘密キーをアップロードして内部証明書オブジェクトを設定しておくと、システムは着信する暗号化トラフィックを復号できます。[復号 - 既知のキー（Decrypt - Known Key）] アクションが設定された SSL ルールでそのオブジェクトを参照し、当該ルールにトラフィックが一致すると、システムはアップロードされた秘密キーを使用してセッションを復号します。

CA 証明書と秘密キーをアップロードして内部 CA オブジェクトを設定した場合、システムは発信トラフィックの復号化もできます。[復号 - 再署名（Decrypt - Resign）] アクションが設定された TLS/SSL ルールでそのオブジェクトを参照し、当該ルールにトラフィックが一致すると、システムはクライアント ブラウザに渡されたサーバー証明書を再署名した後、中間者（man-in-the-middle）としてセッションを復号します。オプションで、証明書全体ではなく自己署名証明書キーのみを置き換えることができます。この場合、ユーザはブラウザで自己署名証明書キー通知を確認します。

暗号化セッションの特性に基づいたトラフィック制御

システムによる暗号化トラフィックの制御は、セッション ネゴシエートに使用されたサーバー証明書または暗号スイートに基づいて実行できます。複数の異なる再利用可能オブジェクトの 1 つを設定し、TLS/SSL ルール条件でオブジェクトを参照してトラフィックを照合することができます。次の表に、設定できる再利用可能なオブジェクトのタイプを示します。

SSL ポリシーで TLS/SSL ルールを作成する場合、ルール エディタの [挿入（Insert）] リストを使用してその位置を指定します。SSL ポリシー内の TLS/SSL ルールには、1 から始まる番号が付けられています。システムは、ルール番号の昇順で上から順に、TLS/SSL ルールをトラフィックと照合します。

ほとんどの場合、システムによるネットワーク トラフィックの処理は、すべてのルールの条件がトラフィックに一致する最初の TLS/SSLSSL ルールに従って行われます。モニター ルール（トラフィックをログに記録するがトラフィック フローには影響しないルール）の場合を除き、システムは、そのトラフィックがルールに一致した後、追加の優先順位の低いルールに対してトラフィックを評価し続けることはありません。こうした条件には、単純なものと複雑なものがあります。セキュリティ ゾーン、ネットワークまたは地理的位置、VLAN、ポート、アプリケーション、要求された URL、ユーザー、証明書、証明書の識別名、証明書ステータス、暗号スイート、暗号化プロトコル バージョンなどによってトラフィックを制御できます。

各ルールにはアクションも設定されます。アクションにより、アクセス制御と一致する暗号化または復号化トラフィックに対してモニター、ブロック、検査のいずれを行うかが決まります。システムがブロックした暗号化トラフィックは、それ以上のインスペクションが行われないことに注意してください。暗号化されたトラフィックおよび復号化できないトラフィックはアクセス コントロールの対象です。ただし、アクセス コントロール ルールの条件では暗号化されていないトラフィックを必要とするため、暗号化されたトラフィックに一致するルール数が少なくなります。

特定の条件（ネットワークや IP アドレスなど）を使用するルールは、一般的な条件（アプリケーションなど）を使用するルールの前に順位付けする必要があります。オープン システム相互接続（OSI）モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ 1、2、および 3（物理、データリンク、およびネットワーク）の条件を持つルールは、ルールの最初に順位付けする必要があります。レイヤ 5、6、および 7（セッション、プレゼンテーション、およびアプリケーション）の条件は、ルールの後ろのほうに順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。

ヒント	適切な TLS/SSL ルールの順序を指定することで、ネットワーク トラフィックの処理に必要なリソースが削減され、ルールのプリエンプションを回避できます。ユーザーが作成するルールはすべての組織と展開に固有のものですが、ユーザーのニーズに対処しながらもパフォーマンスを最適化できるルールを順序付けする際に従うべきいくつかの一般的なガイドラインがあります。

番号ごとのルールの順序付けに加えて、カテゴリ別にルールをグループ化できます。デフォルトでは、3 つのカテゴリ（管理者、標準、ルート）があります。カスタム カテゴリを追加できますが、システム提供のカテゴリを削除したり、それらの順序を変更したりすることはできません。