Современные реалии таковы, что не каждый бизнес может себе позволить сайт, особенно стартующий бизнес. Поэтому выгодно воспользоваться конструктором сайтов, например filandor. Запуск сайта через несколько минут.

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

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

Недавно мы развернули Privacy Gateway для Flo Health Inc., ведущего приложения для женского здоровья, для запуска их анонимного режима. При наличии Privacy Gateway все данные запросов для пользователей анонимного режима шифруются между пользователем приложения и Flo, что не позволяет Flo видеть IP-адреса этих пользователей, а Cloudflare — содержимое этих данных запроса.

При наличии Privacy Gateway возможны несколько других критических для конфиденциальности приложений:

Разработчики браузеров могут собирать телеметрию пользователей с соблюдением конфиденциальности — какие расширения установлены, какие значения по умолчанию пользователь мог изменить — удаляя при этом то, что все еще является потенциально личным идентификатором (IP-адрес) из этих данных.
Пользователи могут посетить сайт здравоохранения, чтобы сообщить о воздействии Covid-19, не беспокоясь о том, что сайт отслеживает их IP-адрес и/или местоположение.
Преобразователи DNS могут обслуживать DNS-запросы, не связывая того, кто сделал запрос, с каким веб-сайтом они посещают — шаблон, который мы внедрили в Oblivious DNS.
Privacy Gateway основан на Oblivious HTTP (OHTTP), развивающемся стандарте IETF, и построен на стандартной гибридной криптографии с открытым ключом.

Как это работает?

Основное нововведение в стандарте Oblivious HTTP, помимо базового прокси-сервиса, заключается в том, что эти сообщения шифруются. на сервер приложениятак что Privacy Gateway ничего не узнает о данных приложения, кроме источника и получателя каждого сообщения.

Privacy Gateway позволяет разработчикам приложений и платформам, особенно тем, которые предъявляют высокие требования к конфиденциальности, создавать что-то, очень похожее на «Mixnet»: подход к сокрытию источника и адресата сообщения в сети. С этой целью Privacy Gateway состоит из трех основных компонентов:

Клиент: устройство пользователя или любой клиент, настроенный на пересылку запросов в Privacy Gateway.
Шлюз конфиденциальности: служба, управляемая Cloudflare и предназначенная для передачи запросов между клиентом и шлюзом без возможности наблюдения за содержимым внутри.
Сервер приложений: веб-сервер источника или приложения, отвечающий за расшифровку запросов от клиентов и обратное шифрование ответов.

Если вы представляете данные запроса как содержимое конверта (письмо), а IP-адрес и метаданные запроса как адрес снаружи, с Privacy Gateway Cloudflare может увидеть адрес конверта и безопасно переслать его по назначению. не имея возможности увидеть, что внутри.

Забывчивая HTTP-транзакция с использованием Privacy Gateway

Более подробно поток данных выглядит следующим образом:

Клиент инкапсулирует HTTP-запрос, используя открытый ключ сервера приложений, и отправляет его в Privacy Gateway через соединение HTTPS.
Privacy Gateway перенаправляет запрос на сервер через собственное, отдельное HTTPS-соединение с сервером приложений.
Сервер приложений декапсулирует запрос, перенаправляя его на целевой сервер, который может дать ответ.
Сервер приложений возвращает инкапсулированный ответ шлюзу конфиденциальности, который затем пересылает результат клиенту.
Как указано в протоколе, запросы от клиента к серверу шифруются с использованием HPKE, современного стандарта шифрования с открытым ключом, о котором вы можете узнать больше здесь. Мы предприняли дополнительные меры для обеспечения безопасности использования HPKE протоколом OHTTP, проведя формальный анализ протокола, и мы планируем опубликовать более глубокий анализ в ближайшие недели.

Как Privacy Gateway повышает конфиденциальность конечных пользователей

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

