Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ESNI – зашифрованное поле SNI
200 views
Skip to first unread message
Urban_Hero
Apr 4, 2019, 7:44:51 AM4/4/19
to
ESNI – зашифрованное поле SNI
https://dxdt.ru/2018/12/28/8645/
28. December 2018, 20:29 Безопасность, Интернет
При установлении TLS-соединения имя узла передаётся в открытом виде,
внутри поля (или расширения) SNI – Server Name Indication. На стороне
сервера имя узла требуется для того, чтобы выбрать правильный набор
сертификатов и серверных ключей, в случае, если на одном IP-адресе
отвечает несколько TLS-узлов.
С появлением новой версии TLS 1.3, в которой зашифрована существенная
часть сообщений, передаваемых при установлении соединения, вновь
обострились споры относительно того, что хорошо бы зашифровать и SNI –
ведь через это поле происходит утечка информации о том, с каким именно
узлом устанавливается соединение.
Предлагалось несколько вариантов защищённого SNI. Вероятно, будет выбран
вариант, использующий ключи в DNS: для него уже есть поддержка в
браузере Firefox (версии 64 и Nightly) и на веб-узлах Cloudflare,
несмотря на то, что сама спецификация пока в состоянии черновика.
Защищённый вариант называется ESNI (Encrypted SNI) и доступен только для
TLS 1.3 (и, в будущем, выше). Рассмотрим, как он работает.
Основная идея следующая. В DNS размещается специальная запись (сейчас
это TXT-запись, но, возможно, скоро появится выделенный для ESNI тип), в
которой публикуется открытый ключ сервера (для протокола Диффи-Хеллмана
(DH), см. ниже) и другие криптографические параметры. А именно:
шифронабор, используемый для защиты SNI; группа для DH; контрольная
сумма; время действия ключа. Для адресации DNS-записи служит специальное
имя, имеющее вид _esni.example.com (здесь важен символ подчёркивания в
начале).
Например, для узла tls13.1d.pw имя записи будет таким:
_esni.tls13.1d.pw. А значением является структура с криптографическими
параметрами, закодированная в Base64. Вот действующее значение для
_esni.tls13.1d.pw:
“/wGu7tnmACQAHQAgLukkHH6AiIAPYODmYK/6Nz3H7N58nYZyb/WG62h4TTgAAhMBAIAAAAAAXCPQTgAAAABcQ3ROAAA=”
Эти данные нужны клиенту для того, чтобы сгенерировать симметричный
ключ, который он использует для зашифрования имени сервера в ESNI.
Обычно, клиентом является браузер. Он действует по следующему алгоритму:
извлекает из DNS запись, содержащую данные ESNI; используя эти данные,
генерирует свою часть обмена по протоколу Диффи-Хеллмана, вычисляет
общий секрет, на его основе генерирует симметричный ключ и зашифровывает
SNI симметричным шифром. Получившийся шифротекст – передаётся в составе
нового расширения сообщения TLS ClientHello ESNI. Вместе с зашифрованным
SNI передаётся клиентский ключ DH, который необходим серверу для
получения симметричного ключа. Таким образом, третья сторона,
прослушивающая канал, не может прочитать значение SNI.
Конкретный пример используемых криптосистем: для (эллиптического) DH
используется кривая Curve25519; в качестве шифра – AES в режиме GCM. Все
эти параметры, как указано выше, записаны в DNS.
Сервер обнаруживает наличие ESNI по присутствию соответствующего
расширения в сообщении ClientHello, отправленном браузером (с этого
сообщения начинается процесс установления TLS-соединения). Так как
сервер знает секретный ключ DH, он может вычислить общий секрет и
симметричный ключ, а после этого – расшифровать имя сервера, полученное
в ESNI. Также сервер, успешно обработавший ESNI, отвечает с
подтверждением: возвращает клиенту уникальное значение, полученное в
зашифрованной части ESNI; при этом значение передаётся в защищённом
виде, то есть, получаем ещё один, дополнительный, канал подтверждения
подлинности сервера (для клиента).
Очевидно, что в данной схеме имя узла потенциально передаётся в открытом
виде при запросе в DNS, поэтому необходимо использовать инструменты
защиты DNS-трафика. В частности, в Firefox используют DNS-over-HTTPS
(DoH), но данная технология защищает трафик только на “последней миле”,
то есть, на пути от рекурсивного резолвера к клиенту. Кроме того, DoH
никак не решает проблему подмены DNS-ответов. То есть, в полной мере
ESNI заработает только при условии поддержки DNSSEC и внедрения TLS для
защиты DNS-транзакций на всех этапах. Тем не менее, с чего-то нужно
начать, поэтому внедрение ESNI в распространённый браузер – весьма
хороший стимул, который может подтолкнуть и другие технологии.
В качестве теста, я реализовал ESNI, в только что описанной версии, на
сервере tls13.1d.pw. Попробовать можно при помощи браузеров Firefox
Nightly или Firefox 64. Поддержка ESNI включается в “about:config” (в
64-й версии уже должна быть включена “из коробки”); обязательно нужно
также активировать DoH (DNS-over-HTTPS), указав URI сервера, который
будет обслуживать DNS-запросы – в Firefox ESNI без DoH не работает.
Если вы зайдёте на tls13.1d.pw с поддержкой ESNI, то информацию об этом
сервер выведет в начале страницы – как на скриншоте (update, 05/02/19:
из-за ошибки в библиотеке NSS, на которой базируется реализация TLS в
Firefox, увидеть при помощи этого браузера ESNI на tls13.1d.pw можно
только в том случае, если сервер не использовал пересогласование
параметров – то есть, нужно несколько раз обновить страницу; подробнее –
в отдельной записке).
https://dxdt.ru/2018/12/28/8645/
https://dxdt.ru/2018/12/28/8645/
28. December 2018, 20:29 Безопасность, Интернет
При установлении TLS-соединения имя узла передаётся в открытом виде,
внутри поля (или расширения) SNI – Server Name Indication. На стороне
сервера имя узла требуется для того, чтобы выбрать правильный набор
сертификатов и серверных ключей, в случае, если на одном IP-адресе
отвечает несколько TLS-узлов.
С появлением новой версии TLS 1.3, в которой зашифрована существенная
часть сообщений, передаваемых при установлении соединения, вновь
обострились споры относительно того, что хорошо бы зашифровать и SNI –
ведь через это поле происходит утечка информации о том, с каким именно
узлом устанавливается соединение.
Предлагалось несколько вариантов защищённого SNI. Вероятно, будет выбран
вариант, использующий ключи в DNS: для него уже есть поддержка в
браузере Firefox (версии 64 и Nightly) и на веб-узлах Cloudflare,
несмотря на то, что сама спецификация пока в состоянии черновика.
Защищённый вариант называется ESNI (Encrypted SNI) и доступен только для
TLS 1.3 (и, в будущем, выше). Рассмотрим, как он работает.
Основная идея следующая. В DNS размещается специальная запись (сейчас
это TXT-запись, но, возможно, скоро появится выделенный для ESNI тип), в
которой публикуется открытый ключ сервера (для протокола Диффи-Хеллмана
(DH), см. ниже) и другие криптографические параметры. А именно:
шифронабор, используемый для защиты SNI; группа для DH; контрольная
сумма; время действия ключа. Для адресации DNS-записи служит специальное
имя, имеющее вид _esni.example.com (здесь важен символ подчёркивания в
начале).
Например, для узла tls13.1d.pw имя записи будет таким:
_esni.tls13.1d.pw. А значением является структура с криптографическими
параметрами, закодированная в Base64. Вот действующее значение для
_esni.tls13.1d.pw:
“/wGu7tnmACQAHQAgLukkHH6AiIAPYODmYK/6Nz3H7N58nYZyb/WG62h4TTgAAhMBAIAAAAAAXCPQTgAAAABcQ3ROAAA=”
Эти данные нужны клиенту для того, чтобы сгенерировать симметричный
ключ, который он использует для зашифрования имени сервера в ESNI.
Обычно, клиентом является браузер. Он действует по следующему алгоритму:
извлекает из DNS запись, содержащую данные ESNI; используя эти данные,
генерирует свою часть обмена по протоколу Диффи-Хеллмана, вычисляет
общий секрет, на его основе генерирует симметричный ключ и зашифровывает
SNI симметричным шифром. Получившийся шифротекст – передаётся в составе
нового расширения сообщения TLS ClientHello ESNI. Вместе с зашифрованным
SNI передаётся клиентский ключ DH, который необходим серверу для
получения симметричного ключа. Таким образом, третья сторона,
прослушивающая канал, не может прочитать значение SNI.
Конкретный пример используемых криптосистем: для (эллиптического) DH
используется кривая Curve25519; в качестве шифра – AES в режиме GCM. Все
эти параметры, как указано выше, записаны в DNS.
Сервер обнаруживает наличие ESNI по присутствию соответствующего
расширения в сообщении ClientHello, отправленном браузером (с этого
сообщения начинается процесс установления TLS-соединения). Так как
сервер знает секретный ключ DH, он может вычислить общий секрет и
симметричный ключ, а после этого – расшифровать имя сервера, полученное
в ESNI. Также сервер, успешно обработавший ESNI, отвечает с
подтверждением: возвращает клиенту уникальное значение, полученное в
зашифрованной части ESNI; при этом значение передаётся в защищённом
виде, то есть, получаем ещё один, дополнительный, канал подтверждения
подлинности сервера (для клиента).
Очевидно, что в данной схеме имя узла потенциально передаётся в открытом
виде при запросе в DNS, поэтому необходимо использовать инструменты
защиты DNS-трафика. В частности, в Firefox используют DNS-over-HTTPS
(DoH), но данная технология защищает трафик только на “последней миле”,
то есть, на пути от рекурсивного резолвера к клиенту. Кроме того, DoH
никак не решает проблему подмены DNS-ответов. То есть, в полной мере
ESNI заработает только при условии поддержки DNSSEC и внедрения TLS для
защиты DNS-транзакций на всех этапах. Тем не менее, с чего-то нужно
начать, поэтому внедрение ESNI в распространённый браузер – весьма
хороший стимул, который может подтолкнуть и другие технологии.
В качестве теста, я реализовал ESNI, в только что описанной версии, на
сервере tls13.1d.pw. Попробовать можно при помощи браузеров Firefox
Nightly или Firefox 64. Поддержка ESNI включается в “about:config” (в
64-й версии уже должна быть включена “из коробки”); обязательно нужно
также активировать DoH (DNS-over-HTTPS), указав URI сервера, который
будет обслуживать DNS-запросы – в Firefox ESNI без DoH не работает.
Если вы зайдёте на tls13.1d.pw с поддержкой ESNI, то информацию об этом
сервер выведет в начале страницы – как на скриншоте (update, 05/02/19:
из-за ошибки в библиотеке NSS, на которой базируется реализация TLS в
Firefox, увидеть при помощи этого браузера ESNI на tls13.1d.pw можно
только в том случае, если сервер не использовал пересогласование
параметров – то есть, нужно несколько раз обновить страницу; подробнее –
в отдельной записке).
https://dxdt.ru/2018/12/28/8645/
Urban_Hero
Apr 4, 2019, 7:46:20 AM4/4/19
to
Domain Fronting, AWS и блокировки с обходом
https://dxdt.ru/2018/05/02/8500/
2. May 2018, 12:03 Безопасность, Интернет, Компьютеры и ПО, Новостное
Очередная новость “про блокировки” сообщает, что, якобы, Amazon запретил
“использовать свои сети в качестве прокси” (варианты: использовать для
“обхода блокировок” и др.). Сообщения сопровождаются ссылкой на
публикацию AWS (Amazon Web Services), где, впрочем, рассказывается о другом.
О чём идет речь? Действительно, существует схема маскировки имени
сервиса, под названием Domain Fronting. Схема построена на архитектурной
особенности HTTPS: данный протокол использует TLS в качестве транспорта,
соответственно, появляются два уровня – TLS и HTTP. С каждым из этих
уровней связано некоторое имя сервера (имя хоста). В TLS это имя
передаётся в поле SNI (Server Name Indication), в открытом виде, то
есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть
ещё одно имя сервера, оно входит в состав адреса документа (URI),
который запрашивает клиент. Этот адрес, а следовательно и имя, входящее
в его состав, передаётся уже в зашифрованном виде, поэтому недоступен
для DPI.
Пример: пусть клиент, являющийся браузером, использует веб-сервер под
именем “example.com” и пытается с помощью HTTPS извлечь документ по
адресу “https://example.com/document.html”. Тогда при установлении
TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в
поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без
полного адреса документа, только имя узла, домен). После того, как
TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав,
согласно спецификации протокола HTTP, адрес документа “/document.html” и
имя узла (в специальном поле заголовка HTTP-запроса, под названием Host)
“example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но
вообще имена могут различаться, так как находятся на разных уровнях
абстракции. Приложение, работающее по HTTP, вообще обычно не видит не
только имени в SNI, но и самого протокола TLS.
Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается
имя одного сервера, но после того, как TLS-соединение установлено, HTTP
запросы отправляются с указанием другого имени. Поясню в терминах
примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”,
однако GET-запрос уже отправляется с указанием “test.ru” в качестве
имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как
TLS и HTTP используют разный контекст, сервис, где размещён исходный
узел (адресуемый example.com в нашем примере), может выполнять и
HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации
HTTPS на стороне сервиса.
Теперь предположим, что из некоторого сегмента Глобальной сети доступ к
test.ru по каким-то причинам невозможен. Используя Domain Fronting можно
замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com:
так как HTTP-запросы передаются в зашифрованном виде, анализирующая
трафик сторона видит только имя example.com в поле SNI TLS. Конечно,
могут заблокировать и доступ к example.com, в том числе, по IP-адресу,
но тут в игру вступает административная часть: представьте, что вместо
example.com используется google.com (или какой-то другой массовый
сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё
сработало, требуется поддержка описанной схемы со стороны сервиса,
используемого как прикрытие. Именно на этом этапе и возникает сервис
“Амазон” CloudFront, который позволяет (или позволял, см. ниже)
использовать такую схему для ресурсов, которые размещаются за
CloudFront. При этом “заехать” за чей-то домен можно без ведома того
клиента CloudFront, который этот домен использует штатно, что, конечно,
не самая привлекательная особенность сервиса.
Метод маскировки с использованием Domain Fronting известен много лет.
Наличие такой особенности объясняется тем, что для массового сервиса
удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают
TLS-соединение (выполняют “терминирование TLS”), а другие – работают с
HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода
блокировок” как раз послужило то, что “Амазон” недавно обновил платформу
CloudFront, исправив обработку контекстов и, тем самым, удалив
возможность использования Domain Fronting. Думаю, понятно, что к “обходу
блокировок” это если и имеет какое-то отношение, то весьма и весьма
косвенное, и только со стороны тех нестандартных клиентов, которые
данную особенность использовали. К ним, например, относится мессенджер
Signal, который, впрочем, уже получил предупреждение о нарушении правил
использования сервиса от Amazon.
https://dxdt.ru/2018/05/02/8500/
https://dxdt.ru/2018/05/02/8500/
2. May 2018, 12:03 Безопасность, Интернет, Компьютеры и ПО, Новостное
Очередная новость “про блокировки” сообщает, что, якобы, Amazon запретил
“использовать свои сети в качестве прокси” (варианты: использовать для
“обхода блокировок” и др.). Сообщения сопровождаются ссылкой на
публикацию AWS (Amazon Web Services), где, впрочем, рассказывается о другом.
О чём идет речь? Действительно, существует схема маскировки имени
сервиса, под названием Domain Fronting. Схема построена на архитектурной
особенности HTTPS: данный протокол использует TLS в качестве транспорта,
соответственно, появляются два уровня – TLS и HTTP. С каждым из этих
уровней связано некоторое имя сервера (имя хоста). В TLS это имя
передаётся в поле SNI (Server Name Indication), в открытом виде, то
есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть
ещё одно имя сервера, оно входит в состав адреса документа (URI),
который запрашивает клиент. Этот адрес, а следовательно и имя, входящее
в его состав, передаётся уже в зашифрованном виде, поэтому недоступен
для DPI.
Пример: пусть клиент, являющийся браузером, использует веб-сервер под
именем “example.com” и пытается с помощью HTTPS извлечь документ по
адресу “https://example.com/document.html”. Тогда при установлении
TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в
поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без
полного адреса документа, только имя узла, домен). После того, как
TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав,
согласно спецификации протокола HTTP, адрес документа “/document.html” и
имя узла (в специальном поле заголовка HTTP-запроса, под названием Host)
“example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но
вообще имена могут различаться, так как находятся на разных уровнях
абстракции. Приложение, работающее по HTTP, вообще обычно не видит не
только имени в SNI, но и самого протокола TLS.
Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается
имя одного сервера, но после того, как TLS-соединение установлено, HTTP
запросы отправляются с указанием другого имени. Поясню в терминах
примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”,
однако GET-запрос уже отправляется с указанием “test.ru” в качестве
имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как
TLS и HTTP используют разный контекст, сервис, где размещён исходный
узел (адресуемый example.com в нашем примере), может выполнять и
HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации
HTTPS на стороне сервиса.
Теперь предположим, что из некоторого сегмента Глобальной сети доступ к
test.ru по каким-то причинам невозможен. Используя Domain Fronting можно
замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com:
так как HTTP-запросы передаются в зашифрованном виде, анализирующая
трафик сторона видит только имя example.com в поле SNI TLS. Конечно,
могут заблокировать и доступ к example.com, в том числе, по IP-адресу,
но тут в игру вступает административная часть: представьте, что вместо
example.com используется google.com (или какой-то другой массовый
сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё
сработало, требуется поддержка описанной схемы со стороны сервиса,
используемого как прикрытие. Именно на этом этапе и возникает сервис
“Амазон” CloudFront, который позволяет (или позволял, см. ниже)
использовать такую схему для ресурсов, которые размещаются за
CloudFront. При этом “заехать” за чей-то домен можно без ведома того
клиента CloudFront, который этот домен использует штатно, что, конечно,
не самая привлекательная особенность сервиса.
Метод маскировки с использованием Domain Fronting известен много лет.
Наличие такой особенности объясняется тем, что для массового сервиса
удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают
TLS-соединение (выполняют “терминирование TLS”), а другие – работают с
HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода
блокировок” как раз послужило то, что “Амазон” недавно обновил платформу
CloudFront, исправив обработку контекстов и, тем самым, удалив
возможность использования Domain Fronting. Думаю, понятно, что к “обходу
блокировок” это если и имеет какое-то отношение, то весьма и весьма
косвенное, и только со стороны тех нестандартных клиентов, которые
данную особенность использовали. К ним, например, относится мессенджер
Signal, который, впрочем, уже получил предупреждение о нарушении правил
использования сервиса от Amazon.
https://dxdt.ru/2018/05/02/8500/
Urban_Hero
Apr 4, 2019, 7:47:55 AM4/4/19
to
On 04/04/2019 14:43, Urban_Hero wrote:
> Domain Fronting, AWS и блокировки с обходом
>
> https://dxdt.ru/2018/05/02/8500/
>
>
> Domain Fronting, AWS и блокировки с обходом
>
> https://dxdt.ru/2018/05/02/8500/
>
>
> Метод маскировки с использованием Domain Fronting известен много лет.
> Наличие такой особенности объясняется тем, что для массового сервиса
> удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают
> TLS-соединение (выполняют “терминирование TLS”), а другие – работают с
> HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода
> блокировок” как раз послужило то, что “Амазон” недавно обновил платформу
> CloudFront, исправив обработку контекстов и, тем самым, удалив
> возможность использования Domain Fronting. Думаю, понятно, что к “обходу
> блокировок” это если и имеет какое-то отношение, то весьма и весьма
> косвенное, и только со стороны тех нестандартных клиентов, которые
> данную особенность использовали. К ним, например, относится мессенджер
> Signal, который, впрочем, уже получил предупреждение о нарушении правил
> использования сервиса от Amazon.
>
> https://dxdt.ru/2018/05/02/8500/
AWS Security Blog
> Наличие такой особенности объясняется тем, что для массового сервиса
> удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают
> TLS-соединение (выполняют “терминирование TLS”), а другие – работают с
> HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода
> блокировок” как раз послужило то, что “Амазон” недавно обновил платформу
> CloudFront, исправив обработку контекстов и, тем самым, удалив
> возможность использования Domain Fronting. Думаю, понятно, что к “обходу
> блокировок” это если и имеет какое-то отношение, то весьма и весьма
> косвенное, и только со стороны тех нестандартных клиентов, которые
> данную особенность использовали. К ним, например, относится мессенджер
> Signal, который, впрочем, уже получил предупреждение о нарушении правил
> использования сервиса от Amazon.
>
> https://dxdt.ru/2018/05/02/8500/
Enhanced Domain Protections for Amazon CloudFront Requests
by Colm MacCarthaigh | on 27 APR 2018 | in Amazon CloudFront, Amazon
Route 53, Networking & Content Delivery | Permalink | Comments | Share
Over the coming weeks, we’ll be adding enhanced domain protections to
Amazon CloudFront. The short version is this: the new measures are
designed to ensure that requests handled by CloudFront are handled on
behalf of legitimate domain owners.
Using CloudFront to receive traffic for a domain you aren’t authorized
to use is already a violation of our AWS Terms of Service. When we
become aware of this type of activity, we deal with it behind the scenes
by disabling abusive accounts. Now we’re integrating checks directly
into the CloudFront API and Content Distribution service, as well.
Enhanced Protection against Dangling DNS entries
To use CloudFront with your domain, you must configure your domain to
point at CloudFront. You may use a traditional CNAME, or an Amazon Route
53 “ALIAS” record.
A problem can arise if you delete your CloudFront distribution, but
leave your DNS still pointing at CloudFront, popularly known as a
“dangling” DNS entry. Thankfully, this is very rare, as the domain will
no longer work, but we occasionally see customers who leave their old
domains dormant. This can also happen if you leave this kind of
“dangling” DNS entry pointing at other infrastructure you no longer
control. For example, if you leave a domain pointing at an IP address
that you don’t control, then there is a risk that someone may come along
and “claim” traffic destined for your domain.
In an even more rare set of circumstances, an abuser can exploit a
subdomain of a domain that you are actively using. For example, if a
customer left “images.example.com” dangling and pointing to a deleted
CloudFront distribution which is no longer in use, but they still
actively use the parent domain “example.com”, then an abuser could come
along and register “images.example.com” as an alternative name on their
own distribution and claim traffic that they aren’t entitled to. This
also means that cookies may be set and intercepted for HTTP traffic
potentially including the parent domain. HTTPS traffic remains protected
if you’ve removed the certificate associated with the original
CloudFront distribution.
Of course, the best fix for this kind of risk is not to leave dangling
DNS entries in the first place. Earlier in February, 2018, we added a
new warning to our systems. With this warning, if you remove an
alternate domain name from a distribution, you are reminded to delete
any DNS entries that may still be pointing at CloudFront.
We also have long-standing checks in the CloudFront API that ensure this
kind of domain claiming can’t occur when you are using wildcard domains.
If you attempt to add *.example.com to your CloudFront distribution, but
another account has already registered www.example.com, then the attempt
will fail.
With the new enhanced domain protection, CloudFront will now also check
your DNS whenever you remove an alternate domain. If we determine that
the domain is still pointing at your CloudFront distribution, the API
call will fail and no other accounts will be able to claim this traffic
in the future.
Enhanced Protection against Domain Fronting
CloudFront will also be soon be implementing enhanced protections
against so-called “Domain Fronting”. Domain Fronting is when a
non-standard client makes a TLS/SSL connection to a certain name, but
then makes a HTTPS request for an unrelated name. For example, the TLS
connection may connect to “www.example.com” but then issue a request for
“www.example.org”.
In certain circumstances this is normal and expected. For example,
browsers can re-use persistent connections for any domain that is listed
in the same SSL Certificate, and these are considered related domains.
But in other cases, tools including malware can use this technique
between completely unrelated domains to evade restrictions and blocks
that can be imposed at the TLS/SSL layer.
To be clear, this technique can’t be used to impersonate domains. The
clients are non-standard and are working around the usual TLS/SSL checks
that ordinary clients impose. But clearly, no customer ever wants to
find that someone else is masquerading as their innocent, ordinary
domain. Although these cases are also already handled as a breach of our
AWS Terms of Service, in the coming weeks we will be checking that the
account that owns the certificate we serve for a particular connection
always matches the account that owns the request we handle on that
connection. As ever, the security of our customers is our top priority,
and we will continue to provide enhanced protection against
misconfigurations and abuse from unrelated parties.
Want more AWS Security how-to content, news, and feature announcements?
Follow us on Twitter.
TAGS: Amazon CloudFront, Amazon Route 53, DNS, SSL/TLS
https://aws.amazon.com/blogs/security/enhanced-domain-protections-for-amazon-cloudfront-requests/
Urban_Hero
Apr 4, 2019, 7:48:38 AM4/4/19
to
https://dxdt.ru/2019/02/13/8696/
ESNI (зашифрованное поле SNI) и системы анализа трафика
13. February 2019, 19:37 Безопасность, Интернет, Компьютеры и ПО
Про технологию ESNI (и SNI) я не так давно написал несколько записок.
Сейчас ESNI находится в процессе внедрения, интересно взглянуть на
эффект, который данная технология будет иметь для систем инспекции
трафика и блокирования доступа. Современные системы используют SNI (а
также, в продвинутых вариантах, TLS-сертификаты) для обнаружения имён
узлов, с которыми пытается установить соединение пользователь. ESNI
скрывает эти имена из SNI (TLS-сертификаты скрыты в новой версии TLS
1.3), причём, текущая версия ESNI использует для этого ключи,
опубликованные в DNS.
То есть, особенность ESNI в том, что в качестве дополнительного
источника ключей, защищающих метаинформацию, используется независимая от
TLS система – DNS. Это важный момент: для того, чтобы зашифровать “адрес
обращения”, клиенту не нужно устанавливать дополнительные соединения –
получить нужный ключ можно типовым запросом к системе доменных имён;
вообще говоря, не обязательно при этом указывать имя того TLS-узла, с
которым будет соединяться клиент.
Провайдер хостинга может использовать ключи, опубликованные под одним
DNS-именем, для обеспечения доступа к “скрытым серверам” под совсем
другими именами, это означает, что открытый запрос в DNS не будет
раскрывать имя “целевого узла”. Например, Cloudflare сейчас использует
одни и те же ключи для самых разных веб-узлов. Более того, “скрытый
узел” может находиться за некоторым “фронтэндом”, имеющим другое,
универсальное, имя – фактически, это Domain Fronting.
В идеале, для работы ESNI нужны DNSSEC (чтобы аутентифицировать источник
ключей и защитить DNS-трафик от подмены) и DNS-over-TLS (чтобы защитить
DNS-трафик от пассивного прослушивания). Но и в условиях незащищённой
DNS, технология ESNI довольно эффективна (отмечу, что ESNI
предусматривает и вариант, в котором ключи встраиваются в приложение,
либо передаются каким-то ещё способом, без DNS).
В открытой DNS, системы анализа трафика, которые видят весь трафик
клиента, могут сопоставить запрос в DNS для извлечения ключа ESNI и
последующее TLS-соединение. DNS-ответ с ключами даже можно
заблокировать, сделав использование ESNI невозможным (но только при
условии, что ключи не были получены другим способом). Однако
автоматическое корректное сопоставление имени из DNS-запроса и сессии
TLS – представляют серьёзную дополнительную задачу, которая тем сложнее,
чем больше объём трафика, анализируемого системой фильтрации. (Конечно,
уже само наличие ESNI может являться признаком подозрительного соединения.)
То есть, ESNI, в случае массового внедрения, довольно заметно повлияет
на ландшафт систем инспекции трафика. А кроме того, данная технология
может подстегнуть рост распространённости DNSSEC и DNS-over-TLS.
Впрочем, пока что ESNI не поддерживается распространёнными
веб-серверами, да и соответствующий RFC не вышел из статуса черновика.
(Как работает ESNI – можно посмотреть на моём тестовом сервере TLS 1.3,
там реализована поддержка.)
https://dxdt.ru/2019/02/13/8696/
ESNI (зашифрованное поле SNI) и системы анализа трафика
13. February 2019, 19:37 Безопасность, Интернет, Компьютеры и ПО
Про технологию ESNI (и SNI) я не так давно написал несколько записок.
Сейчас ESNI находится в процессе внедрения, интересно взглянуть на
эффект, который данная технология будет иметь для систем инспекции
трафика и блокирования доступа. Современные системы используют SNI (а
также, в продвинутых вариантах, TLS-сертификаты) для обнаружения имён
узлов, с которыми пытается установить соединение пользователь. ESNI
скрывает эти имена из SNI (TLS-сертификаты скрыты в новой версии TLS
1.3), причём, текущая версия ESNI использует для этого ключи,
опубликованные в DNS.
То есть, особенность ESNI в том, что в качестве дополнительного
источника ключей, защищающих метаинформацию, используется независимая от
TLS система – DNS. Это важный момент: для того, чтобы зашифровать “адрес
обращения”, клиенту не нужно устанавливать дополнительные соединения –
получить нужный ключ можно типовым запросом к системе доменных имён;
вообще говоря, не обязательно при этом указывать имя того TLS-узла, с
которым будет соединяться клиент.
Провайдер хостинга может использовать ключи, опубликованные под одним
DNS-именем, для обеспечения доступа к “скрытым серверам” под совсем
другими именами, это означает, что открытый запрос в DNS не будет
раскрывать имя “целевого узла”. Например, Cloudflare сейчас использует
одни и те же ключи для самых разных веб-узлов. Более того, “скрытый
узел” может находиться за некоторым “фронтэндом”, имеющим другое,
универсальное, имя – фактически, это Domain Fronting.
В идеале, для работы ESNI нужны DNSSEC (чтобы аутентифицировать источник
ключей и защитить DNS-трафик от подмены) и DNS-over-TLS (чтобы защитить
DNS-трафик от пассивного прослушивания). Но и в условиях незащищённой
DNS, технология ESNI довольно эффективна (отмечу, что ESNI
предусматривает и вариант, в котором ключи встраиваются в приложение,
либо передаются каким-то ещё способом, без DNS).
В открытой DNS, системы анализа трафика, которые видят весь трафик
клиента, могут сопоставить запрос в DNS для извлечения ключа ESNI и
последующее TLS-соединение. DNS-ответ с ключами даже можно
заблокировать, сделав использование ESNI невозможным (но только при
условии, что ключи не были получены другим способом). Однако
автоматическое корректное сопоставление имени из DNS-запроса и сессии
TLS – представляют серьёзную дополнительную задачу, которая тем сложнее,
чем больше объём трафика, анализируемого системой фильтрации. (Конечно,
уже само наличие ESNI может являться признаком подозрительного соединения.)
То есть, ESNI, в случае массового внедрения, довольно заметно повлияет
на ландшафт систем инспекции трафика. А кроме того, данная технология
может подстегнуть рост распространённости DNSSEC и DNS-over-TLS.
Впрочем, пока что ESNI не поддерживается распространёнными
веб-серверами, да и соответствующий RFC не вышел из статуса черновика.
(Как работает ESNI – можно посмотреть на моём тестовом сервере TLS 1.3,
там реализована поддержка.)
https://dxdt.ru/2019/02/13/8696/
Urban_Hero
Apr 4, 2019, 7:54:03 AM4/4/19
to
Реальность SSL в Интернете: Trustwave
12. February 2012, 15:08 Безопасность, Интернет
На прошлой неделе масла в огонь обсуждения непростой ситуации с
иерархией SSL-сертификатов в Интернете подлил бренд Trustwave,
представители которого открыто признали, что их удостоверяющий центр
выпустил корневые сертификаты (или, возможно, один сертификат – как
утверждают) для использования в составе систем мониторинга трафика. То
есть, при помощи ключей от такого сертификата можно перехватывать
HTTPS-соединения и просматривать трафик так, что рядовой пользователь
даже ничего не почувствует: нет никаких предупреждений браузера, не
меняется домен, не перенаправляются запросы. Схема работает благодаря
тому, что корень Trustwave встроен в браузеры.
(Наверное, нужно в отдельной заметке описать, как всё это реализуется в
технических деталях. Но, думаю, в другой раз. Пока отмечу, что в
действительно корпоративном окружении для организации прозрачного
исследования HTTPS-трафика с корпоративных рабочих мест не требуется
использовать полноценный корневой сертификат, выпущенный признаваемым
удостоверяющим центром в обход фундаментальных правил: достаточно
сделать собственный “корень” и встроить его в браузеры на рабочих
местах. Собственно, обычно так и поступают. А вот полноценный сертификат
позволяет прозрачно перехватывать трафик с любого компьютера,
подключенного к контролируемому сегменту сети. Например, такая штука
очень хорошо будет работать в отеле, куда посетители приезжают со своими
компьютерами.)
Вообще, рассказывая о реализации технологий взаимодействия с веб-сайтами
по HTTPS, с использованием SSL-сертификатов, редко кто обходится без
упоминания об иерархии доверия, которую составляют удостоверяющие
центры. Последние выпускают сертификаты для тех или иных доменов, под
которыми работают защищённые веб-сайты. (Для полноты картины напомню,
что сертификаты используются не только для доменов и сайтов, но и для
подписывания программного кода, при авторизации пользователей и так
далее.) Известно, что использование HTTPS позволяет защитить трафик от
перехвата, для этого служит шифрование. Третья сторона, – как раз
представляющая элемент только что упомянутой иерархии удостоверяющих
центров, – нужна для того, чтобы исключить атаки типа “человек
посередине”. Именно пример такой атаки, когда злоумышленник выдаёт себя
за доверенный сайт, подставляя вместо “настоящего” свой собственный
SSL-сертификат, традиционно используют в качестве иллюстрации,
обосновывающей необходимость удостоверяющих центров.
Хорошо известно, что если злоумышленник сумел получить доступ к
удостоверяющему центру, то система доверия полностью разрушается, а
пользователь, который вынужден по определению доверять сертификатам
центра (они встроены в браузер!), оказывается даже в худшем положении по
сравнению со случаем, когда SSL-сертификаты никто дополнительно не
удостоверяет.
Едва ли не менее популярным поводом для дискуссий сейчас является тот
факт, что из-за “особенностей реализации” всякий удостоверяющий центр
может выпустить вполне рабочий сертификат для любого домена. То есть, вы
приобрели коммерческий сертификат для своего сайта, и при этом никто не
гарантирует, что кто-то ещё тем или иным способом не приобретёт в другом
удостоверяющем центре сертификат для вашего же домена. Да, а сообщение
Trustwave очередной раз подтверждает, что вовсе не обязательно, чтобы в
упомянутой схеме активно участвовал злоумышленник.
Полноценные сертификаты для “чужих” доменов могут использоваться в
системах мониторинга и анализа трафика. Традиционный рынок для таких
систем – сети и узлы, от которых требуется отслеживание шифрованного (и,
якобы, “доверенного”) трафика HTTPS. Об этих “особенностях” давно
известно, постоянно ходят как бы слухи, что удостоверяющие центры
выпускают “левые” сертификаты по “особым заявкам”, но шумное публичное
обсуждение вне профильного сообщества, похоже, намечается только сейчас.
Вернёмся к теме: да, проблема тут в том, что Trustwave использовали своё
положение “центра доверия” для того, чтобы поставлять систему,
трактующую это “доверие”, мягко говоря, не так, как его трактуют в
презентациях для владельцев веб-сайтов, которые приобретают
SSL-сертификаты. С другой стороны, хорошо известно, что Trustwave не
первые, и, возможно, не последние. А всё это лишь очередной громкий
информационный повод для того чтобы “пересмотреть существующую систему”.
Чуть ранее шумели вокруг “массовых взломов и хакерских атак на VeriSign”
(а это вообще крупнейший провайдер “доверия” в действующей иерархии,
даже DNS подписана с участием этой компании). Вокруг данных технологий
существует заметный рынок и разные бизнесы, так что, похоже, заготовлено
занятное продолжение.
12. February 2012, 15:08 Безопасность, Интернет
На прошлой неделе масла в огонь обсуждения непростой ситуации с
иерархией SSL-сертификатов в Интернете подлил бренд Trustwave,
представители которого открыто признали, что их удостоверяющий центр
выпустил корневые сертификаты (или, возможно, один сертификат – как
утверждают) для использования в составе систем мониторинга трафика. То
есть, при помощи ключей от такого сертификата можно перехватывать
HTTPS-соединения и просматривать трафик так, что рядовой пользователь
даже ничего не почувствует: нет никаких предупреждений браузера, не
меняется домен, не перенаправляются запросы. Схема работает благодаря
тому, что корень Trustwave встроен в браузеры.
(Наверное, нужно в отдельной заметке описать, как всё это реализуется в
технических деталях. Но, думаю, в другой раз. Пока отмечу, что в
действительно корпоративном окружении для организации прозрачного
исследования HTTPS-трафика с корпоративных рабочих мест не требуется
использовать полноценный корневой сертификат, выпущенный признаваемым
удостоверяющим центром в обход фундаментальных правил: достаточно
сделать собственный “корень” и встроить его в браузеры на рабочих
местах. Собственно, обычно так и поступают. А вот полноценный сертификат
позволяет прозрачно перехватывать трафик с любого компьютера,
подключенного к контролируемому сегменту сети. Например, такая штука
очень хорошо будет работать в отеле, куда посетители приезжают со своими
компьютерами.)
Вообще, рассказывая о реализации технологий взаимодействия с веб-сайтами
по HTTPS, с использованием SSL-сертификатов, редко кто обходится без
упоминания об иерархии доверия, которую составляют удостоверяющие
центры. Последние выпускают сертификаты для тех или иных доменов, под
которыми работают защищённые веб-сайты. (Для полноты картины напомню,
что сертификаты используются не только для доменов и сайтов, но и для
подписывания программного кода, при авторизации пользователей и так
далее.) Известно, что использование HTTPS позволяет защитить трафик от
перехвата, для этого служит шифрование. Третья сторона, – как раз
представляющая элемент только что упомянутой иерархии удостоверяющих
центров, – нужна для того, чтобы исключить атаки типа “человек
посередине”. Именно пример такой атаки, когда злоумышленник выдаёт себя
за доверенный сайт, подставляя вместо “настоящего” свой собственный
SSL-сертификат, традиционно используют в качестве иллюстрации,
обосновывающей необходимость удостоверяющих центров.
Хорошо известно, что если злоумышленник сумел получить доступ к
удостоверяющему центру, то система доверия полностью разрушается, а
пользователь, который вынужден по определению доверять сертификатам
центра (они встроены в браузер!), оказывается даже в худшем положении по
сравнению со случаем, когда SSL-сертификаты никто дополнительно не
удостоверяет.
Едва ли не менее популярным поводом для дискуссий сейчас является тот
факт, что из-за “особенностей реализации” всякий удостоверяющий центр
может выпустить вполне рабочий сертификат для любого домена. То есть, вы
приобрели коммерческий сертификат для своего сайта, и при этом никто не
гарантирует, что кто-то ещё тем или иным способом не приобретёт в другом
удостоверяющем центре сертификат для вашего же домена. Да, а сообщение
Trustwave очередной раз подтверждает, что вовсе не обязательно, чтобы в
упомянутой схеме активно участвовал злоумышленник.
Полноценные сертификаты для “чужих” доменов могут использоваться в
системах мониторинга и анализа трафика. Традиционный рынок для таких
систем – сети и узлы, от которых требуется отслеживание шифрованного (и,
якобы, “доверенного”) трафика HTTPS. Об этих “особенностях” давно
известно, постоянно ходят как бы слухи, что удостоверяющие центры
выпускают “левые” сертификаты по “особым заявкам”, но шумное публичное
обсуждение вне профильного сообщества, похоже, намечается только сейчас.
Вернёмся к теме: да, проблема тут в том, что Trustwave использовали своё
положение “центра доверия” для того, чтобы поставлять систему,
трактующую это “доверие”, мягко говоря, не так, как его трактуют в
презентациях для владельцев веб-сайтов, которые приобретают
SSL-сертификаты. С другой стороны, хорошо известно, что Trustwave не
первые, и, возможно, не последние. А всё это лишь очередной громкий
информационный повод для того чтобы “пересмотреть существующую систему”.
Чуть ранее шумели вокруг “массовых взломов и хакерских атак на VeriSign”
(а это вообще крупнейший провайдер “доверия” в действующей иерархии,
даже DNS подписана с участием этой компании). Вокруг данных технологий
существует заметный рынок и разные бизнесы, так что, похоже, заготовлено
занятное продолжение.
Urban_Hero
Apr 4, 2019, 7:54:08 AM4/4/19
to
Антивирусы и “подмена” сертификатов в браузерах
14. September 2017, 17:06 Безопасность, Интернет, Компьютеры и ПО
Современные антивирусы нередко добавляют свой “особый” корневой
сертификат в системное хранилище или в хранилище браузера (зависит от
платформы), это делается для того, чтобы прозрачно и без предупреждений
для пользователя инспектировать трафик, защищённый TLS (обычно – HTTPS).
Антивирус проксирует соединения, генерируя в реальном времени подменные
сертификаты для TLS-серверов, которые посещает пользователь. Подменные
сертификаты подписаны от корневого сертификата антивируса. У такого
решения есть ряд неприятных, с точки зрения безопасности, побочных
эффектов. Так, при помощи ключа от этого корневого сертификата можно
перехватывать TLS-соединения не только на компьютере пользователя, но и
на других промежуточных узлах сети (при этом не обязательно, чтобы
антивирус работал – достаточно, что его корневой сертификат находится в
списке доверенных).
Естественно, антивирус должен бы при установке генерировать для
добавляемого сертификата уникальный локальный ключ. В противном случае,
всякий пользователь антивируса, который сумел извлечь ключ из своей
копии программы, получает потенциальную возможность перехватывать трафик
других пользователей. Но, во-первых, антивирус может полагать, что
сгодится и одинаковый для всех установок ключ. Во-вторых, уже
встречались ошибки (или условные “ошибки”) в реализациях аналогичных
схем, приводившие к тому, что ключ везде получался один и тот же.
В-третьих, генерировать локальный ключ можно таким способом, что, зная
дополнительную информацию, его нетрудно быстро вычислить и использовать
на перехватывающем узле.
Перехватывающему узлу, конечно, ещё необходимо определить, что у
клиента, который пытается установить TLS-соединение, встроен корневой
сертификат от данного антивируса. Дело в том, что список корневых
сертификатов системы не передаётся наружу, а попытка подмены при
неустановленном сертификате – вызовет предупреждение в браузере. Однако
перехватывающий узел может распознать антивирус подходящей версии при
помощи анализа пакетов, которыми этот антивирус обменивается с
центральными серверами разработчика. При целевой атаке – определить
антивирус можно, просто взглянув на интерфейс операционной системы. Ну,
либо сами разработчики могут посмотреть в регистрационной БД. И нельзя
исключать вариант, что подходящий антивирус установлен у подавляющего
большинства пользователей.
С другой стороны, при таком проксировании, соединение с удалённым
сервером устанавливает не браузер, а прокси антивируса. Реализация TLS в
данном прокси может содержать уязвимости. В целом, следует ожидать
добротной реализации TLS от браузера, а не от того или иного антивируса
(либо другого TLS-прокси). Дело в том, что подобное проксирование на
клиентской стороне находится в некотором противоречии уже с идеологией
протокола TLS, поэтому ситуацию в любом случае не улучшает. TLS-прокси
может не валидировать или некорректно валидировать серверные
сертификаты, соответственно, отсутствие аутентификации сервера позволит
перехватывать соединение третьей стороне. Более того, TLS-прокси
антивируса может быть ошибочно (или даже намеренно, ничего нельзя
исключать) настроен так, что в качестве сессионных используются
нестойкие ключи, которые достаточно легко вычислить, наблюдая TLS-трафик
(либо даже просто зная время соединения и параметры клиента), для этого
даже не потребуется знать секретный ключ от сертификата и активно
перехватывать соединение. При этом, браузер может быть современным, а
браузерная/системная реализация TLS – надёжной, но так как ключи для
внешней сессии генерирует проксирующий модуль антивируса, появляется
дополнительная возможность для пассивной расшифровки трафика, которая
никак от браузера не зависит.
14. September 2017, 17:06 Безопасность, Интернет, Компьютеры и ПО
Современные антивирусы нередко добавляют свой “особый” корневой
сертификат в системное хранилище или в хранилище браузера (зависит от
платформы), это делается для того, чтобы прозрачно и без предупреждений
для пользователя инспектировать трафик, защищённый TLS (обычно – HTTPS).
Антивирус проксирует соединения, генерируя в реальном времени подменные
сертификаты для TLS-серверов, которые посещает пользователь. Подменные
сертификаты подписаны от корневого сертификата антивируса. У такого
решения есть ряд неприятных, с точки зрения безопасности, побочных
эффектов. Так, при помощи ключа от этого корневого сертификата можно
перехватывать TLS-соединения не только на компьютере пользователя, но и
на других промежуточных узлах сети (при этом не обязательно, чтобы
антивирус работал – достаточно, что его корневой сертификат находится в
списке доверенных).
Естественно, антивирус должен бы при установке генерировать для
добавляемого сертификата уникальный локальный ключ. В противном случае,
всякий пользователь антивируса, который сумел извлечь ключ из своей
копии программы, получает потенциальную возможность перехватывать трафик
других пользователей. Но, во-первых, антивирус может полагать, что
сгодится и одинаковый для всех установок ключ. Во-вторых, уже
встречались ошибки (или условные “ошибки”) в реализациях аналогичных
схем, приводившие к тому, что ключ везде получался один и тот же.
В-третьих, генерировать локальный ключ можно таким способом, что, зная
дополнительную информацию, его нетрудно быстро вычислить и использовать
на перехватывающем узле.
Перехватывающему узлу, конечно, ещё необходимо определить, что у
клиента, который пытается установить TLS-соединение, встроен корневой
сертификат от данного антивируса. Дело в том, что список корневых
сертификатов системы не передаётся наружу, а попытка подмены при
неустановленном сертификате – вызовет предупреждение в браузере. Однако
перехватывающий узел может распознать антивирус подходящей версии при
помощи анализа пакетов, которыми этот антивирус обменивается с
центральными серверами разработчика. При целевой атаке – определить
антивирус можно, просто взглянув на интерфейс операционной системы. Ну,
либо сами разработчики могут посмотреть в регистрационной БД. И нельзя
исключать вариант, что подходящий антивирус установлен у подавляющего
большинства пользователей.
С другой стороны, при таком проксировании, соединение с удалённым
сервером устанавливает не браузер, а прокси антивируса. Реализация TLS в
данном прокси может содержать уязвимости. В целом, следует ожидать
добротной реализации TLS от браузера, а не от того или иного антивируса
(либо другого TLS-прокси). Дело в том, что подобное проксирование на
клиентской стороне находится в некотором противоречии уже с идеологией
протокола TLS, поэтому ситуацию в любом случае не улучшает. TLS-прокси
может не валидировать или некорректно валидировать серверные
сертификаты, соответственно, отсутствие аутентификации сервера позволит
перехватывать соединение третьей стороне. Более того, TLS-прокси
антивируса может быть ошибочно (или даже намеренно, ничего нельзя
исключать) настроен так, что в качестве сессионных используются
нестойкие ключи, которые достаточно легко вычислить, наблюдая TLS-трафик
(либо даже просто зная время соединения и параметры клиента), для этого
даже не потребуется знать секретный ключ от сертификата и активно
перехватывать соединение. При этом, браузер может быть современным, а
браузерная/системная реализация TLS – надёжной, но так как ключи для
внешней сессии генерирует проксирующий модуль антивируса, появляется
дополнительная возможность для пассивной расшифровки трафика, которая
никак от браузера не зависит.
0 new messages