Хабрахабр

Слабости HTTPS. Часть 2

Любая система имеет свои слабые и сильные стороны. Первая часть о слабостях HTTPS вызвала неоднозначную реакцию, что «это не слабости, так было задумано». В первой части говорилось:

  1. О невозможности обеспечить полную конфиденциальность и privacy пользователям (все ещё можно отслеживать и банить ресурсы, которые человек посещает)
  2. О том, что сертификаты передаются по открытому каналу и содержат чаще больше информации, чем текущий ресурс (например, сертификат bing.com содержит информацию о 72 дополнительных ресурсах, включая дев, тест, бета среды)

Продолжу называть это «слабостями» дизайна. В этой статье поговорим о ещё одной слабой стороне — централизованности.

Поэтому говоря о слабости, мы будем иметь ввиду централизованность SSL протокола. HTTPS базируется на SSL и TLS протоколах (для простоты будем называть просто SSL – хотя SSL и TLS работают на разных уровнях OSI стека).

Теория

Начать стоит с теории протоколов шифрования. Проблема современной криптографии состоит не в самом шифровании, а в том, что делать с ключами: как их хранить, передавать, создавать и уничтожать безопасно.

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

Быстрое и эффективное шифрование – это прерогатива симметричных алгоритмов, которые используют один и тот же ключ как для шифровки, так и для дешифровки. Основной функцией ассиметричного шифрования является аутентификация, отнюдь не шифрование – это достаточно ресурсоемкая и дорогая операция для данного алгоритма.

Публичный ключ доступен всем. Один из ключей остаётся всегда у одной стороны для подтверждения его идентификации, его называют приватным.

В будущем уже и ключи другого размера, и алгоритмы более строгие, и способности головного мозга несоразмерны с современным, но подход, предположим, остается тем же. Представим, что есть деревня будущего, в которой живут Борис и Аня.

Борис и Аня хотят конфиденциальности своей любовной переписки, поэтому главное для них это безопасный обмен информацией.

Аня генерирует две пары ключей ассиметричного шифрования – приватный Pr1 и публичный P1. В самом простом случае Борис посылает Анне сообщение: «давай общаться». Борис генерирует симметричный ключ S1, шифрует его публичным ключом Ани P1(S1). «Давай», — говорит Аня, — «Я Аня, вот мой публичный ключ, вот алгоритм симметричного шифрования, который я знаю». В конце концов у Бориса и Ани появляется симметричный сессионный ключ для того, чтобы «обеспечить» надёжную передачу писем друг другу и не дать родителям читать их переписку. Теперь S1 не сможет расшифровать даже сам Борис, потому что расшифровать сообщение может только Аня своим приватным ключом.

image

С двухсторонней – Борис генерирует свою пару ключей и передает публичный ключ Ане. Я специально сильно не редуцировал этот обмен сообщениями, по сути мы описали SSL Handshake с односторонней аутентификацией [1].

Из трех основных функций SSL протокола (аутентификация, шифрование, обеспечение целостности), наиболее важным является именно аутентификация. Важный вывод, который мы уже можем сделать.

Между Борисом и Аней встает вопрос, как гарантировать теперь, что почтальон не сможет прочитать их сообщения. Все нормально, пока не появляется почтальон, обиженный на жизнь, который падок читать чужие письма, вдобавок ещё и умный. Почтальон может сгенерировать свою пару ключей, выставить Борису свой ключ «якобы» от Ани, организовать два шифрованных канала и спокойно читать письма. Ответ – никак.

image

Представим, что в деревне появляется некий сельсовет, который ведет регистр публичных ключей жителей. Решить дилемму может только наличие некой третьей стороны, которая сможет гарантировать, что P1 ключ принадлежит Ане. Борис, когда получит P1 от Ани, может сходить в тот же сельсовет и проверить регистр. Аня может взять свой паспорт, свой публичный ключ P1, прийти туда и попросить зарегистрировать. Но проблема пока решится. Если ключ не совпадает, можно начинать грешить на почтальона и обвинять его во всех тяжких, хотя тот может уйти в отказ.

