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

Расшифровка TLS

Cloudflare Gateway может выполнять Расшифровка SSL/TLS ↗ чтобы проверять трафик HTTPS на наличие вредоносного ПО и других угроз безопасности. Для проверки трафика HTTPS политиками HTTP требуется расшифровка TLS. Без неё информация, содержащаяся в шифровании HTTPS, такая как полный URL-адрес, заголовки и тело запроса, не будет виден Gateway.

Если вы включите расшифровку TLS, Gateway расшифровывает весь трафик, отправленный по HTTPS, применяет ваши HTTP-политики, а затем повторно шифрует запрос с помощью сертификат на стороне пользователя.

Cloudflare предотвращает вмешательство в трафик, расшифровывая, проверяя и повторно шифруя запросы HTTPS в своих дата-центрах только в оперативной памяти. Gateway сохраняет в кэше на диске лишь допустимое к этому содержимое. Все диски кэша зашифрованы в состоянии покоя. Место расшифровки TLS можно настроить с помощью Regional Services в Cloudflare Data Localization Suite (DLS). Чтобы дополнительно контролировать, из каких дата-центров исходит трафик, вы можете использовать выделенные исходящие IP-адреса.

Cloudflare поддерживает подключения пользователей к Gateway по TLS 1.1, 1.2 и 1.3.

Включите расшифровку TLS

Чтобы включить расшифровку TLS:

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Настройки трафика.
В Прокси и проверка, включите Проверяйте HTTPS-запросы с расшифровкой TLS.

Добавьте следующее разрешение в свой cloudflare_api_token ↗:
- Zero Trust Write

Настройте tls_decrypt аргумент в cloudflare_zero_trust_gateway_settings ↗:

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

Ограничения проверки

Gateway не поддерживает расшифровку TLS для приложений, использующих:

Закрепление сертификата
Самоподписанные сертификаты
Аутентификация с использованием взаимного TLS (mTLS)
Шифрование рукопожатия ESNI и ECH
Автоматическое обновление до HTTPS

Проверка на всех портах

По умолчанию Gateway проверяет HTTP-трафик только через порт 80. Кроме того, если вы включить расшифровку TLS, Gateway будет проверять HTTPS-трафик через порт 443.

Чтобы обнаруживать и проверять трафик HTTP и HTTPS на портах, помимо 80 и 443, вы можете включить определение протокола и настройте Gateway так, чтобы проверять трафик на всех портах.

Несовместимые сертификаты

Приложения, использующие certificate pinning и аутентификацию mTLS, не доверяют сертификатам Cloudflare. Например, большинство мобильных приложений используют закрепление сертификата. Cloudflare не доверяет приложениям, использующим самоподписанные сертификаты вместо сертификатов, подписанных публичным CA.

Если вы попытаетесь выполнить расшифровку TLS для приложения с несовместимой конфигурацией сертификата, приложение может вернуть ошибку SSL или доверия и (или) не загрузиться. Чтобы устранить эту проблему, можно сделать следующее:

Добавьте сертификат Cloudflare к поддерживаемым приложениям.
Создайте Политика Do Not Inspect чтобы освободить приложения от проверки. Селектор приложения предоставляет список доверенных приложений, которые, как известно, используют встроенные сертификаты. Обратите внимание, что при создании политики Do Not Inspect для приложения или веб-сайта вы теряете возможность логировать или блокировать HTTP-запросы, применять политики DLP и выполнять антивирусное сканирование.
Настройте Split Tunnel в режиме Include, чтобы Gateway проверял только трафик, направленный на ваши IP-адреса или домены. Это полезно организациям, которые развёртывают Zero Trust на личных устройствах пользователей или иначе рассчитывают на использование личных приложений.

Как вариант, чтобы разрешить фильтрацию HTTP при обращении к сайту с недействительным сертификатом, задайте Действие в отношении недоверенного сертификата к Pass through.

Автоматическое обновление до HTTPS в Google Chrome

Google Chrome может автоматически обновлять HTTP-запросы до HTTPS-запросов, даже если вы переходите по ссылке, которая явно указывает http://. Если вы используете Gateway для проксирования и фильтрации трафика, это обновление может прервать соединение между вашими пользователями Zero Trust и Gateway.

Автоматическое обновление до HTTPS можно отключить с помощью политики Gateway pass through, флага браузера Chrome или политики Chrome Enterprise.

Чтобы отключить автоматическое обновление HTTPS для URL-адреса во всей организации Zero Trust, создайте политику Gateway Pass Through.

Разверните пользовательский корневой сертификат.
Создайте Политика HTTP чтобы соответствовать домену URL-адреса, для которого выполняется автоматическое обновление. Например:

Селектор Оператор Значение Действие

URL in example.com Allow
В Действие в отношении недоверенного сертификата, выберите Pass through.
Выберите Создать политику.

Селектор	Оператор	Значение	Действие
URL	in	`example.com`	Allow

Политика Pass Through пропускает небезопасные обновления соединения для любого устройства, подключённого к вашей организации Zero Trust. Дополнительные сведения см. в Недоверенные сертификаты.

Чтобы отключить автоматическое обновление HTTPS для отдельных браузеров, перейдите в Флаги Chrome и отключите Переход на HTTPS.

Пользователи Chrome Enterprise могут отключить автоматическое обновление до HTTPS для всех URL-адресов с помощью HttpsUpgradesEnabled политика управления ↗.

Взаимный TLS (mTLS)

При взаимной аутентификации TLS (mTLS) клиент и сервер предъявляют друг другу сертификаты для проверки подлинности. Когда Gateway расшифровывает TLS-трафик, он разрывает соединение с клиентом и устанавливает новое соединение с исходным сервером. Поскольку Gateway не может передать сертификат клиента исходному серверу, согласование mTLS завершается ошибкой. Чтобы избежать сбоев соединения, создайте Политика Do Not Inspect для этого трафика.

ESNI и ECH

Веб-сайты, соответствующие требованиям Стандарты ESNI или Encrypted Client Hello (ECH) ↗ шифруют индикацию имени сервера (SNI) во время рукопожатия TLS и поэтому несовместимы с проверкой HTTP. Gateway использует SNI для сопоставления HTTP-запроса с политикой: если SNI зашифрован, Gateway не может определить, какую политику применять. Если ECH завершается ошибкой, браузеры повторяют рукопожатие TLS с использованием незашифрованного SNI из исходного запроса. Чтобы избежать такого поведения, можно отключить ECH в браузерах пользователей.

Вы по-прежнему можете применить все фильтры политики Network кроме SNI и SNI Domain. Чтобы ограничить трафик ESNI и ECH, можно отфильтровать весь трафик на порту 80 и 443 трафик, который не содержит заголовка SNI.

Постквантовая поддержка

Gateway поддерживает постквантовую криптографию с гибридным обменом ключами по алгоритмам X25519 и MLKEM768 через TLS 1.3. После завершения обмена ключами Gateway использует AES-128-GCM для шифрования трафика.

См. Постквантовая криптография чтобы узнать больше.

Соответствие FIPS

По умолчанию для расшифровки TLS могут использоваться как TLS версии 1.2, так и версии 1.3. Однако в некоторых средах, например FedRAMP, могут требоваться наборы шифров и версии TLS, соответствующие FIPS 140-3. Соответствие FIPS в настоящее время требует версии TLS 1.2.

Включите соответствие FIPS

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Настройки трафика.
В Прокси и проверка, включите Проверяйте HTTPS-запросы с расшифровкой TLS.

Добавьте следующее разрешение в свой cloudflare_api_token ↗:
- Zero Trust Write

Настройте tls_decrypt аргумент в cloudflare_zero_trust_gateway_settings ↗:

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

Выберите Включить только наборы шифров и версии TLS, совместимые с FIPS 140-3.

Ограничения

Когда включено соответствие FIPS, Gateway выбирает только Наборы шифров с поддержкой FIPS при подключении к источнику (origin). Если источник не поддерживает FIPS-совместимые шифры, запрос завершится ошибкой.

Трафик с поддержкой FIPS по умолчанию использует HTTP/3. Чтобы применять политики HTTP к трафику UDP, необходимо включить Gateway proxy для UDP.

Соответствие FedRAMP

Если вы используете Cloudflare Regional Services в США и Cloudflare One Client для приёма TLS-трафика в Gateway, трафик будет выходить из дата-центра Cloudflare в пределах периметра FedRAMP компании Cloudflare. Если ближайший к пользователю дата-центр не соответствует FedRAMP, трафик всё равно будет выходить из дата-центра, соответствующего FedRAMP, сохраняя соответствие FedRAMP для этого трафика.

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}

Наборы шифров

Набор шифров (cipher suite) представляет собой совокупность алгоритмов шифрования для установления защищенного канала связи. Существует несколько широко используемых наборов шифров, и клиент с сервером согласовывают, какой набор шифров использовать при установлении TLS-соединения. Поддержка нескольких наборов шифров обеспечивает совместимость с различными клиентами.

В следующей таблице перечислены наборы шифров по умолчанию, которые Gateway использует для расшифровки TLS.

Название (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	❌

Дополнительные сведения о наборах шифров см. в Наборы шифров.