← Cloudflare One / cloudflare-one / traffic-policies / http-policies

dešifrování TLS

Cloudflare Gateway dokáže provádět Dešifrování SSL/TLS ↗ a kontrolovat provoz HTTPS na malware a další bezpečnostní rizika. Aby mohly zásady HTTP kontrolovat provoz HTTPS, je nutné dešifrování TLS. Bez něj zůstávají informace obsažené v šifrování HTTPS, jako je úplná adresa URL, hlavičky a tělo požadavku, nebude viditelné pro Gateway.

Když zapnete dešifrování TLS, Gateway dešifruje veškerý provoz odeslaný přes HTTPS, uplatní vaše zásady HTTP a poté požadavek znovu zašifruje pomocí certifikát na straně uživatele.

Cloudflare zabraňuje zásahům do provozu tím, že HTTPS požadavky dešifruje, kontroluje a znovu šifruje výhradně v paměti svých datacenter. Gateway ukládá do cache v klidovém stavu pouze způsobilý obsah. Všechny disky s cache jsou v klidovém stavu šifrované. Kde má dešifrování TLS probíhat, můžete nakonfigurovat pomocí Regional Services v Cloudflare Data Localization Suite (DLS). Chcete-li mít větší kontrolu nad tím, ze kterých datových center provoz odchází, můžete použít vyhrazené odchozí IP adresy.

Cloudflare podporuje připojení uživatelů ke Gateway přes TLS 1.1, 1.2 a 1.3.

Zapnutí dešifrování TLS

Zapnutí dešifrování TLS:

V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady provozu > Nastavení provozu.
V Proxy a kontrola, zapněte Kontrolujte HTTPS požadavky pomocí dešifrování TLS.

Přidejte následující oprávnění do svého cloudflare_api_token ↗:
- Zero Trust Write

Nakonfigurujte tls_decrypt argument v cloudflare_zero_trust_gateway_settings ↗:

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

Omezení kontroly

Gateway nepodporuje dešifrování TLS pro aplikace, které používají:

Připnutí certifikátu
Self-signed certifikáty
Ověřování Mutual TLS (mTLS)
Šifrování handshake ESNI a ECH
Automatické přepnutí na HTTPS

Kontrola na všech portech

Gateway ve výchozím nastavení kontroluje HTTP provoz jen přes port 80. Pokud navíc zapnutí dešifrování TLS, Gateway zkontroluje provoz HTTPS přes port 443.

Chcete-li detekovat a kontrolovat provoz HTTP a HTTPS na portech kromě 80 a 443, můžete zapnout detekce protokolu a nakonfigurujte Gateway tak, aby kontrolovat provoz na všech portech.

Nekompatibilní certifikáty

Aplikace používající certificate pinning a ověřování mTLS certifikátům Cloudflare nedůvěřují. Většina mobilních aplikací například používá připnutí certifikátu. Cloudflare nedůvěřuje aplikacím, které místo certifikátů podepsaných veřejnou certifikační autoritou (CA) používají self-signed certifikáty.

Pokud se pokusíte provést dešifrování TLS u aplikace s nekompatibilní konfigurací certifikátu, aplikace může vrátit chybu SSL nebo chybu důvěryhodnosti a/nebo se nemusí načíst. Problém můžete vyřešit takto:

Přidejte Certifikát Cloudflare na podporované aplikace.
Vytvořte zásada Do Not Inspect vyjmout aplikace z kontroly. Tato Výběr aplikace poskytuje seznam důvěryhodných aplikací, o kterých je známo, že používají vložené certifikáty. Upozorňujeme, že pokud pro aplikaci nebo web vytvoříte zásadu Do Not Inspect, ztratíte možnost protokolovat nebo blokovat HTTP požadavky, uplatňovat zásady DLP a provádět kontrolu antivirem.
Nakonfigurujte Split Tunnel v režimu Include, aby Gateway kontroloval pouze provoz směřující na vaše IP adresy nebo domény. To se hodí organizacím, které nasazují Zero Trust na osobní zařízení uživatelů nebo jinak počítají s používáním osobních aplikací.

Případně, chcete-li povolit filtrování HTTP při přístupu na web s nezabezpečeným certifikátem, nastavte Akce pro nedůvěryhodný certifikát na Pass through.

Automatické přechody na HTTPS v Google Chrome

Google Chrome dokáže automaticky převést požadavky HTTP na požadavky HTTPS, i když vyberete odkaz, který explicitně deklaruje http://. Když k proxy a filtrování svého provozu používáte Gateway, tento upgrade může přerušit spojení mezi vašimi uživateli Zero Trust a Gateway.

Automatické upgrady HTTPS můžete vypnout pomocí zásady Gateway typu pass through, příznaku prohlížeče Chrome nebo zásady Chrome Enterprise.

Chcete-li zakázat automatické přechody na HTTPS pro adresu URL v celé organizaci Zero Trust, vytvořte zásadu Gateway Pass Through.

Nasaďte vlastní kořenový certifikát.
Vytvořte Zásada HTTP tak, aby odpovídalo doméně URL adresy, která se automaticky převádí. Například:

Selektor Operátor Hodnota Akce

URL v example.com Allow
V Akce pro nedůvěryhodný certifikát, vyberte Pass through.
Vyberte Vytvořit zásadu.

Selektor	Operátor	Hodnota	Akce
URL	v	`example.com`	Allow

