Шлюз Cloudflare OHTTP

Расширение портфеля продуктов OHTTP

В архитектуре OHTTP запросы проходят через два независимо управляемых звена: relay и gateway. OHTTP relay слепо перенаправляет зашифрованные запросы, чтобы скрыть идентификаторы клиента от серверов приложений. OHTTP gateway выполняет криптографическую работу — расшифровывает входящие запросы и шифрует ответы, позволяя серверам приложений обрабатывать OHTTP-запросы как обычный HTTP. Разделение доверия между relay и gateway критично: оно гарантирует, что ни один из них не видит одновременно идентификаторы клиента и содержимое запроса.

В 2022 году Cloudflare запустила OHTTP relay, известный как Privacy Gateway. Он позволяет клиентам компании предоставлять более приватные впечатления своим пользователям. Например, Flo Health использует OHTTP для Anonymous Mode своего приложения, а Private Cloud Compute от Apple использует OHTTP для разделения AI-запросов от пользовательских идентичностей. Однако клиенты, уже защищающие свои серверы через Cloudflare, не могут использовать управляемый Cloudflare relay — им нужен OHTTP gateway.

На опыте запуска OHTTP relay Cloudflare убедилась, насколько сложно строить и эксплуатировать безопасный, высокопроизводительный OHTTP gateway в масштабе. Сегодня компания запускает закрытую бета-версию самостоятельного Cloudflare OHTTP Gateway. Одновременно Cloudflare переименовала «Privacy Gateway» в «Cloudflare OHTTP Relay», чтобы лучше различать два продукта.

Теперь клиенты, желающие построить архитектуру OHTTP с необходимым разделением доверия, имеют два варианта:

1. Использовать Cloudflare OHTTP Relay (бывший Privacy Gateway) и запустить свой gateway самостоятельно. Это лучше всего, если серверы приложений размещены вне Cloudflare и есть возможность запустить собственный OHTTP gateway.
2. Использовать новый Cloudflare OHTTP Gateway с relay от третьей стороны. Это лучше всего, если серверы приложений уже за Cloudflare (на CDN или Workers), если приложение принимает OHTTP-запросы от третьей стороны (например, Apple LiveCallerID), или если нужен управляемый gateway для снижения задержки и операционных издержек.

Cloudflare работает над повышением стандартов приватности в Интернете и верит, что такие протоколы, как OHTTP, помогут — если сделать их достаточно простыми в использовании. Всегда было целью компании расширять портфель OHTTP и делать надёжную приватную инфраструктуру доступной более широкой части Интернета.

Почему создали Cloudflare OHTTP Gateway

С момента запуска OHTTP Relay компания заметила несколько тенденций.

Во-первых, растёт спрос разработчиков на доступную, удобную инфраструктуру приватности. Создатели приватных приложений хотят встроить сетевую приватность в свои приложения по умолчанию, но это по-прежнему сложнее, чем должно быть.

Во-вторых, выяснилось, что построить и управлять OHTTP gateway сложно для клиентов. Любая архитектура проксирования добавляет задержку — запросы должны пройти ещё один-два хопа через Интернет. Добавьте к этому затраты на расшифровку запросов и шифрование ответов, и задержка самостоятельного OHTTP решения может быть значительной. Cloudflare хорошо позиционирована для решения этой проблемы: те же технологические основы, которые позволяют компании управлять быстрой, надёжной приватной инфраструктурой для продуктов вроде 1.1.1.1 и iCloud Private Relay, делают OHTTP gateway хорошим домом для этого сервиса. Благодаря подходу anycast Cloudflare OHTTP Gateway будет работать на каждом сервере глобальной сети Cloudflare, минимизируя задержку в relay-to-gateway хопах. Если используется CDN Cloudflare, пользовательские запросы могут быть расшифрованы Gateway и обработаны серверами приложений на том же оборудовании Cloudflare, экономя задержку gateway-to-origin.

Наконец, напомним, что модель приватности OHTTP требует, чтобы relay и сервер приложений управлялись отдельными, неколлудирующими сторонами. Компания хочет предоставить клиентам лучший возможный набор вариантов для приватной инфраструктуры. Ранее разработчики, защищавшие серверы приложений через Cloudflare, не могли использовать OHTTP Relay компании, потому что Cloudflare видела бы и метаданные клиента, и расшифрованное содержимое запросов, нарушая модель приватности OHTTP. Теперь разработчики могут выбрать, подходит ли им Cloudflare OHTTP Relay или Gateway, в зависимости от архитектуры.

Основы OHTTP

Типичное взаимодействие между клиентом и сервером приложения раскрывает информацию о клиенте. Когда клиент и сервер приложения общаются, сервер узнаёт IP-адрес клиента — каждый пакет помечается исходящим IP-адресом, как на письме помечается отправитель. Серверы приложений могут также «отпечатать» клиента на основе атрибутов, таких как поддерживаемые версии TLS или наборы шифров. Эти сигналы позволяют серверам приложений связать множественные запросы с одним пользователем.

Но что, если нужно построить приложение, которое действительно не знает много о своих пользователях? Например, Flo Health хотела создать Anonymous Mode для доступа пользователей к личным данным о здоровье без привязки к возможным идентификаторам.

OHTTP вводит прокси, называемый «relay», который перенаправляет запросы и ответы между клиентом и сервером приложения, чтобы скрыть личность клиента от сервера. Relay видит идентификаторы клиента, как IP-адрес и TLS-отпечаток, но удаляет их перед перенаправлением запросов. Это предотвращает связывание серверами приложений множественных запросов с одним пользователем и означает, что содержимое запроса не может быть связано с IP-адресом пользователя.

Например, обычный обмен клиент-сервер может раскрыть о клиенте следующее:

- ipAddress: 192.0.2.33 # IP-адрес клиента
- ASN: 7922
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # потенциально уникальный
- tlsVersion: TLSv1.3
- Country: US
- Region: California # местоположение клиента
- City: Campbell

Запрос, отправленный сначала через OHTTP relay, раскроет серверу приложения только информацию о relay:

- ipAddress: 128.62.37.13 # IP-адрес и отпечаток relay
- ASN: 18
- tlsCipher: AEAD-AES-128-GCM-SHA256
- tlsVersion: TLSv1.3
- Country: US
- Region: Texas # местоположение relay
- City: Austin

Это означает, что для каждого запроса сервер приложения не узнает местоположение и TLS-отпечаток конечного пользователя. Кроме того, если множество разных пользователей отправляют запросы через relay, сервер приложения не сможет различить, какие запросы идут от кого, что ограничивает его способность отследить активность приложения до одного конечного пользователя. Это создаёт мощную границу приватности.

То, что действительно отличает OHTTP от простого прокси перенаправления, — это шифрование данных между клиентом и сервером приложения. Запросы и ответы инкапсулируются с использованием гибридного криптографического шифрования с открытым ключом (HPKE) таким образом, что только клиент и сервер приложения видят открытый текст, а relay видит только зашифрованные данные. «Gateway» находится между relay и сервером приложения для обработки всей криптографии — расшифровки запросов, шифрования ответов — а сервер приложения обрабатывает только обычный HTTP.

Это создаёт модель приватности с «двойной слепотой»: relay видит только идентификаторы клиента; gateway и сервер приложения видят только содержимое запроса; никто не видит обоих.

Как построили OHTTP Gateway

При разработке OHTTP gateway-as-a-service целью было донести безопасную, высокопроизводительную приватную инфраструктуру до более широкой части Интернета. Производительность и простая интеграция критичны. Поэтому Gateway построен как гибкий сервис, развёрнутый по глобальной сети. Всего за пару кликов можно включить Gateway на своей зоне и начать отправлять OHTTP на https://your-zone.com/.well-known/ohttp-gateway. Сервис автоматически масштабируется вверх и вниз, поэтому не нужно беспокоиться о мощности.

У компании было ещё несколько требований, основанных на проблемах, которые клиенты OHTTP Relay встречали при управлении собственными OHTTP gateway.

Первое: максимально абстрактно убрать сложность OHTTP для серверов приложений. Разработчики должны иметь возможность начать получать OHTTP, продолжая принимать обычный HTTP трафик, если захотят. Поэтому Gateway спроектирован как функция зоны, куда клиенты отправляют правильно отформатированные OHTTP-запросы на эндпоинт /.well-known/ohttp-gateway зоны. Поддерживаются как стандартный, так и чанкированный OHTTP — рекомендуется использовать чанкированный OHTTP для лучшей производительности, потому что он позволяет обрабатывать запросы постепенно («чанками»).