image

Поэтому ту же аутентификацию можно провести и с самим сельсоветом. Не камильфо, конечно, Борису таскаться каждый раз в сельсовет. Когда приходит Аня с паспортом и своим публичным ключом, CA выдает что-то наподобие карточки, в которой указано, что это Аня, ей принадлежит публичный ключ P1, ещё какая-нибудь информация, вплоть до номера паспорта, и добавляет ещё одно поле для своей подписи: берет всю информацию из карточки, снимает с нее хеш, и шифрует его своим приватным ключом, и называет это цифровой подписью. Сельсовет теперь называет себя Certification Authority (CA) и имеет свою пару ключей P10 и Pr10. И CA называет теперь эту карточку сертификатом. Можно было бы и без хеша обойтись, но тогда подпись была был слишком большой.

Борису надо будет только один раз сходить в сельсовет, и попросить у них их публичный ключ. Теперь Аня для обмена любовными сообщениями с Борисом передает ему не просто свое имя и публичный ключ, а свой сертификат. Почтальон вообще не знает, что ему делать, его накрывает экзистенциальный вакуум, ему остается только одно – попробовать подобрать приватный ключ сельсовета, чтобы жизнь вернулась на круги своя. Любая информация, которую сможет расшифровать этот ключ, будет априори считаться информацией, зашифрованной сельсоветом.

image

У Бориса появляется ещё одна подруга в соседней деревне, потом ещё одна. Но жизнь не стоит на месте. Затем это обретает национальный и наднациональный масштаб. Ему приходится добавлять ключи других сельсоветов себе в доверенные, начинает вести свой реестр с публичными ключами центров сертификации. Появляются корневые центры сертификации (Root Certification Authority), которые не подписывают сертификаты простых смертных, а подписывают только сертификаты промежуточных центров (Intermediate Certification Authority) после их проверки. Организаций, которые подписывают сертификаты становится так много, что они начинают объединяться в иерархию. А от Ани он получает уже не один её сертификат, но и сертификаты промежуточных центров, чтобы далее по цепочке их проверить до корневого центра. Борису достаточно теперь хранить только публичные ключи рутовых сертификатов.

image

Проблемное поле

Система усложняется и централизуется, и с этого момента у почтальона снова появляется шанс.

С другой стороны, ему сложно уже следить каждый раз за всей цепочкой сертификационных центров. С одной стороны, у Бориса изначально небольшой список корневых центров сертификации (Windows прописывает около 50 корневых центров сертификации ещё при установке). Он доверяет своему списку корневых центров на 99. Скорее всего он уже не будет проверять, что в сертификате Ани из его же деревни почему-то указан сертификационный центр другой страны. Почтальон может пойти по самому брутальному пути, и каким-то образом (социальная инженерия, взлом с проникновением) прописать свой фейковый корневой центр сертификации в реестр Бориса. 9 процентов.

image

Для проведения тестирования на проникновение и использования этого подхода мой любимый инструмент ZapProxy (бесплатный и опенсорсный), который сгенерирует сертификат корневого центра (его необходимо будет вручную установить), а затем на лету подменяет настоящий сертификат на «похожий». PS. Этот способ добавления фейкового сертификата корневого центра активно используется как пентестерами (вроде меня), так и злоумышленниками. Поэтому, если в вашей системе валидация не дублируется на сервере, то у вас определённо проблемы. Это позволяет не только просматривать трафик, но и останавливать его, менять и отправлять дальше.