Zásada Pass Through obejde upgrady na nezabezpečené připojení u libovolného zařízení připojeného k vaší organizaci Zero Trust. Další informace najdete v Nedůvěryhodné certifikáty.

Chcete-li zakázat automatické přechody na HTTPS pro jednotlivé prohlížeče, přejděte do Chrome flags a vypněte HTTPS Upgrades.

Uživatelé Chrome Enterprise mohou vypnout automatické přesměrování na HTTPS pro všechny adresy URL pomocí HttpsUpgradesEnabled zásadu správy ↗.

Mutual TLS (mTLS)

V mutual TLS (mTLS) si klient i server navzájem ověřují identitu pomocí certifikátů. Když Gateway dešifruje provoz TLS, ukončí spojení od klienta a vytvoří nové spojení k origin serveru. Protože Gateway nemůže certifikát klienta předat origin serveru, handshake mTLS selže. Aby nedocházelo k selhání spojení, vytvořte zásada Do Not Inspect pro tento provoz.

ESNI and ECH

Weby, které dodržují Standardy ESNI nebo Encrypted Client Hello (ECH) ↗ šifrují Server Name Indication (SNI) během TLS handshake, a proto nejsou kompatibilní s HTTP inspekcí. Gateway totiž používá SNI k tomu, aby přiřadila HTTP požadavek ke správné zásadě: pokud je SNI zašifrováno, Gateway nedokáže určit, kterou zásadu použít. Když ECH selže, prohlížeče zopakují TLS handshake s nezašifrovaným SNI z původního požadavku. Tomuto chování se lze vyhnout vypnutím ECH v prohlížečích uživatelů.

Stále můžete použít všechny filtry síťových zásad kromě SNI a SNI Domain. Chcete-li omezit provoz ESNI a ECH, můžete filtrovat veškerý port 80 a 443 provoz, který neobsahuje hlavičku SNI.

Postkvantová podpora

Gateway podporuje postkvantovou kryptografii pomocí hybridní výměny klíčů X25519 a MLKEM768 přes TLS 1.3. Po dokončení výměny klíčů Gateway šifruje provoz pomocí AES-128-GCM.

Viz Postkvantová kryptografie a zjistěte více.

Soulad s FIPS

Dešifrování TLS ve výchozím nastavení může používat verzi TLS 1.2 i 1.3. Některá prostředí, například FedRAMP, ale mohou vyžadovat sady šifer a verze TLS odpovídající standardu FIPS 140-3. Soulad s FIPS aktuálně vyžaduje verzi TLS 1.2.

Povolení shody s FIPS

V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady provozu > Nastavení provozu.
V Proxy a kontrola, zapněte Kontrolujte HTTPS požadavky pomocí dešifrování TLS.

Přidejte následující oprávnění do svého cloudflare_api_token ↗:
- Zero Trust Write

Nakonfigurujte tls_decrypt argument v cloudflare_zero_trust_gateway_settings ↗:

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

Vyberte Povolte pouze sady šifer a verze TLS splňující normu FIPS 140-3.

Omezení

Když je zapnutá shoda s FIPS, Gateway vybere pouze Sady šifer kompatibilní s FIPS při připojování k originu. Pokud origin nepodporuje šifry vyhovující standardu FIPS, požadavek selže.

Provoz kompatibilní s FIPS standardně používá HTTP/3. Chcete-li vynutit zásady HTTP pro provoz UDP, musíte zapnout Proxy Gateway pro UDP.

Soulad s FedRAMP

Když používáte Cloudflare Regional Services ve Spojených státech a Cloudflare One Client za účelem on-ramp TLS provozu do Gateway, bude provoz odcházet z datacentra Cloudflare v rámci hranice FedRAMP společnosti Cloudflare. Pokud nejbližší datacentrum uživatele nesplňuje FedRAMP, provoz bude přesto odcházet z datacentra, které splňuje FedRAMP, čímž se zachová soulad s FedRAMP pro tento provoz.

flowchart LR
 %% Accessibility
 accTitle: How Gateway routes FedRAMP compliant traffic with Regional Services
 accDescr: Flowchart describing how the Cloudflare One Client with Gateway routes traffic to egress from a FedRAMP compliant data center when used with Regional Services in the United States.

 %% Flowchart
 subgraph s1["Non-FedRAMP data center"]
        n2["WARP TLS encryption terminated"]
  end
 subgraph s2["FedRAMP data center"]
        n3["Gateway TLS encryption (FIPS) terminated"]
  end
 subgraph s3["Private internal network"]
        n5["FedRAMP compliant cloudflared"]
        n6(["Private server"])
  end
    n1(["User near non-FedRAMP compliant data center"]) -- Gateway TLS connection wrapped with WARP TLS (MASQUE) --> n2
    n2 -- Gateway TLS connection --> n3
    n3 <-- FIPS tunnel --> n5
    n5 --> n6

    n5@{ shape: rect}

Šifrovací sady

Sada šifer (cipher suite) je soubor šifrovacích algoritmů pro navázání zabezpečeného komunikačního spojení. V praxi se hojně používá několik sad šifer a klient se serverem se při navazování spojení TLS dohodnou, kterou sadu šifer použijí. Podpora více sad šifer umožňuje kompatibilitu s různými klienty.

Následující tabulka uvádí výchozí šifrovací sady, které Gateway používá pro dešifrování TLS.

Název (OpenSSL)	Název (IANA)	Kompatibilní s 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	❌

Další informace o sadách šifer najdete v Šifrovací sady.