По мере роста использования HTTPS растёт желание посторонних лиц внедриться в защищённый трафик. Исследование 2017 года The Security Impact of HTTPS Interception показало, что это становится всё более распространённой практикой. Анализ трафика на серверах обновления Firefox показал, что в отдельных странах процент внедрения посторонних агентов в HTTPS достигает 15%.
Со времени исследования ситуация вряд ли улучшилась. Сейчас даже последняя модель беспроводных наушников Sennheiser требует установить в системе корневой сертификат (с небезопасными параметрами).
Чаще всего защиту компрометирует антивирус или корпоративный middlebox (см. список ниже), но бывает и хуже. В любом случае, лучше знать наверняка, когда ваш канал HTTPS на самом деле не защищён из конца в конец. Даже когда сторонняя система перехватывает трафик из лучших побуждений, она зачастую не поддерживает современные шифры или не валидирует сертификаты, таким образом снижая общую защиту соединения. А ведь перехватывать SSL-трафик могут не только в благих целях, но и в злонамеренных: например, для цензуры на государственном уровне.
Программы мониторинга HTTPS работают как прозрачные прокси, которые обрывают сессию TLS, инспектируют контент, а затем устанавливают новую сессию с сервером назначения. Они используют не такие версии TLS-библиотек, как у популярных браузеров, что позволяет обнаружить их на стороне сервера по несоответствию между HTTP User-Agent и TLS Client Hello реального браузера и прокси.
Для начала приведём некоторые практические выводы из исследования 2017 года, в котором участвовали Mozilla, Google, GlobalSign, а также академические исследователи из Мичиганского университета, Иллинойсского университета в Урбане-Шампейне и Калифорнийского университета в Беркли.
Практический вред от HTTPS-перехвата заключается в деградации шифрования и дополнительных уязвимостях «прозрачного прокси». Авторы исследования оценили по этим параметрам ряд популярных middlebox'ов. Как видим, в 2017 году почти половина из них не поддерживала современные наборы шифров, а у пяти зарегистрированы серьёзные уязвимости. Только 1 из 12 оказался способен полностью зеркалировать все пользовательские наборы шифров.
Активность антивирусов на компьютерах пользователей тоже обычно детектируется на стороне сервера. Исследование показало, что только два антивируса полностью зеркалируют пользовательские шифры, в остальных случаях происходит деградация шифрования.
Защищая от одних угроз, антивирусы снижают шифрование и добавляют собственные уязвимости. В целом установка стороннего антивируса часто значительно ухудшает общую безопасность системы. Некоторые специалисты советуют пользователям всегда удалять из системы сторонние антивирусы, потому что их инвазивный и плохо написанный код осложняет браузерам и другим программам возможность обеспечить собственную безопасность.
На пути между клиентом и сервером могут работать и другие «прозрачные прокси». Чтобы лучше детектировать этих агентов, компания Cloudflare недавно выпустила два новых инструмента:
- MITMEngine, свободная библиотека для определения HTTPS-перехвата.
- MALCOLM, приборная панель для отображения метрик о HTTPS-перехвате в сети Cloudflare.
Главный интерес представляет библиотека MITMEngine. Разработчики пишут, что взяли за образец популярный инструмент Caddy Server MITM Detection. Он поддерживает набор популярных браузеров и распознаёт HTTPS-перехват по специфическим отпечаткам сообщений TLS Client Hello и User Agent, как описано выше.
Разработчики постарались обеспечить расширяемость, упростив будущее добавление в детектор новых версий браузеров, а также улучшили производительность и расширили функциональность детектора, по сравнению с Caddy Server MITM Detection. Он анализирует следующие параметры TLS Client Hello, сравнивая реальные данные с отпечатками известных браузеров:
- версия TLS;
- наборы шифров;
- расширения и их значения;
- поддерживаемые группы эллиптических кривых;
- форматы точек эллиптической кривой.
Фактически, MITMEngine выполняет частичный фингерпринтинг пользователя без его деанонимизации, но с надёжным определением, что соединение устанавливает реальный браузер, а не посредник.
Пример работы
Предположим, MITMEngine видит следующий User Agent от пользователя:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/47.0.2526.111 Safari/537.36Этот User Agent соответствует Chrome 47 под Windows 7. Он сопровождается сообщением TLS Client Hello, которое указывает на следующие наборы шифров, в hex:
0000 c0 2b c0 2f 00 9e c0 0a c0 14 00 39 c0 09 c0 13 .+./.... ...9....
0010 00 33 00 9c 00 35 00 2f 00 0a .3...5./ ..Это сообщение соответствует таким наборам шифров:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)Дефолтные наборы шифров для Chrome 47 следующие:
0000 c0 2b c0 2f 00 9e cc 14 cc 13 c0 0a c0 14 00 39 .+./.... .......9
0010 c0 09 c0 13 00 33 00 9c 00 35 00 2f 00 0a .....3.. .5./..Если посмотреть внимательно, то можно заметить: в реальном трафике список шифров чуть короче, чем должно быть в реальном браузере. Хотя остальные расположены в том же порядке, но не хватает двух наборов:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)Можно предположить, что трафик от браузера пользователя проходит через прозрачный прокси, который не поддерживает шифры ChaCha. Это снижает защиту пользователя, поскольку в списке следующие за ChaCha наборы шифров AES-CBC уязвимы для атак типа padding oracle.
В некоторых случаях MITMEngine позволяет даже определить, какая конкретно программа вызывает деградацию HTTPS-соединения (в примере выше это антивирус Sophos). Сервер может предупредить пользователя об этой угрозе.
Комментарии (21)
LAG_LAGbI4
20.03.2019 11:19Я правильно понимаю, что если установить в систему сертификат доверенного центра сертификации, то система будет принимать все сертификаты, заверенные этим центром? А не существует ли механизма, который бы разрешал удостоверя заверение только определённых сертификатов? Ну например я у меня установлен сертификат минкомсвязи. Пусть он используется для проверки сертификата с сайта госуслуги, но не сертификата гугла.
HellKaim
20.03.2019 11:28На сколько мне известно на стороне клиента — нет. Если корневой сертификат стоит, то все его дочерние сертификаты (т.е. в рамках дерева доверия) будут автоматически верны.
Собственно, на этом и основаны прокси.
Revertis
20.03.2019 13:04Года через три до этого дойдут, думаю. Красные плашки для HTTP сайтов тоже долго внедряли, но вот, они уже есть.
Я тоже считаю, что некие «зоны ответственности» у корневых сертификатов должны быть определены. Пусть даже на уровне DNS (с новыми протоколами DOT, DOH и т.п.), можно было бы прописать некую TXT-запись, в которой указать кто ответственен за данный домен. Хотя, это не панацея, нужно придумать механизм распространения этих данных.HellKaim
20.03.2019 20:03Беда в том, что это не нужно рынку. Красная или не красная плашка это блаж и фича, ничего, по сути, не меняющая.
А вот реализация "это проверяем так, а то — эдак на стороне клиента" приведет к падению работы всей infosec какая она есть сей час.
Вообще же, если говорить серьезно, то нужно сделать, так это вернуть обратно HPKI, который как раз эту проблему и решал (как я понимаю), но был выпелен под благие лозунги. А стоило бы оставить...
LAG_LAGbI4
20.03.2019 20:20Что такое HPKI?
HellKaim
20.03.2019 20:26+1Ошибочка вышла, HPKP
funca
20.03.2019 21:29+1Оно создавало больше проблем, чем решало. При смене сертификата сайт становится недоступным и теряет посетителей.
В браузерах есть нормальные схемы с использованием pki, кому нужна безопасность.
HellKaim
20.03.2019 21:31Слушайте: всегда можно было добавить несколько сигнатур.
Хотя, 2bh, это не решает проблемы "левого" сертификата от слова совсем.
khanid
21.03.2019 11:22Система — да, а вот браузеры — нет. У них свой набор сертификатов доверенных CA. По этой причине пытались в своё время казахские CA пропихнуть в CA на FF. В комментариях возник человек, который пояснил, что это из-за попытки контроля через MitM на госуровне, после чего запрос свернули.
amarao
Мне кажется, что это ошибка дизайна SSL/TLS. Там с самого начала надо было закладывать поддержку третьей стороны с явным согласием на это пользователя.
powerman
Нельзя такое делать на транспортном уровне — согласие это просто один бит да/нет, его слишком легко подделать, скрыть, получить от пользователя обманом, или вообще игнорировать. Про этот принцип уже немало писали: нельзя сделать софт, который позволил бы прослушивать трафик террористов и педофилов, но при этом не дал бы возможности прослушивать вообще всех подряд.
Если пользователь хочет дать доступ к своему трафику — этот доступ необходимо реализовывать непосредственно на одном из концов шифрованного соединения (напр. в браузере пользователя). Нет ничего плохого в том, чтобы браузер предоставлял API для антивирусов и прочих инструментов, которые пользователь должен сначала установить на свой комп, и потом открыть им доступ к конкретному браузеру — вот это будет вполне приемлемой формой получения согласия пользователя слушать его трафик.
В корпоративной среде установку/подключение таких инструментов можно автоматизировать, а инструмент на компах юзеров вполне может быть тонким агентом, который прогоняет трафик для анализа через централизованный сервис компании.
Собственно, такие API уже есть: браузерные плагины имеют доступ к трафику, плюс имеют возможность коммуникации с локально установленными приложениями.
amarao
Немного не так. Надо было предусмотреть, что в браузере может быть установлен сертификат от MitM'а. Нет сертификата — нет доверия. MitM осуществляется использованием общего ключа для передачи, при этом клиенту предъявляют сертификат и подпись данных оригинального сайта (т.е. MitM'у не надо CA, который может что угодно подписывать), и, возможно, подпись от MitM'а, который контент разрешает.
Т.е. браузер должен давать явное согласие на участие mitm'а (и сервер с своей стороны тоже). Никакого wiretapping, просто участие third party.
powerman
Что значит "общего ключа для передачи"? Насколько этот общий ключ вычисляется с поддержкой адекватных алгоритмов, насколько поддерживает forward secrecy, etc. — т.е. насколько использование такого MITM сделает коммуникацию более уязвимой по сравнению с вариантом без MITM? Учитывая среднее качество таких инструментов, хорошо описанное в данной статье — это явно плохая идея. Канал сайт-браузер должен быть защищён. А что там пользователь добровольно делает с полученными браузером данными — кому их передаёт и как при этом шифрует — это уже его личное дело.
amarao
Тот же PFS прекрасно реализуется и тремя сторонами. Я говорю о том, что практическое применение SSL показало, что модель Алиса/Боб/Ева ему не соответствует. Вместо того, чтобы городить костыли в стиле «самопальный CA, подписывающий всё подряд» правильнее было бы признать существование (кто там по очереди? Клэр?), которая имеет разрешение от Алисы участвовать в процессе и согласовывает ключ наравне с Алисой и Бобом. В этой ситуации Алиса может проверить сертификат Боба (напоминаю, если Клэр выпускает свой сертификат для Боба, то Алиса не знает какой был сертификат у Боба), а Клэр может спокойно инспектировать трафик.
Разрешит Алиса участвовать Клэр в этом процессе или нет — вопрос настроек браузера Алисы.
А мой комментарий был, что модель SSL не соответствует его применению в энтерпрайзе. И это порождает хаки, которые значительно хуже, чем признание наличия Клэр в протоколе.
powerman
Да, не соответствует. Да, порождает. Нет, признавать этот факт и менять протокол всё-равно плохая идея, и мой комментарий был о том, почему это плохая идея: мы не сможем гарантировать, что никто кроме уважаемой в нашей компании Клэр не использует эту
дырувозможность протокола без нашего ведома. В текущем виде протокол, по крайней мере, очень старается исключить MITM либо сделать его применение очень неудобным и/или заметным. Если протокол будет допускать "доверенный MITM", то отличать доверенный от недоверенного и контролировать наличие MITM в принципе станет намного сложнее.amarao
Мне кажется, что довольно просто. Достаточно, чтобы браузер явно давал контроль за этим и явно показывал всех участников.
Согласитесь, что ткнуть в адресную строку и посмотреть «кто именно ещё участвует» куда удобнее, чем сидеть с strace'ом/tcpdump'ом и вылавливать кто там что кому подменяет.
А административные вопросы как раз станут лучше. Сейчас есть разумная причина для CA, который подписывает что попало. Если mitm станет официальной частью, это причина исчезнет, и любой CA, который подписывает чужие сервера, станет очевидным злоумышленником.
Насчёт гэбни — это не сделает их жизнь легче. Браузер предоставляет возможность не доверять третьей стороне. (Гэбня может за это не пускать трафик, но это уже другой вопрос — сейчас они с тем же успехом могут резать чужой SSL).
Ghool
Так сейчас проверяется просто — смотрится, что за сертификат подписал трафик.
Зачем tcpdump?
Ghool
В хроме, кстати, доступ к просмотру сертификата закопали в консоль отладки, за что им моё большое фи.
В мозилле и хроме в начале урля замочек, тыкнув по которому можно смотреть и сертификат, и всю цепочку сертификатов
shifttstas
Неплохой вариант: что бы это разрешать по идее должен быть только 1 метод — доменные политики, и при установке такой политики в MITM:true — в заголовке хрома указывать:
«Ваш сетевой администратор имеет полный доступ к вашему трафику»
Если продолжить идею — такой заголовок надо бы передавать веб-серверам, т.к возможно не все сайты согласятся давать трубу, которая доступна третьей стороне.
amarao
Да. Надо сказать, что со стороны сервера тоже могло бы быть больше одного участника. Reverse proxy (типа cloudflare) мог бы тоже легально участвовать в процессе не получая доступ к сертификатам клиента.
Соединение (полный вариант с всеми возможными опциями) выглядело бы так:
Пользователь: Сертификат выписан CA-таким-то.
Proxy пользователя: сертификат подписан тем-то, разрешение на участие в соединении выдано (согласие пользователя/настройки браузера/доменная политика/etc)
Proxy сервера: сертификат cloudflare, подписанный сертификатом сервера example.com
Example.com: сертификат от Let's Encrypt.
Всё понятно, ясно, у пользователя есть возможность видеть всех их, видеть почему каждый из них в процессе участвует, возможность забанить любого из (возможно/нет — это уже локальные настройки браузера).
Вместо этого у нас супердырявые MITM'ы, которые скрывают от пользователя оригинальные сертификаты.