Аня деньги заплатила, и хотела бы, чтобы Борис все-таки распознал её. PPS. Вторая проблема, которая поднялась в этом кейсе, касается Ани и указания в её сертификате непонятного центра. Это особенно имеет смысл для приложений с высоким уровнем риска. Эта проблема решается использованием SSL Pinning [3], когда в приложение можно прописать доверие только определённому сертификату и определенным центрам сертификации. Ради эксперимента я поставил фейковый сертификат себе на Андроид, указал, чтобы трафик шёл через ZapProxy, который торчит в сети на моей машине, и посмотрел сколько приложений используют этот механизм. С браузерами это сложнее, для мобильных приложений, которые работают с одним-двумя сервисами, попроще. Практически никто, я смог посмотреть и поиграться с подменой трафика практически со всеми популярными приложениями.

Правительство не могло не оценить его рвение и наделило статусом секретного агента с более высокими полномочиями. Итак, вернемся к нашему почтальону. Он нашёл более простой путь. Хотя приватные ключи корневых центров сертификации хранятся под семью замками, самовыгораемыми дисками, многоуровневой защитой – даже полномочий почтальона может не хватить договориться с ними, чтобы они предоставили ему свой приватный ключ, чтобы на лету генерировать фейковые валидные сертификаты (хотя всё возможно). Теперь он может слушать трафик не только Бориса, но в принципе любого субъекта. Он идет в свой же сельсовет, который в иерархии центров сертификации на самом нижнем уровне, и надавливает или подкупает сельсовет, чтобы тот подписал его сертификат, как сертификат промежуточного центра сертификации. Человек скорее всего даже не заметит ничего, браузер никаких предупреждений не выдаст.

image

При обнаружении подобных фейковых сертификатов, скомпрометированных промежуточных и корневых центров, эти сертификаты нужно пометить как отозванные и скомпрометированные (Revoked Certificates). Это известная проблема, и с нею человечество тоже пытается бороться. Когда мы начали активно работать над контролем OUTPUT трафика с помощью Dhound [5], мы заметили периодические запросы на 80 порт. Это значит, что Борису помимо хранения корневых сертификатов ещё нужно их постоянно синхронизировать с онлайн списком отозванных сертификатов – этот механизм реализуется через CRL (certificate revocation list) и Online Certificate Status Protocol (OCSP) протоколы [4], которые, кстати говоря, работают по незащищённому каналу. Проблема с отозванными сертификатами состоит в том, что их уже огромное количество: на 2013 год насчитывалось около 3 миллионов отозванных сертификатов [6], 23000 отозванных Symantec сертификатов только в 2018 [7]. Если банить подобные запросы на уровне firewall-а, то некоторые функции перестают работать – например, отсылка почты. Получается, что если нашего почтальона и обнаружат, то процесс дальнейшего предотвращения его действий будет долгим и не всегда успешным. Chrome отключил по умолчанию функцию полноценной проверки отозванных сертификатов несколько лет назад [8], чтобы увеличить скорость загрузки страниц.

Выводы

Современная система SSL является частично закрытой и централизованной, что определённо является одной из её слабых сторон. Пока она является таковой, всегда будет соблазн «сильных мира сего» получить от нее свои выгоды, не ставя в приоритет личную конфиденциальность пользователей. Все ещё будут создаваться собственные алгоритмы шифрования на национальном уровне, в попытке отгородить другие страны от собственных граждан, и делать это самим. Компрометация ключевых узлов способна обрушить всю систему в целом. Увеличивающаяся энтропия и сложность системы будут все более приводить её в нестабильное состояния и в конце концов к смерти системы.

Переход от закрытой и централизованной SSL системы к более прозрачной и распределённой, которая не способна будет по своей природе давать преимущества какой-либо из сторон. Какой возможен выход? Возможно, это будет решение чем-то похожее на то, что реализует открытый blockchain.

SSL протокол имеет более сложные нюансы, которые не были затронуты в статье. PS. Есть ли ещё слабые стороны? Но уровень информации был достаточен, чтобы раскрыть одну из его слабостей. В следующих статьях посмотрим.

Ссылки

Автор — Денис Колошко, CISSP

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть