В Brave конфиденциальность — это не функция, а требование, вокруг которого построен проект. Наш браузер демонстрирует это в полной мере: мы блокируем трекеры, не разрешаем снимать отпечатки пальцев и предлагаем пользователям собственный рекламный сервис, ориентированный на конфиденциальность.
В сегодняшнем выпуске мы рассмотрим метод сокрытия IP-адресов пользователей от нас и нашего партнерского CDN, а также другие проблемы конфиденциальности в ленте рекомендаций браузера Brave Today. 
Известен , что во время работы Brave передает на наши серверы минимум информации и только при необходимости.
Но этого недостаточно — чтобы делать по-настоящему правильные вещи, следует поставить перед собой цель сделать принципиально невозможным причинение вреда конфиденциальности пользователей.
Как не раскрыть IP-адреса пользователей браузера? Как правило, мы отфильтровываем их из запросов к нашим бэкэндам в сети доставки контента (также известной как CDN ), чтобы адрес даже случайно не мог попасть в логи.
Но для одной из наших новых услуг мы хотим пойти еще дальше — убедиться, что никакие изменения в конфигурации CDN не могут раскрыть IP-адреса клиентов, даже если бы мы этого захотели.
Опишем по пунктам, что мы делаем и почему.
Начинать
Новые функции браузера требуют, чтобы IP-адреса клиентов были защищены лучше, чем раньше.Одной из таких функций является наша лента рекомендаций новостей Brave Today на новой вкладке браузера.
Можно просто доставлять новости через обычную сеть доставки контента: сами новости одинаковы для всех пользователей, а специфическая выборка и машинное обучение происходит локально в самом браузере.
Есть нюансы в иллюстрациях к новости.
Если вы загружаете изображения во время просмотра ленты, любой, кто может наблюдать за этими сетевыми запросами (например, CDN), может узнать, какие статьи были показаны в ленте.
Из этих фактов мы можем извлечь информацию о том, какую модель машинного обучения использует клиент, а также косвенно о том, какие страницы ранее были посещены для обучения этой модели.
Дизайн
Традиционно контент для чувствительных к задержке сервисов доставляется и кэшируется с использованием CDN. Очевидно, что оператор CDN видит как содержимое запросов пользователя, так и его IP-адрес.В нашем случае (см.
Конфиденциальность) эти потоки данных должны быть разделены.
Мы решили добавить балансировщик нагрузки перед CDN. Результат был следующий: 
В этой модели поставщик балансировщика не видит содержимое запросов и ответов.
Все, что ему доступно — это зашифрованный трафик на порту 443, расшифровать который может только сеть доставки контента.
В этом случае поставщик CDN имеет доступ ко всему внутри запросов и ответов, но вместо IP-адреса пользователя он получает один из адресов балансировщика нагрузки.
А чтобы на сторону CDN не подключались посторонние IP-адреса, он устанавливает соединения только с IP-адресами балансировщика.
Аналогично, контейнер S3, из которого сеть берет данные, возвращает данные только с использованием ключа, который есть у CDN. Также важно использовать балансировщики разных поставщиков для CDN, что мы и делаем.
Это необходимо, чтобы минимизировать теоретический риск их сговора с целью деанонимизации клиентов.
Нам нужно пойти глубже
Очевидно, что балансировщик нагрузки TCP не может расшифровать проходящий через него трафик.Но он может отслеживать размер HTTP-запросов и ответов, что является вектором атаки на эти данные.
У нас нет оснований подозревать, что наши партнеры-вендоры попытаются отслеживать пользователей, но такие убеждения неуместны, когда есть технические решения: мы добавляем к запросам отступы, чтобы сделать их размеры максимально похожими.
Например, сервис запрашивает изображения: /article/12/image/3927.png /article/8/image/148.jpg Эти запросы можно изменить следующим образом: /article/0012/image/03927.png /article/0008/image/00148.jpg Что касается HTTP-ответов, то уменьшение всех файлов до одного размера может оказаться затратным, но вы можете установить несколько стандартных размеров и выбрать тот, который вам нужен.
Это должно быть сделано каждым приложением, которое использует CDN для своих конкретных запросов.
Понятно, что для корректной работы этого алгоритма необходимо отключить сжатие на стороне CDN. Несмотря на то, что IP-адрес пользователя ни в какой форме не включен в CDN, некоторые HTTP-заголовки могут использоваться для снятия отпечатков пальцев — в зависимости от степени уникальности их значений.
Поэтому каждое приложение, использующее нашу частную сеть доставки контента, должно удалять такие заголовки из запросов.
Этот:
- Accept-Язык
- печенье
- ДНТ
- Реферер
- Пользовательский агент
Что в браузере?
Все, что было сказано до сих пор, больше относится к вендорам нашей инфраструктуры.Однако как насчет самой компании Brave, ведь у нас есть доступ к партнерским дашбордам? Чтобы идентифицировать пользователя на основе набора запросов, нам потребуется:
- Иметь доступ к журналам обеих систем,
- Добавляйте дополнительную информацию к запросам, когда они направляются из балансировщика нагрузки TCP.
Мы также не можем добавлять информацию в заголовки, так как балансировщик нагрузки не может расшифровать поток TLS. Теоретически мы могли бы настроить так, чтобы протокол прокси добавлял IP-адрес клиента во все исходящие запросы, но, к счастью, наш CDN-провайдер в принципе не может этого сделать.
На случай, если такая возможность возникнет в будущем, в нашем договоре есть специальный пункт, который оговаривает это ограничение.
Доверяй, но проверяй
Важность тщательного проектирования такой системы неоспорима, но слова и диаграммы ничего не значат без возможности проверить наши утверждения.Чтобы оправдать доверие наших пользователей, мы стараемся показывать нашу работу максимально прозрачно.
Во-первых, каждый может увидеть, как обрабатываются данные на стороне клиента, поскольку Brave браузер с открытым исходным кодом .
Во-вторых, легко проверить, к какому IP-адресу обращается браузер, проанализировав трафик, например, с помощью mitmproxy или просто посмотрев, что разрешает хост pcdn.brave.com. Наконец, чтобы убедиться, что запросы пересылаются от первого поставщика в точку расшифровки TLS, вы можете сравнить заголовки ответов из https://pcdn.brave.com/ и сайты, которые обслуживаются непосредственно первым поставщиком, например https://haveibeenpwned.com/ .
В том маловероятном случае, если вы обнаружите какие-либо ошибки или нарушения модели конфиденциальности, немедленно сообщите о них нашему программа поиска ошибок Теги: #browsers #cdn #brave Browser #cdn-service
-
.Masterhost + Reg.ru =…
19 Oct, 24 -
Работа С Файлами Cookie Из Javascript
19 Oct, 24 -
Как Портировать Libcurl На Android
19 Oct, 24
