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

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

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

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

Теория

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

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

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

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

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

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

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



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

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

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



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



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

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



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

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

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

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



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

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

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



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

Выводы

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

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

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


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