Несколько реплик про перехват TLS при помощи MitM

1.

MitM – атака “Человек посередине”. Это атака уровня аутентификации, а не “шифрования”. Смысл атаки, в случае TLS (на клиентской стороне), состоит в том, что подменяется узел, с которым клиент пытается устанавливать соединение. А для того, чтобы клиент не догадался о подмене – используется сертификат, выпущенный для имени исходного узла. История с сертификатами в основном касается как раз TLS, для других протоколов ситуация может быть иной.

2.

Возьмём для примера HTTPS (работает на базе TLS), а также браузер в качестве клиента. Если подменный сертификат для удостоверяемого узла выпущен от корневого ключа, которого браузер не знает, то браузер выдаст предупреждение системы безопасности. (К сожалению, ситуация такова, что для многих пользователей такое предупреждение означает примерно следующее: “Нажмите “Продолжить” для получения доступа к вашему любимому сайту”. Соответственно, пользователи привычно игнорируют предупреждение.) Важный момент: если соответствующий корневой ключ, в составе корневого сертификата УЦ, будет штатным образом импортирован пользователем в браузер, то никаких предупреждений браузер больше выдавать не будет. Это штатное поведение – импорт сертификатов требуется в корпоративных средах, а также в ряде других случаев (скажем, вы хотите использовать собственный УЦ для собственных сайтов). После успешного импорта, работа по HTTPS снова станет прозрачной. Но это относится только к браузерам, да и то, в случае, если они не используют каких-то дополнительных мер по отслеживанию ключей (плагины и пр.).

3.

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

4.

Тем не менее, при устройстве тотального MitM – много чего сломается: например, перестанут работать сервисы, использующие клиентскую авторизацию; возникнут проблемы с различными VPN; перестанут работать решения, которые используют привязку к конкретным открытым ключам на стороне сервера (это относится к приложениям для смартфонов, к различным клиентам онлайн-сервисов, начиная от месcенджеров, интернет-телефонии, систем телеконференций и заканчивая клиентами онлайн-игр).

5.

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

6.

Технически, выпускать подменные сертификаты может тот или иной хорошо известный УЦ, то есть, УЦ, корневые ключи которого включены в стандартный дистрибутив браузера. Однако попытка массово реализовать подобное для большого числа ничего не подозревающих пользователей – скорее всего приведёт к тому, что ключи УЦ будут отозваны из браузеров. Тем не менее, УЦ попадались на подобных штуках.

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)

Адрес записки: https://dxdt.ru/2016/09/21/8094/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 7

  • 1 <t> // 21st September 2016, 18:48 // Читатель Alex Laskin написал:

    Это все правильно, но только с технической стороны.
    С организационной — все просто. Заводится новый ГосУЦ, и все обязаны прописать его ключи к себе в списки доверенных.
    А кто не прописал, тот враг народа, госдеповская шлюха и получит двушечку.
    И оп! Все работает.

  • 2 <t> // 22nd September 2016, 11:14 // Читатель xM написал:

    Его должны будут прописать себе пользователи сами. Собственноручно. В этом заковыка.

  • 3 <t> // 23rd September 2016, 03:10 // Читатель Amir написал:

    Сможет ли гугл со своим hsts c Certificate pinning допустить клиентов с таким сертификатом к себе на сайт? Возможно, отрезано будет население от его служб.

  • 4 <t> // 23rd September 2016, 13:15 // Александр Венедюхин:

    HSTS и pinning – работают на стороне браузера, так что их можно отключить.

  • 5 <t> // 23rd September 2016, 20:42 // Читатель xM написал:

    Если не брать варианты взлома TLS “людьми из органов”, то варианта видится четыре.
    1. Вы сами ставите себе промежуточный сертификат.
    2. Его включает в набор разработчик браузера.
    3. Удостоверяющий центр генерирует для этих людей промежуточный сертификат.
    4. Владелец сертификата даёт ключ.

  • 6 <t> // 27th September 2016, 15:08 // Читатель Amir написал:

    “HSTS и pinning – работают на стороне браузера, так что их можно отключить” –
    А как быть с Chrome, который жестко прописывает в браузере сайты Google? Я не нашел в интернете методы как именно в нем отключить HSTS предупреждение к gmail, например. В firefox’е, сафари, да – есть такая возможность. Будем заходить на gmail через firefox или другой браузер, который позволит заходить на google-ие сайты и соответственно давать доступ к почте “людям из органов”.

  • 7 <t> // 27th September 2016, 19:00 // Александр Венедюхин:

    > А как быть с Chrome,

    Пока что достаточно импортировать корневой сертификат в браузер. Для цепочек валидации, которые ведут к этому импортированному сертификату, pinning не работает. HSTS – немного о другом: этот заголовок предписывает браузеру использовать только безопасное соединение (HTTPS) при последующих обращениях к данному сайту, привязку ключей HSTS не производит.