Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

TLS 復号

最終更新 Markdown で表示Agent セットアップ

Cloudflare Gateway は SSL/TLS 復号 ↗ を行い、HTTPS トラフィックをマルウェアやその他のセキュリティリスクについて検査できます。HTTP ポリシーで HTTPS トラフィックを検査するには、TLS 復号が必要です。無効だと、完全な URL、ヘッダー、リクエスト本文など、HTTPS 暗号化の内側にある情報は Gateway から見えません。

TLS 復号をオンにすると、Gateway は HTTPS 経由で送られるすべてのトラフィックを復号し、HTTP ポリシーを適用してから、ユーザー側証明書 でリクエストを再暗号化します。

Cloudflare は、HTTPS リクエストの復号、検査、再暗号化をデータセンターのメモリ上だけで行い、トラフィックへの干渉を防ぎます。Gateway がディスクに保存するのは、対象となるキャッシュ内容だけです。キャッシュディスクはすべて保存時に暗号化されます。TLS 復号を行う場所は、Cloudflare Data Localization Suite (DLS) の Regional Services で設定できます。トラフィックの送信元データセンターをさらに制御するには、専用エグレス IP を使えます。

Cloudflare は、ユーザーから Gateway への接続として TLS 1.1、1.2、1.3 をサポートします。

TLS 復号をオンにする

TLS 復号をオンにするには:

  1. Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Traffic settings を開きます。
  2. Proxy and inspection で、Inspect HTTPS requests with TLS decryption をオンにします。

  1. cloudflare_api_token ↗ に次の権限を追加します。

    • Zero Trust Write

  2. cloudflare_zero_trust_gateway_settings ↗ で tls_decrypt 引数を設定します。

    resource "cloudflare_zero_trust_gateway_settings" "team_name" {
	account_id = var.cloudflare_account_id
	settings = {
		tls_decrypt = {
			enabled = true
		}
	}
}

検査の制限

Gateway は、次を使うアプリケーションの TLS 復号に対応していません。

すべてのポートで検査する

デフォルトでは、Gateway はポート 80 の HTTP トラフィックだけを検査します。TLS 復号 をオンにすると、ポート 443 の HTTPS トラフィックも検査します。

ポート 80 および 443 に加えて、他のポートの HTTP および HTTPS トラフィックを検出して検査するには、you can turn on protocol detection and configure Gateway to inspect traffic on all ports。

互換性のない証明書

証明書ピン留めと mTLS 認証を使うアプリケーションは、Cloudflare の証明書を信頼しません。たとえば、ほとんどのモバイルアプリケーションは 証明書ピン留め（certificate pinning） を使います。公開 CA が署名した証明書ではなく自己署名証明書を使うアプリケーションは、Cloudflare は信頼しません。

互換性のない証明書構成のアプリケーションで TLS 復号を行うと、アプリケーションが SSL エラーや信頼エラーを返す、または読み込みに失敗することがあります。対処するには、次のいずれかができます。

  • 対応しているアプリケーションに Cloudflare 証明書 を追加します。
  • Do Not Inspect ポリシー を作成し、アプリケーションを検査対象外にします。Application セレクター には、埋め込み証明書を使うことが分かっている信頼済みアプリケーションの一覧があります。アプリケーションまたは Web サイトに Do Not Inspect ポリシーを作成すると、HTTP リクエストのログ記録やブロック、DLP ポリシーの適用、AV スキャンはできなくなります。
  • Include モードの Split Tunnel を設定し、Gateway が自組織の IP またはドメイン宛てのトラフィックだけを検査するようにします。ユーザーの個人デバイスに Zero Trust を導入する場合や、個人向けアプリケーションの利用が見込まれる場合に有用です。

または、信頼できない証明書のサイトへアクセスしつつ HTTP フィルタリングを許可するには、Untrusted certificate action を Pass through に設定します。

Google Chrome の自動 HTTPS アップグレード

Google Chrome は、http:// を明示したリンクを選んだ場合でも、HTTP リクエストを HTTPS リクエストへ自動でアップグレードできます。Gateway でトラフィックをプロキシしてフィルタリングしていると、このアップグレードが Zero Trust ユーザーと Gateway の接続を妨げることがあります。

自動 HTTPS アップグレードは、Gateway のパススルーポリシー、Chrome のフラグ、または Chrome Enterprise ポリシーでオフにできます。

Zero Trust 組織全体で特定 URL の自動 HTTPS アップグレードを無効にするには、Gateway のパススルーポリシーを作成します。

  1. カスタムルート証明書 をデプロイします。

  2. 自動アップグレードされる URL のドメインに一致する HTTP ポリシー を作成します。例:

    セレクター 演算子 値 アクション
    URL in example.com Allow

  3. Untrusted certificate action で Pass through を選びます。

  4. Create policy を選択します。

パススルーポリシーは、Zero Trust 組織に接続しているすべてのデバイスで、安全でない接続のアップグレードをバイパスします。詳細は 信頼できない証明書 を参照してください。

ブラウザー単位で自動 HTTPS アップグレードを無効にするには、Chrome のフラグ を開き、HTTPS Upgrades をオフにします。

Chrome Enterprise のユーザーは、HttpsUpgradesEnabled 管理ポリシー ↗ で、すべての URL の自動 HTTPS アップグレードをオフにできます。

相互 TLS（mTLS）

相互 TLS（mTLS）では、クライアントとサーバーの両方が証明書を提示し、互いの身元を確認します。Gateway が TLS トラフィックを復号すると、クライアントからの接続を終端し、オリジンサーバーへの新しい接続を作ります。Gateway はクライアントの証明書をオリジンへ転送できないため、mTLS ハンドシェイクは失敗します。接続失敗を防ぐには、このトラフィック向けに Do Not Inspect ポリシー を作成します。

ESNI と ECH

ESNI または Encrypted Client Hello (ECH) の標準 ↗ に従う Web サイトは、TLS ハンドシェイク中に Server Name Indication (SNI) を暗号化するため、HTTP 検査と互換がありません。Gateway は SNI を使って HTTP リクエストをポリシーに照合します。SNI が暗号化されていると、どのポリシーを適用すべきか判断できません。ECH が失敗すると、ブラウザーは最初のリクエストの暗号化されていない SNI を使い、TLS ハンドシェイクを再試行します。この動作を避けるには、ユーザーのブラウザーで ECH を無効にできます。

SNI と SNI Domain を除く、すべての ネットワークポリシーフィルター は引き続き適用できます。ESNI と ECH のトラフィックを制限する一つの方法は、SNI ヘッダーを含まないポート 80 および 443 のトラフィックをすべて除外することです。

耐量子暗号のサポート

Gateway は、TLS 1.3 上の X25519 と MLKEM768 によるハイブリッド鍵交換で、耐量子暗号（post-quantum cryptography）をサポートします。鍵交換が完了すると、Gateway は AES-128-GCM でトラフィックを暗号化します。

詳細は 耐量子暗号 を参照してください。

FIPS 準拠

既定では、TLS 復号は TLS 1.2 と 1.3 の両方を使えます。ただし、FedRAMP などの環境では、FIPS 140-3 に準拠した暗号スイートと TLS バージョンが必要な場合があります。FIPS 準拠では、現在 TLS 1.2 が必要です。

FIPS 準拠を有効にする

  1. Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Traffic settings を開きます。
  2. Proxy and inspection で、Inspect HTTPS requests with TLS decryption をオンにします。

  1. cloudflare_api_token ↗ に次の権限を追加します。

    • Zero Trust Write

  2. cloudflare_zero_trust_gateway_settings ↗ で tls_decrypt 引数を設定します。

    resource "cloudflare_zero_trust_gateway_settings" "team_name" {
	account_id = var.cloudflare_account_id
	settings = {
		tls_decrypt = {
			enabled = true
		}
	}
}
  1. Enable only cipher suites and TLS versions compliant with FIPS 140-3 を選択します。

制限事項

FIPS 準拠を有効にすると、Gateway はオリジンへの接続時に FIPS 準拠の暗号スイート だけを選びます。オリジンが FIPS 準拠の暗号をサポートしていない場合、リクエストは失敗します。

FIPS 準拠のトラフィックは既定で HTTP/3 になります。UDP トラフィックに HTTP ポリシーを適用するには、UDP 向けの Gateway プロキシ をオンにする必要があります。

FedRAMP 準拠

米国で Cloudflare Regional Services を使い、Cloudflare One Client で TLS トラフィックを Gateway にオンランプすると、トラフィックは Cloudflare の FedRAMP 境界内にある Cloudflare データセンターから送信されます。ユーザーに最も近いデータセンターが FedRAMP 非準拠でも、トラフィックは FedRAMP 準拠のデータセンターから送信され、FedRAMP 準拠が維持されます。

flowchart LR
 %% Accessibility
 accTitle: Regional Services を使った場合に Gateway が FedRAMP 準拠トラフィックをルーティングする方法
 accDescr: 米国の Regional Services と組み合わせて Cloudflare One Client と Gateway を使うと、トラフィックが FedRAMP 準拠のデータセンターから送信される流れを示すフローチャートです。

 %% Flowchart
 subgraph s1["FedRAMP 非準拠データセンター"]
        n2["WARP TLS 暗号化を終端"]
  end
 subgraph s2["FedRAMP データセンター"]
        n3["Gateway TLS 暗号化（FIPS）を終端"]
  end
 subgraph s3["プライベート内部ネットワーク"]
        n5["FedRAMP 準拠の cloudflared"]
        n6(["プライベートサーバー"])
  end
    n1(["FedRAMP 非準拠データセンターの近くにいるユーザー"]) -- Gateway TLS 接続を WARP TLS（MASQUE）でラップ --> n2
    n2 -- Gateway TLS 接続 --> n3
    n3 <-- FIPS トンネル --> n5
    n5 --> n6

    n5@{ shape: rect}

暗号スイート

暗号スイート（cipher suite）とは、安全な通信接続を確立するための暗号アルゴリズムの集合です。広く使われている暗号スイートはいくつかあり、クライアントとサーバーは TLS 接続の確立時に使う暗号スイートに合意します。複数の暗号スイートをサポートすることで、さまざまなクライアントとの互換性を保てます。

次の表は、TLS 復号で Gateway が使う既定の暗号スイートです。

名前（OpenSSL） 名前（IANA） FIPS 準拠
ECDHE-ECDSA-AES128-GCM-SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ✅
ECDHE-ECDSA-AES256-GCM-SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ✅
ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ✅
ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ✅
ECDHE-RSA-AES128-SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ❌
ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ✅
AES128-GCM-SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 ✅
AES256-GCM-SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 ✅
AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA ❌
AES256-SHA TLS_RSA_WITH_AES_256_CBC_SHA ❌

暗号スイートの詳細は 暗号スイート を参照してください。

役に立ちましたか？