Конфиденциальность запроса означает, что сервер приложений не узнает информацию, которая в противном случае была бы раскрыта HTTP-запросом, например IP-адрес, геолокацию, отпечатки пальцев TLS и HTTPS и т. д. Поскольку Privacy Gateway использует отдельное HTTPS-соединение между собой и сервером приложений, вся эта информация о каждом запросе, предоставляемая серверу приложений, представляет собой Privacy Gateway, а не клиента. Однако разработчикам необходимо позаботиться о том, чтобы не отправлять личную информацию в содержании запросов. Если запрос после декапсуляции включает в себя такую информацию, как, например, адрес электронной почты пользователя, номер телефона или информация о кредитной карте, Privacy Gateway не сможет значительно улучшить конфиденциальность.

Конфиденциальность клиента — более сильное понятие. Поскольку Cloudflare и сервер приложений не вступают в сговор для обмена данными отдельных пользователей, с точки зрения сервера каждая отдельная транзакция исходила от какого-то неизвестного клиента за Privacy Gateway. Другими словами, правильно сконфигурированное развертывание шлюза конфиденциальности означает, что приложения не могут связать любые два запроса с одним и тем же клиентом. В частности, с Privacy Gateway конфиденциальность любит компанию. Если шлюз конфиденциальности использует только один конечный пользователь, то он обеспечивает только конфиденциальность запросов (поскольку IP-адрес клиента остается скрытым от шлюза). Это не обеспечило бы конфиденциальность клиента, поскольку сервер знал бы, что каждый запрос соответствует одному и тому же клиенту. Конфиденциальность клиента требует, чтобы в системе было много пользователей, поэтому сервер приложений не может сделать это определение.

Чтобы лучше понять запрос и конфиденциальность клиента, рассмотрим следующий HTTP-запрос между клиентом и сервером:

Обычная конфигурация HTTP с набором анонимности клиента размером 1

Если клиент подключается напрямую к серверу (или «шлюзу» в терминах OHTTP), сервер, скорее всего, увидит информацию о клиенте, включая IP-адрес, используемый шифр TLS и данные о местоположении на основе этого IP-адреса:

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

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

При использовании Privacy Gateway клиенты не подключаются напрямую к самому серверу приложений. Вместо этого они подключаются к шлюзу конфиденциальности, который, в свою очередь, подключается к серверу. Это означает, что сервер наблюдает только за подключениями от Privacy Gateway, а не за отдельными подключениями от клиентов, что дает другое представление:

- ipAddress: 104.16.5.5 # a Cloudflare IP
- ASN: 13335
- AS Organization: Cloudflare
- tlsCipher: ECDHE-ECDSA-AES128-GCM-SHA256 # shared across several clients
- tlsVersion: TLSv1.3
- Country: US
- Region: California
- City: Los Angeles

Конфигурация Privacy Gateway с набором анонимных клиентов размером k

Это конфиденциальность запроса. Вся информация о местоположении и личности клиента скрыта от сервера приложений. И все подробности о данных приложения скрыты от Privacy Gateway. Для конфиденциальных приложений и протоколов, таких как DNS, хранение этих метаданных отдельно от данных приложения является важным шагом на пути к повышению конфиденциальности конечных пользователей.

Кроме того, приложения должны следить за тем, чтобы не раскрывать конфиденциальную информацию о каждом клиенте в своих индивидуальных запросах. Privacy Gateway не может гарантировать, что приложения не будут отправлять идентифицирующую информацию, такую как адреса электронной почты, полные имена и т. д., в теле запроса, поскольку он не может отслеживать данные приложения в открытом виде. Приложения, раскрывающие в запросах информацию, позволяющую идентифицировать пользователя, могут нарушать конфиденциальность клиента, но не запрашивать конфиденциальность. Вот почему, в отличие от нашего полноценного продукта Privacy Proxy на уровне приложения, Privacy Gateway нет предназначен для использования в качестве общего протокола на основе прокси для произвольных приложений и трафика. Это протокол специального назначения для конфиденциальных приложений, включая DNS (о чем свидетельствует Oblivious DNS-over-HTTPS), данные телеметрии или общие запросы API, как обсуждалось выше.

Интеграция Privacy Gateway в ваше приложение

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

Интеграция с сервером

Серверная часть протокола отвечает за две основные задачи:

Публикация открытого ключа для инкапсуляции запроса; а также
Расшифровка инкапсулированных клиентских запросов, обработка результирующего запроса и шифрование соответствующего ответа.

Открытый ключ инкапсуляции, называемый конфигурацией ключа, состоит из идентификатора ключа (чтобы сервер мог поддерживать несколько ключей одновременно для ротации), идентификаторов криптографических алгоритмов для шифрования и дешифрования и открытого ключа:

HPKE Symmetric Algorithms {
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
}

OHTTP Key Config {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE Public Key (Npk * 8),
  HPKE Symmetric Algorithms Length (16),
  HPKE Symmetric Algorithms (32..262140),
}

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

func (s *GatewayResource) configHandler(w http.ResponseWriter, r *http.Request) {
	config, err := s.Gateway.Config(s.keyID)
	if err != nil {
		http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
		return
	}
	w.Write(config.Marshal())
}

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

Библиотеки OHTTP с открытым исходным кодом обычно предлагают функции для расшифровки запросов и шифрования ответов, тогда как преобразование открытого текста из двоичного HTTP в HTTP-запрос выполняется отдельно. Например, наш сервер с открытым исходным кодом делегирует этот перевод другой библиотеке, которая зависит от того, как HTTP-запросы Go представлены в памяти. В частности, функция преобразования запроса открытого текста в HTTP-запрос Go выполняется с помощью функции, имеющей следующую сигнатуру:

func UnmarshalBinaryRequest(data []byte) (*http.Request, error) {
	...
}

И наоборот, преобразование ответа Go HTTP в двоичное сообщение ответа HTTP с открытым текстом выполняется с помощью функции, имеющей следующую сигнатуру:

type BinaryResponse http.Response

func (r *BinaryResponse) Marshal() ([]byte, error) {
	...
}

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

Интеграция с клиентом

Естественно, поведение OHTTP на стороне клиента отражает поведение сервера. В частности, клиент должен:

Обнаружить или получить открытый ключ сервера; а также
Кодируйте и шифруйте HTTP-запросы, отправляйте их в Privacy Gateway, а также расшифровывайте и декодируйте HTTP-ответы.

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

$ curl https://server.example/ohttp-configs > config.bin

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

configEnc := ... // encoded public key
config, err := ohttp.UnmarshalPublicConfig(configEnc)
if err != nil {
	return err
}

request, err := http.NewRequest(http.MethodGet, "https://test.example/index.html", nil)
if err != nil {
	return err
}

binaryRequest := ohttp.BinaryRequest(*request)
encodedRequest, err := binaryRequest.Marshal()
if err != nil {
	return err
}

ohttpClient := ohttp.NewDefaultClient(config)
encapsulatedReq, reqContext, err := ohttpClient.EncapsulateRequest(encodedRequest)

relayRequest, err := http.NewRequest(http.MethodPost, "https://relay.example", bytes.NewReader(encapsulatedReq.Marshal()))
if err != nil {
	return err
}
relayRequest.Header.Set("Content-Type", "message/ohttp-req")

client := http.Client{}
relayResponse, err := client.Do(relayRequest)
if err != nil {
	return err
}
bodyBytes, err := ioutil.ReadAll(relayResponse.Body)
if err != nil {
	return err
}
encapsulatedResp, err := ohttp.UnmarshalEncapsulatedResponse(bodyBytes)
if err != nil {
	return err
}

receivedResp, err := reqContext.DecapsulateResponse(encapsulatedResp)
if err != nil {
	return err
}

response, err := ohttp.UnmarshalBinaryResponse(receivedResp)
if err != nil {
	return err
}

fmt.Println(response)

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

Заинтересованы?

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

Заказать сайт визитку

Privacy Gateway: прокси-сервер, сохраняющий конфиденциальность, созданный на основе интернет-стандартов.