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

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

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

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

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

    Теория


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

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

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

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

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

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

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

    image

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

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

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

    image

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

    image

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

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

    image

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

    image

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


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

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

    image

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

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

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

    image

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

    Ну. И что?
    Реклама
    Комментарии 23
    • +3

      В предыдущей статье было обещание рассказать "что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации)."
      Это и есть обещанный фрагмент или в следующий раз будет гораздо более интересный вариант?


      Вариант с внедрением корневого сертификата, если верить хабру, уже даже на государственном уровне встречался, так что на данный момент всё упомянутое не сильно новость.


      Есть какие-то более интересные варианты, не требующие в атакуемую систему ставить доверенный сертификат?

      • 0

        Приходится констатировать, что и https-у на ГОСТ-алгоритмах тоже присущи все эти проблемы.

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


          Извините, но никакого «наоборот» нет. Закрытым ключом нельзя ничего зашифровать, публичным невозможно расшифровать что-либо.
          Закрытым ключом можно подписать, а открытым — проверить подпись, но это не тождественно шифрованию/расшифровке в общем случае.
          • 0

            Можно зашифровать открытым, а расшифровать закрытым. Другой вопрос, что это ресурсоемко, и поэтому предпочтительнее временный симметричный ключ.

            • –4
              Можно. Моя претензия к той части где «и наоборот». Наоборот (зашифровать закрытым и расшифровать открытым) — нельзя. Более, того EdDSA или ECDSA, например, вообще не поддерживают шифрование. Только подпись/проверку подписи.

              Вообще, пора бы уже отходить от заблуждения что «асимметричная криптография» == RSA. Потому что в каждой первой научно-популярной статье о криптографии особенности работы RSA выдают за особенности работы публичной криптографии вообще.
              • +6
                В ассиметричном шировании есть такое понятие как trapdoor permutation, которое означает:
                1. Если сообщение зашифровано публичным ключом, его можно расшировать приватным
                2. Если сообщение зашифровано приватным ключом, его можно расшировать публичным

                С математической точки зрения соотношение это возможно — например, для RSA ключи связаны по формуле 1=E*D(mod phi(N)). Поэтому без разницы какой ключ берётся для шифрования.

                Но приватный и публичный ключи не взаимозаменямы по своей природе. Если брать все тот же RSA, публичный ключ даже по размеру меньше приватного, потому что приватный включает дополнительные математические переменные. И рассчитываются ключи математически по разному.

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

                По поводу второго вопроса. Действительно не стоит ассоциировать ассиметричное шифрование только с RSA. Ниже пару примеров популярных алгоритмов, и для каких задач они предназначены:
                • RSA: Encryption, Digital Signature, Key Distribution
                • ECC: Encryption, Digital Signature, Key Distribution
                • Diffie-Hellman: Key Distribution
                • EI Gamal: Encryption, Digital Signature, Key Distribution
                • DSA: Digital Signature
                • Knapsack: Encryption, Digital Signature, Key Distribution


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

                В целом говоря, первый ассиметричный алгоритм Diffie-Hellman был придуман людьми Whitfield Diffie и Martin Hellman, которые первыми попытались решить вопрос безопасного обмена симметричного ключа. Подход, описанный в статье, стоило бы отнести в первую очередь к ним. Алгоритмы усложняются и меняются, но базовые методологические основы остаются теми же.
                • +1
                  По сути, подпись — это шифрование хэша подписываемых данных закрытым ключом, а проверка подписи — расшифровка открытым ключом и сравнение. Поэтому осторожно замечу, что Вы глубоко заблуждаетесь

                  Ps если в других алгоритмах принцип другой, то это повод для когнитивного диссонанса. Как тогда происходит подписывание и проверка?
                  • 0
                    Простите, я говорил в контексте SSL, а именно о HMAC алгоритме, который он использует, с высчитыванием хеша и затем его шифрованием.
                    Есть другие алгоритмы, например:
                    CBC-MAC — когда сообщение шифруется симметричным ключом, затем берется последний блок, который и будет являтся подписью
                    СМАС — это аналог CBC-MAC, только с более сложной математикой и математическими функциями
                    • 0
                      Небольшой комментарий добавлю.
                      C HMAC тоже не все так просто. Чтобы во время передачи сообщений гарантировать целостность, и чтобы одно и тоже сообщение не получило одинаковую цифровую подпись — алгоритм немного усложняется: к сообщению добавляется что-то вроде сальта или ключа, затем все это прогоняется через хеширование и затем криптуется.
              • 0

                Ваше утверждение истинно в общем виде. Однако конкретно для RSA при подписи хеш шифруется приватным ключом, а при проверке расшифровывется публичным. https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Signing_messages
                Для других алгоритмов это не так.

                • +1
                  Раз уж мы говорим о подписи, то в RSA хеш «расшифровывается» приватным ключом. И «шифруется» для проверки подписи. Посмотрите на применяемое для подписи криптопреобразование и сравните его с криптопреобразованием при расшифровке. RSAEP полностью идентичен RSAVP1, а RSADP — RSASP1.

                  Конечно, если углубиться еще дальше, то окажется что по сути все четыре операции, это — одно и то же возведение в степень. Но тем не менее…

                  Кстати, по вашей ссылке написано точно то же самое:

                  Suppose Alice wishes to send a signed message to Bob. She can use her own private key to do so. She produces a hash value of the message, raises it to the power of d (modulo n) (as she does when decrypting a message), and attaches it as a «signature» to the message. When Bob receives the signed message, he uses the same hash algorithm in conjunction with Alice's public key. He raises the signature to the power of e (modulo n) (as he does when encrypting a message), and compares the resulting hash value with the message's actual hash value
              • 0

                Какое-то время назад мне надо было для отладки расшифровать трафик между моим клиентом и моим сервером.
                У меня был полный контроль над окружением, у меня были все ключи и у меня был дамп трафика в формате pcap. И… я не смог расшифровать этот дамп — ни один гайд на эту тему не сработал.

                • 0

                  Chrome, Firefox можно попросить сессионные ключи сохранять. Повозился, но получилось, в этом случае Wireshark вполне успешно всё декодировал.

                  • 0

                    HTTPS это не всегда браузер.
                    Посыл статьи я понял как "всё просто, бах-трах, ключи стырил, сертификат подменил и вуаля" и тут не предусматривается, что почтальон будет просить Бориса и Анну "А повторите ка сеанс общения, только включите сохранение сессионных ключей"

                    • 0
                      Почтальон может не просто читать письма (слушать трафик), но и подменять их. А вы этого не сделали, вы просто записали трафик.
                  • 0
                    Все ключи — это включая сессионные или только закрытые? Во втором случае скорее всего дело в алгоритме Диффи — Хеллмана и предоставляемой им perfect forward secrecy.
                    • 0

                      У меня был полный дамп трафика и сертификат и ключ сервера

                  • +2
                    Если нужно отладить лайв HTTPS трафик (а не постфактум), то нужно на уровень выше забраться по OSI стеку и организовать MITM с двумя криптоваными каналами. Это практически все проксики умеют. Я обычно пользуюсь ZapProxy (бесплатный) или Burp (платный). Главное, рутовый сертификат вручную поставить на клиентскую машину, чтобы браузеры или софт смогли доверять подложенному сертификату.
                    • 0
                      Аня генерирует две пары ключей ассиметричного шифрования – приватный Pr1 и публичный P1.

                      А может одну пару?
                      • 0
                        Спасибо. Конечно, одну пару.
                      • 0

                        Как я люблю такие заявления:


                        каким-то образом (социальная инженерия, взлом с проникновением) прописать свой фейковый корневой центр сертификации в реестр Бориса.

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


                        Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.

                        • 0

                          Здесь описывалась общая проблема централизованного SSL, а не "как взломать соседа".

                          • 0

                            Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
                            Уже много раз встречал подобные заявления и каждый раз умиляюсь.
                            Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое