Сегодня на конечных пользователей ложится слишком большая нагрузка в вопросах обеспечения конфиденциальности в Интернете. Чтобы избежать стороннего отслеживания или таргетированной рекламы, пользователям приходится использовать VPN, отключать файлы cookie или устанавливать блокировщики рекламы. В то же время некоторые разработчики приложений в итоге узнают о своих пользователях больше, чем им хотелось бы: типичный обмен данными между клиентом и сервером создает след из пользовательских данных, таких как IP-адрес клиента или TLS-отпечаток. Такой уровень прозрачности может стать обузой.
Именно поэтому Cloudflare создает инфраструктуру, которая помогает разработчикам встраивать конфиденциальность в свои приложения. Oblivious HTTP (OHTTP) — это стандарт IETF, разработанный для того, чтобы бэкенды приложений могли получать HTTP-запросы, не видя IP-адресов пользователей.
Этой осенью мы запускаем Cloudflare OHTTP Gateway. Клиенты смогут подключить наш новый OHTTP Gateway в качестве платного дополнения к своей зоне и начать получать OHTTP-трафик всего за несколько кликов. Зарегистрируйтесь через нашу форму, чтобы попасть в список ожидания. Читайте дальше, чтобы узнать больше.
Расширение нашего набора продуктов OHTTP
При использовании OHTTP запросы проходят через два независимо управляемых узла: ретранслятор (relay) и шлюз (gateway). OHTTP-ретранслятор «вслепую» пересылает зашифрованные запросы, чтобы скрыть идентификаторы клиента от серверов приложений. OHTTP-шлюз выполняет криптографическую работу по декапсуляции зашифрованных запросов и инкапсуляции ответов таким образом, чтобы серверы приложений могли обрабатывать OHTTP-запросы так, как если бы это был обычный HTTP. Разделение доверия между ретранслятором и шлюзом имеет решающее значение: оно гарантирует, что ни одна из сторон не увидит одновременно и идентификаторы клиента, и содержимое запроса.
В 2022 году мы запустили продукт OHTTP-ретранслятора — Privacy Gateway. Privacy Gateway позволяет нашим клиентам предоставлять своим пользователям более конфиденциальные возможности. Например, Flo Health использует OHTTP для анонимного режима своего приложения, а Private Cloud Compute от Apple использует OHTTP, чтобы отделить запросы к ИИ от личности пользователей. Однако клиенты, которые уже защищают свои серверы с помощью Cloudflare, не могут использовать ретранслятор под управлением Cloudflare — им вместо этого нужен OHTTP-шлюз.
Основываясь на нашем опыте эксплуатации OHTTP-ретрансляторов, мы поняли, насколько сложно создать и поддерживать безопасный и производительный OHTTP-шлюз в масштабе. Сегодня мы запускаем закрытое бета-тестирование нашего самообслуживаемого Cloudflare OHTTP Gateway. Мы также переименовываем наш «Privacy Gateway» в «Cloudflare OHTTP Relay», чтобы лучше различать эти два продукта.
Теперь у клиентов, которым нужна архитектура OHTTP с необходимым разделением доверия, есть два варианта:
- Использовать OHTTP Relay от Cloudflare (ранее Cloudflare Privacy Gateway) и самостоятельно управлять своим шлюзом. Это лучший вариант, если серверы вашего приложения размещены вне Cloudflare и вы можете самостоятельно запустить свой OHTTP-шлюз.
- Использовать новый OHTTP Gateway от Cloudflare со сторонним ретранслятором. Это лучший вариант, если серверы вашего приложения уже находятся за Cloudflare (например, в нашей CDN или Workers), если вы принимаете OHTTP-запросы от третьей стороны (например, Apple LiveCallerID) или если вам нужен управляемый шлюз для минимизации задержек и эксплуатационных расходов.
Мы работаем над тем, чтобы повысить планку конфиденциальности во всем Интернете, и верим, что такие протоколы, как 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. Теперь разработчики могут выбирать, что лучше подходит для их архитектуры: OHTTP Relay или Gateway от Cloudflare.
Краткий обзор OHTTP
Типичное взаимодействие между клиентом и сервером приложения раскрывает информацию о клиенте. Когда клиент и сервер приложения общаются друг с другом, сервер приложения узнает IP-адрес клиента, поскольку каждый пакет, в котором отправляются данные, помечен исходным IP-адресом — подобно метке «от кого» на конверте. Серверы приложений также могут создавать «отпечаток» клиента на основе таких атрибутов, как поддерживаемые версии TLS или наборы шифров. Эти сигналы позволяют серверам приложений связывать несколько запросов с одним и тем же пользователем.
Но что, если я хочу создать приложение, которое действительно не знает многого о моих пользователях? Например: Flo Health хотела создать анонимный режим, чтобы позволить пользователям получать доступ к личным медицинским данным, не связывая их с возможными идентификаторами пользователей.
OHTTP вводит прокси-сервер, называемый «ретранслятором», который пересылает запросы и ответы между клиентом и сервером приложения, чтобы скрыть личность клиента от сервера приложения. Ретранслятор видит идентификаторы клиента, такие как IP-адрес и TLS-отпечаток, но удаляет их перед пересылкой запросов. Это предотвращает связывание серверами приложений нескольких запросов с одним и тем же пользователем и означает, что содержимое запроса не может быть связано с IP-адресом пользователя.
Например, обычный обмен данными между клиентом и сервером может раскрыть следующую информацию о клиенте:
Запрос, впервые отправленный через OHTTP-ретранслятор, раскроет серверу приложения, получающему запрос, только информацию о ретрансляторе:
Это означает, что для каждого запроса сервер приложений не узнает местоположение и TLS-отпечаток конечного пользователя. Кроме того, если множество разных пользователей отправляют запросы через ретранслятор, сервер приложений не сможет определить, от кого исходят запросы, что ограничивает его возможность отследить активность приложения до конкретного конечного пользователя. Это создает надежный барьер конфиденциальности.
Однако то, что действительно отличает OHTTP от базового прокси-сервера пересылки, — это шифрование данных между клиентом и сервером приложений. Запросы и ответы инкапсулируются с использованием гибридного шифрования с открытым ключом (HPKE), так что только клиент и сервер приложений могут видеть открытый текст, а ретранслятор видит только набор зашифрованных данных. Между ретранслятором и сервером приложений находится «шлюз», который берет на себя всю эту криптографию — декапсуляцию запросов и инкапсуляцию ответов, — а сервер приложений работает только с обычным HTTP.
Это создает модель конфиденциальности «двойного слепого метода»: ретранслятор видит только идентификаторы клиента; шлюз и сервер приложений видят только содержимое запроса; никто из участников не видит и то, и другое одновременно.
Как мы создали шлюз OHTTP
Создавая наш сервис «шлюз OHTTP как услуга», мы стремились предоставить нашу безопасную и производительную инфраструктуру конфиденциальности более широкому кругу пользователей Интернета. Производительность и простота подключения имеют решающее значение. Поэтому мы создали наш шлюз как гибкий сервис, развернутый в нашей глобальной сети. Всего за пару кликов вы можете активировать шлюз в своей зоне и начать отправлять OHTTP-запросы на https://your-zone.com/.well-known/ohttp-gateway. Мы будем автоматически масштабировать сервис, поэтому вам не нужно беспокоиться о пропускной способности.
Мы учли и другие потребности пользователей, основываясь на проблемах, с которыми сталкивались клиенты OHTTP Relay при эксплуатации собственных шлюзов OHTTP.
Во-первых, мы хотели максимально абстрагироваться от сложности OHTTP для ваших серверов приложений. Мы хотели, чтобы разработчики могли начать получать OHTTP, продолжая при необходимости принимать обычный HTTP-трафик. Поэтому мы разработали шлюз как функцию вашей зоны, где клиенты отправляют well-formatted OHTTP-запросы на конечную точку /.well-known/ohttp-gateway в вашей зоне. Мы поддерживаем как стандартный, так и фрагментированный OHTTP — и рекомендуем использовать фрагментированный OHTTP для повышения производительности, поскольку он позволяет нам обрабатывать запросы пошагово (по «фрагментам»).
Наш сервис шлюза будет перехватывать каждый запрос, расшифровывать его, отправлять подзапрос на ваш сервер приложений и возвращать зашифрованный ответ клиенту. Все запросы, не относящиеся к OHTTP, будут направляться на ваш сервер без участия шлюза.
Привязка шлюза к вашей зоне также позволяет нам защитить его от злоупотреблений. Клиент, отправляющий запросы в вашу зону `example.com`, может отправлять их на `foo.example.com` или `bar.example.com`, но не на wikipedia.com. Вам не нужно беспокоиться об этом, так как это предотвращает использование вашей зоны неавторизованными клиентами для атак на другие домены.
Во-вторых, критически важно бесшовное управление ключами. Шлюзам необходимо поддерживать конфигурацию открытых ключей HPKE, чтобы клиенты могли шифровать запросы, но безопасное управление ключами — сложная задача. Поэтому мы разработали шлюз так, чтобы он полностью управлял всеми ключами для клиентов и предоставлял открытые ключи в ответ на GET-запросы к /.well-known/ohttp-gateway. Для обеспечения более высокого уровня конфиденциальности клиенты могут загружать ключи через IP-адрес, отличный от того, на который они отправляют запросы к шлюзу.
В-третьих, шлюзы должны иметь возможность аутентифицировать ретрансляторы. Поскольку шлюз (по своей архитектуре) знает очень мало о клиенте, отправляющем конкретный запрос, он доверяет ретранслятору аутентификацию клиентов и ответственную пересылку трафика. Но как гарантировать, что только доверенные ретрансляторы могут отправлять трафик на ваш шлюз?
Мы спроектировали шлюз так, что Cloudflare Access, продукт Cloudflare для обеспечения сетевого доступа с нулевым доверием, запускается до расшифровки запросов, что позволяет вам использовать любые стандартные правила Access policies для аутентификации входящего трафика и защиты шлюза от злоупотреблений. Доступные варианты включают взаимный TLS, статические учетные данные службы и пользовательскую внешнюю логику.
Наконец, ошибки случаются, и мы предвидели, что клиенты могут случайно нарушить модель конфиденциальности OHTTP, запустив и ретранслятор, и шлюз на Cloudflare. Поэтому, чтобы сохранить разделение доверия в OHTTP и гарантировать, что Cloudflare никогда не увидит одновременно идентификаторы клиентов и расшифрованные внутренние запросы, наш шлюз будет отказываться расшифровывать запросы, отправленные из Cloudflare Workers или с проксируемых хостов в Cloudflare.
Когда шлюз OHTTP лучше подходит, чем ретранслятор OHTTP?
Если вы хотите использовать набор продуктов OHTTP от Cloudflare, но задаетесь вопросом, почему стоит выбрать шлюз OHTTP от Cloudflare, а не ретранслятор OHTTP, вот несколько соображений.
Во-первых, хотите ли вы, чтобы ваши серверы приложений находились в Cloudflare — например, за нашей CDN или на базе Workers? Если да, то шлюз OHTTP лучше подходит для обеспечения соблюдения модели конфиденциальности OHTTP.
Во-вторых, каков ваш сценарий использования? Если вы хотите получать OHTTP-запросы от стороннего клиента и ретранслятора — например, для использования SDK от Apple, — то шлюз OHTTP, скорее всего, будет для вас лучшим решением.
Начало работы
Если у вас есть запрос на добавление функции или вы хотите зарегистрироваться в нашем списке ожидания, чтобы мы могли уведомить вас о запуске продукта, зарегистрируйтесь здесь.
Затем вам нужно будет реализовать OHTTP-клиент. См. ohttp.info или нашу библиотеку примеров клиента для получения примеров, которые помогут вам начать. Один важный момент при создании клиента: OHTTP обеспечивает конфиденциальность на сетевом уровне и не затрагивает тело внутреннего запроса. Поэтому, чтобы сохранить конфиденциальность пользователей, вы сами должны не отправлять идентифицирующую информацию (например, адрес электронной почты или имя пользователя) в теле запроса.
Далее вам нужно будет использовать свой собственный ретранслятор. Ретрансляторы могут работать на инфраструктуре любого провайдера, и они просты: вот несколько примеров кода. Сложность, из-за которой вам может понадобиться специализированный провайдер ретрансляторов OHTTP, заключается в необходимости подтверждаемо обещать пользователям, что вы не будете просматривать журналы с идентификаторами клиентов. В противном случае вы могли бы сопоставить клиентов на ретрансляторе с расшифрованными запросами на ваших серверах приложений.
Наконец, когда ваше развертывание OHTTP заработает, ознакомьтесь с нашим
чтобы помочь с тестированием и отладкой.
Мы рады предоставить доступную инфраструктуру конфиденциальности разработчикам по всему миру.
если вы хотите попробовать новый шлюз OHTTP и повысить стандарты конфиденциальности в Интернете.