Сервис Gateway перехватит каждый запрос, расшифрует его, выпустит подзапрос к серверу приложения и вернёт зашифрованный ответ клиенту. Все не-OHTTP запросы пойдут к серверу без использования Gateway.

Привязка Gateway к зоне также позволяет защитить Gateway от злоупотреблений. Клиент, отправляющий запросы на зону example.com, может отправлять на foo.example.com или bar.example.com, но не на wikipedia.com. Без необходимости что-либо делать, это предотвращает использование зоны несанкционированными клиентами в качестве способа атаковать другие домены.

Второе: управление ключами без трений критично. Gateway должны хранить конфигурацию публичного HPKE ключа для клиентов, но управление ключами безопасно — вызов. Поэтому Gateway спроектирован для полного управления всеми ключами клиентов и предоставления публичных ключей в ответах на GET-запросы на /.well-known/ohttp-gateway. Для усиленной приватности клиенты могут скачивать ключи с другого IP, чем запрашивают gateway.

Третье: gateway должны иметь возможность аутентифицировать relay. Потому что Gateway (по проекту) знает мало о клиенте, отправляющем данный запрос, он доверяет relay аутентифицировать клиентов и ответственно перенаправлять трафик. Но как гарантировать, что только доверенные relay могут отправлять трафик на gateway?

Gateway спроектирован таким образом, что Cloudflare Access (продукт zero trust сетевого доступа Cloudflare) запускается перед расшифровкой запросов, позволяя использовать любые стандартные политики Access для аутентификации входящего трафика и защиты Gateway от злоупотреблений. Опции включают взаимный TLS, статические учётные данные сервиса и пользовательскую внешнюю логику.

Наконец: ошибки случаются, и компания предусмотрела, что клиенты случайно могут нарушить модель приватности OHTTP, запустив как relay, так и gateway на Cloudflare. Чтобы сохранить разделение доверия OHTTP и гарантировать, что Cloudflare никогда не видит одновременно клиентские идентичности и расшифрованные внутренние запросы, Gateway откажется расшифровывать запросы, отправленные с Cloudflare Workers или проксированных хостов на Cloudflare.

Когда OHTTP Gateway лучше, чем OHTTP Relay?

Если нужно использовать портфель OHTTP продуктов Cloudflare, но не уверены, почему выбрать OHTTP Gateway вместо OHTTP Relay, вот несколько соображений.

Первое: нужны ли серверы приложений на Cloudflare — за CDN или построены на Workers? Если да, то OHTTP Gateway лучше подходит для соблюдения модели приватности OHTTP.

Второе: какой сценарий использования? Если нужно получать OHTTP-запросы от клиента третьей стороны и relay — например, для использования SDK Apple LiveCallerID — то OHTTP Gateway скорее всего лучшее решение.

Начало работы

Если есть пожелание по функциям или нужна регистрация в списке ожидания для уведомления о запуске продукта, зарегистрируйтесь здесь.

Затем нужно реализовать OHTTP-клиент. Посмотрите ohttp.info или библиотеку примеров клиента Cloudflare для помощи в начале работы. Один момент при разработке клиента: OHTTP обеспечивает приватность на сетевом уровне и не касается тела внутреннего запроса. Поэтому, чтобы сохранить приватность пользователя, нужно не отправлять информацию идентификации (например, адрес электронной почты или имя пользователя) в теле запроса.

Дальше нужен свой relay. Relay могут работать на любом поставщике инфраструктуры, и они просты: вот примеры кода. Вызов, и причина, по которой может потребоваться поставщик выделенного OHTTP relay, — верифицируемо обещать пользователям, что логи с идентификаторами клиента не будут проверяться. Иначе можно было бы коррелировать клиентов на relay с расшифрованными запросами на серверах приложений.

Наконец, когда развёртывание OHTTP живое, посмотрите pvcli клиент Cloudflare для помощи в тестировании и отладке.

Cloudflare рада предоставить доступную приватную инфраструктуру разработчикам везде. Свяжитесь с компанией, если хотите опробовать новый OHTTP Gateway и повысить стандарты приватности в Интернете.