ИИтог

Cloudflare запустила закрытую бету OHTTP Gateway для приватных запросов

инфраструктураРедакция ИИтогHacker News🔥49Рейтинг ИИтог49Влияние45Новизна38Релевантность68Неожиданность25Участники70Достоверность88
Cloudflare запустила закрытую бету OHTTP Gateway для приватных запросов

Cloudflare объявила о Cloudflare OHTTP Gateway, управляемом шлюзе для Oblivious HTTP (OHTTP), стандарта IETF, который позволяет бэкенду приложения принимать HTTP-запросы, не видя IP-адреса пользователей. Сейчас запущена закрытая бета с листом ожидания (запись через форму). Компания обещает, что осенью клиенты смогут включать шлюз как платное дополнение к своей зоне и начинать получать OHTTP-трафик в несколько кликов. Цена в тексте не названа.

В OHTTP запрос проходит через два независимо управляемых звена: ретранслятор (relay) и шлюз (gateway). Ретранслятор вслепую пересылает зашифрованные запросы и скрывает идентификаторы клиента от серверов приложения. Шлюз выполняет криптографическую работу, расшифровывает запросы и шифрует ответы, чтобы сервер приложения обрабатывал их как обычный HTTP. Разделение доверия между ними критично: ни одна сторона не должна видеть одновременно идентификаторы клиента и содержимое запроса. Данные шифруются по схеме Hybrid Public Key Encryption (HPKE), так что открытый текст видят только клиент и сервер приложения, а ретранслятор, лишь шифротекст. Получается «двойная слепота»: ретранслятор знает, кто пишет, шлюз и сервер знают, что написано, и никто не знает и того и другого.

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

Выбор для клиентов такой. Первый вариант: Cloudflare OHTTP Relay плюс собственный шлюз, подходит, если серверы приложения размещены не на Cloudflare. Второй вариант: новый OHTTP Gateway со сторонним ретранслятором, подходит, если серверы уже за Cloudflare (на CDN или Workers), если запросы OHTTP приходят от третьей стороны (в пример приведён LiveCallerID от Apple) или если нужен управляемый шлюз с меньшими задержками и эксплуатационной нагрузкой.

Как устроен шлюз. Он работает на каждом сервере глобальной сети Cloudflare (благодаря anycast-маршрутизации), что, по заявлению компании, минимизирует задержку на участке ретранслятор, шлюз; при использовании CDN запрос может быть расшифрован и обработан на тех же площадках Cloudflare, что экономит задержку на участке шлюз, origin. Шлюз включается как функция зоны: клиенты отправляют корректно оформленные OHTTP-запросы на адрес /.well-known/ohttp-gateway в зоне клиента, обычный HTTP-трафик идёт на сервер без участия шлюза. Поддерживаются стандартный и «чанкованный» (chunked) OHTTP; Cloudflare рекомендует второй для лучшей производительности, так как он позволяет обрабатывать запросы по частям. Ключи HPKE шлюз ведёт полностью сам, а публичные ключи отдаёт в ответ на GET-запросы по тому же адресу; для большей приватности клиенты могут скачивать ключи с другого IP, чем тот, с которого шлют запросы.

Для защиты от злоупотреблений шлюз привязан к зоне: клиент может слать запросы на foo.example.com или bar.example.com, но не на wikipedia.com. Аутентификацию ретрансляторов обеспечивает Cloudflare Access, который срабатывает до расшифровки запросов: подходят стандартные политики, взаимный TLS, статические служебные учётные данные, внешняя логика. Наконец, чтобы клиент случайно не сломал модель приватности, запустив и ретранслятор, и шлюз на Cloudflare, шлюз откажется расшифровывать запросы, пришедшие из Cloudflare Workers или с проксируемых хостов Cloudflare.

Ключевые факты

  • Cloudflare запустила закрытую бету OHTTP Gateway с листом ожидания; осенью шлюз появится как платное дополнение к зоне, цена в тексте не названа.
  • OHTTP, стандарт IETF: запрос идёт через два независимых звена, ретранслятор и шлюз, и ни одно не видит одновременно IP клиента и содержимое запроса.
  • Шлюз нужен тем, чьи серверы уже за Cloudflare: ретранслятор Cloudflare им не подходил, иначе компания увидела бы и метаданные, и содержимое.
  • Прежний продукт 2022 года Privacy Gateway переименован в Cloudflare OHTTP Relay; в качестве примеров OHTTP названы Flo Health и Private Cloud Compute от Apple.
  • Шлюз сам управляет ключами HPKE, проверяет ретрансляторы через Cloudflare Access и отказывается расшифровывать запросы из Workers и с проксируемых хостов Cloudflare.

Почему это важно

Cloudflare закрывает пробел в наборе инструментов для приватных приложений. Раньше у компании был только ретранслятор (Privacy Gateway, 2022), а те, кто уже защищает серверы через Cloudflare, не могли им пользоваться без нарушения модели приватности OHTTP. Теперь есть управляемый шлюз, который можно связать со сторонним ретранслятором. Отдельный интерес для сферы ИИ: в тексте упомянуто, что Private Cloud Compute от Apple использует OHTTP, чтобы отвязать запросы ИИ-инференса от личности пользователей. Сам анонс при этом касается сетевой инфраструктуры, а не моделей.

Кому это важно

Разработчикам приватных приложений, чьи серверы уже стоят за Cloudflare (на CDN или Workers). Тем, кто принимает OHTTP-запросы от третьей стороны, как в примере с LiveCallerID от Apple. Командам, которые не хотят сами строить и эксплуатировать шлюз OHTTP: Cloudflare пишет, что делать это безопасно и быстро в масштабе непросто. Тем, кто выбирает между ретранслятором и шлюзом, текст даёт два прямых сценария.

Как это применить

Сейчас доступна только запись в лист ожидания закрытой беты через форму Cloudflare. По заявлению компании, шлюз включается на зоне в несколько кликов и принимает OHTTP по адресу /.well-known/ohttp-gateway вашей зоны. Клиенты шлют корректные OHTTP-запросы, остальной HTTP-трафик идёт на сервер как раньше. Рекомендован chunked OHTTP для лучшей производительности. Доступ ретрансляторов настраивается стандартными политиками Cloudflare Access (взаимный TLS, статические учётные данные, внешняя логика). Если серверы размещены не на Cloudflare и вы можете запустить собственный шлюз, подходит OHTTP Relay (прежний Privacy Gateway) плюс свой шлюз. Стоимость дополнения в видимом тексте не указана.

Можно ли доверять

Это анонс самой Cloudflare в её блоге, то есть описание продукта глазами разработчика, а не независимая оценка. Видимая часть текста технически конкретна, но не содержит замеров задержки или бенчмарков: утверждения о минимизации задержки, заявления компании. Автор в видимом тексте не назван. Текст источника обрывается на середине раздела о том, когда шлюз лучше ретранслятора, поэтому концовка не учтена. Flo Health и Apple названы как пользователи OHTTP в рамках прежнего продукта-ретранслятора; ни один клиент нового шлюза не назван.

Риски и подводные камни

Продукт пока в закрытой бете, общий запуск обозначен лишь как «этой осенью» без точной даты, цена не названа. Сам OHTTP добавляет один-два лишних участка в пути запроса, и Cloudflare признаёт, что любая прокси-архитектура вносит задержку, а расшифровка и шифрование добавляют стоимость. Модель приватности требует, чтобы ретранслятор и сервер приложения управлялись раздельными, не сговаривающимися сторонами: шлюз откажется расшифровывать запросы из Cloudflare Workers и с проксируемых хостов Cloudflare, так что ретранслятор придётся брать вне Cloudflare. Шлюз по замыслу почти ничего не знает о клиенте и доверяет ретранслятору в аутентификации клиентов, поэтому доступ ретрансляторов нужно настраивать аккуратно.