Вверх

Реклама

Статистика

Яндекс.Метрика

Кто на сайте

Сейчас 157 гостей и ни одного зарегистрированного пользователя на сайте

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

slabosti protokola https

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

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


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

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

Теория


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

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

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

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

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

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

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

6b9e67314d1d8ff276cdac79d259c73b

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

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

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

Слабости HTTPS

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

Слабости HTTPS

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

99f55f30dcb8fffcafb5f23a5c318596

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


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

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

649a3f3579c7f587bd7bf5990be4608c

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

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

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

958fb1abd619e6f93d8ee7ad12162f0b

Это известная проблема, и с нею человечество тоже пытается бороться. При обнаружении подобных фейковых сертификатов, скомпрометированных промежуточных и корневых центров, эти сертификаты нужно пометить как отозванные и скомпрометированные (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

 

Популярные видеобзоры

Сравнение SSD дисков для десктопа и сервера

ССД диски домашнего и корпоративного уровняВ данном обзоре мы попытались сравнить устройства - SSD твердотельные жесткие диски домашнего и корпоративного уровня, указали их особенности, достоинства и недостатки.

Подробнее...

Обзор League of Legends PowerBank

HP 12ac150ur

На сколько бесплатным бывает сыр в мышеловке? Сейчас в интернете можно найти огромное количество одних и тех же устройств по совершенно разным ценам, от бросовых до заоблачных. Есть даже возможность получить те или иные устройства совершенно бесплатно участвуя во всевозможных рекламных конкурсах и акциях. Как раз о там на сколько вкусным бывает бесплатный сыр мы и хотим рассказать.

Подробнее...

Заказ обратного звонка

Перезвоним через 30 секунд.