Реплика: атака посредника в TLS и проблема доверия сертификатам
Процитирую заметку из 2016 года, про MITM для TLS:
Главная проблема с перехватом TLS при помощи MitM в том, что такое решение полностью уничтожает смысл аутентификации узлов на стороне клиента. Дело в том, что клиент больше не может проверять валидность сертификатов оконечного узла, с которым пытается установить соединение: клиент просто не видит этого подлинного узла и сертификатов – он обменивается данными с перехватывающим, подменным узлом и вынужден доверять ему. Если на пути от подменного узла до узла, соединение с которым перехватывается, что-то пошло не так, то обнаружить это “не так” должен перехватывающий узел. Однако, он может этого не делать: вообще, ситуация, когда перехватывающий узел просто не валидирует сертификаты перехватываемого – встречается нередко. Более того, не в интересах перехватывающего прокси заниматься такими проверками. Так, этот узел не может видеть всего контекста установления соединения (часть контекста – у клиента: например, только клиент знает, какие ключи и сертификаты он ожидает получить от сервера), а поэтому в принципе не может надёжно проверить подлинность соединения.
Уточнить, пожалуй, тут можно вот что: во-первых, если перехватывающий узел не проверяет подлинность “внешних” узлов по сертификатам (а нужно считать, что не проверяет), то этот самый узел точно так же может оказаться под атакой MITM, затянув туда и все “внутренние” узлы, которые через него работают; во-вторых, если за MITM-прокси стоит большое количество ничего не подозревающих пользователей, то для третьей стороны повышается привлекательность своего собственного MITM (см. предыдущее предложение) даже с подменными сертификатами от хорошо известного УЦ – просто потому, что такая атака будет направлена на единственный узел (на MITM-прокси) и гораздо больше шансов, что никто не заметит (при этом пользователей, которые попадут под “двойной перехват” – сразу много).
Адрес записки: https://dxdt.ru/2023/02/17/9592/
Похожие записки:
- Открытые "исходники" и "бинарный" код с точки зрения ИБ
- Разноцветные шары и "анонимизация"
- Странные особенности Golang: комментарии и ассемблер
- Токены доступа и популярная автоматизация
- "Случайные пакеты" как транспорт
- Техническое: связь SCT-меток с логами Certificate Transparency
- LLM и "решения" задач
- "Яндекс.Браузер" и российские сертификаты TLS в вебе
- Техническое: ошибки делегирования в DNS
- Chrome и УЦ Entrust
- Рандомизация регистра символов в DNS
Написать комментарий