dxdt.blog: занимательный интернет-журнал

Процитирую заметку из 2016 года, про MITM для TLS:

Главная проблема с перехватом TLS при помощи MitM в том, что такое решение полностью уничтожает смысл аутентификации узлов на стороне клиента. Дело в том, что клиент больше не может проверять валидность сертификатов оконечного узла, с которым пытается установить соединение: клиент просто не видит этого подлинного узла и сертификатов – он обменивается данными с перехватывающим, подменным узлом и вынужден доверять ему. Если на пути от подменного узла до узла, соединение с которым перехватывается, что-то пошло не так, то обнаружить это “не так” должен перехватывающий узел. Однако, он может этого не делать: вообще, ситуация, когда перехватывающий узел просто не валидирует сертификаты перехватываемого – встречается нередко. Более того, не в интересах перехватывающего прокси заниматься такими проверками. Так, этот узел не может видеть всего контекста установления соединения (часть контекста – у клиента: например, только клиент знает, какие ключи и сертификаты он ожидает получить от сервера), а поэтому в принципе не может надёжно проверить подлинность соединения.

Уточнить, пожалуй, тут можно вот что: во-первых, если перехватывающий узел не проверяет подлинность “внешних” узлов по сертификатам (а нужно считать, что не проверяет), то этот самый узел точно так же может оказаться под атакой MITM, затянув туда и все “внутренние” узлы, которые через него работают; во-вторых, если за MITM-прокси стоит большое количество ничего не подозревающих пользователей, то для третьей стороны повышается привлекательность своего собственного MITM (см. предыдущее предложение) даже с подменными сертификатами от хорошо известного УЦ – просто потому, что такая атака будет направлена на единственный узел (на MITM-прокси) и гораздо больше шансов, что никто не заметит (при этом пользователей, которые попадут под “двойной перехват” – сразу много).

Адрес записки: https://dxdt.blog/2023/02/17/9592/