Представляем шлюз Cloudflare OHTTP — расширяем доступ к инфраструктуре Cloudflare, защищающей конфиденциальность02.10.2026 16:00

Сегодня конечные пользователи несут на себе слишком большую часть бремени защиты конфиденциальности в интернете. Чтобы избежать сторонних трекеров и таргетированной рекламы, пользователям советуют использовать VPN, отключать файлы cookie или устанавливать блокировщики рекламы. Между тем некоторые разработчики приложений в итоге знают о своих пользователях больше, чем им хотелось бы: обычный обмен данными между клиентом и сервером оставляет след из пользовательских данных, например IP-адрес клиента или его TLS-отпечаток. Такая степень видимости может стать обременительной.

Именно поэтому Cloudflare создает инфраструктуру, которая помогает разработчикам встраивать защиту конфиденциальности в свои приложения. Oblivious HTTP (OHTTP) — это стандарт IETF, призванный позволить серверной части приложения получать HTTP-запросы, не видя IP-адресов пользователей.

Этой осенью мы запускаем шлюз Cloudflare OHTTP Gateway. Клиенты смогут подключить наш новый OHTTP Gateway как платное дополнение к своей зоне и всего за несколько щелчков мышью начать получать трафик OHTTP. Чтобы попасть в список ожидания, заполните нашу форму. Читайте дальше, чтобы узнать подробности.

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

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

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

При использовании существующего ретранслятора Cloudflare OHTTP клиентам необходимо самостоятельно предоставить шлюз, чтобы сохранить разделение доверия.

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

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

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

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

Зачем мы создали Cloudflare OHTTP Gateway

С момента запуска нашего продукта OHTTP Relay мы успели кое-что заметить.

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

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

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

Краткое введение в OHTTP

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

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

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

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

- ipAddress: 192.0.2.33 # the client’s IP address 
- ASN: 7922
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique
- tlsVersion: TLSv1.3
- Country: US
- Region: California # the client's location
- City: Campbell

Если сначала отправить запрос через ретранслятор OHTTP, сервер приложения, получающий запрос, увидит только сведения о ретрансляторе:

- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint 
- ASN: 18 
- tlsCipher: AEAD-AES-128-GCM-SHA256 
- tlsVersion: TLSv1.3 
- Country: US
- Region: Texas  # the relay's location
- City: Austin

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

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

Так создается модель конфиденциальности с «двойной слепой зоной»: ретранслятор видит только идентификаторы клиента, а шлюз и сервер приложения — только содержимое запросов; ни одна сторона не видит и того и другого одновременно.

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

Как мы создали OHTTP Gateway

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

Мы также учли несколько других потребностей пользователей, опираясь на проблемы, с которыми сталкивались клиенты OHTTP Relay при самостоятельной эксплуатации шлюзов OHTTP.

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

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

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

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

В-третьих, шлюзы должны уметь аутентифицировать ретрансляторы. Поскольку шлюз по своей задумке почти ничего не знает о клиенте, отправившем запрос, он полагается на ретранслятор, который аутентифицирует клиентов и ответственно пересылает трафик. Но как убедиться, что отправлять трафик на ваш шлюз могут только надежные ретрансляторы?

Мы спроектировали Gateway так, чтобы Cloudflare Access — продукт Cloudflare для сетевого доступа с нулевым доверием — обрабатывал запросы до их расшифровки. Это позволяет использовать любые стандартные политики Access для аутентификации входящего трафика и защиты Gateway от злоупотреблений. Доступны такие варианты, как взаимный TLS, статические учетные данные службы и пользовательская внешняя логика.

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

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

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

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

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

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

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

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

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

Наконец, когда развертывание OHTTP будет завершено, воспользуйтесь нашим клиентом pvcli для тестирования и отладки.

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

© Cloudflare Blog