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

    Иногда технически неподготовленные люди продавая IT услугу либо продукт, на вопрос «а как насчёт надёжности вашей системы?» отвечают: «У нас всё защищено по https». Если с другой стороны такой же технически неподготовленный человек, то вопрос автоматически закрывается, и все остались довольны уровнем безопасности. Сам неоднократно был свидетелем подобного разговора. Было смешно.

    HTTPS активно продвигается Интернет сообществом и основная идея перевести весь Интернет к определённому году на шифрованный трафик, благо современные машины это позволяют. HTTPS — это всегда хорошо. Но нужно знать и подводные камни связанные с ним.
    Задача данной статьи — показать возможность слушать HTTPS трафик пользователя (назовём его Степан), и чтобы он этого не заметил.

    Мы не будет брать последние исследования и эксплоиты в области взлома HTTPS. Пойдём лучше к основам и рассмотрим давно известные и простые способы.

    HTTPS — это HTTP + SSL. Http — это открытый протокол передачи данных, открытый означает, что данные передаются в открытом виде. SSL — это протокол, обеспечивающий безопасное соединение посредством шифрования. То есть, наша задача состоит именно в том, чтобы перехватить чистый трафик нашего Степана и вывести его на чистую воду, какие же ХХХ сайты он смотрит по вечерам. Но мы ведь не как наш Степан и не смотрим XXX, поэтому для примера возьмём поисковик bing, который пока ещё может работать как по https, так и по http.

    Ниже на картинке пример как выглядит перехваченный трафик при помощи WireShark на один и тот же запрос в bing для HTTP и для HTTPS.

    image

    image

    HTTPS действительно криптует все данные включая урл-адреса, которые генерирует клиент. Но HTTPS построен на базе TCP/IP, то есть, информацию о том, куда направляется трафик, можно получить в незашифрованном виде. Мы говорим о Mac-адресах, IP адресах и портах.

    image

    С помощью онлайн инструментов (например, whois.domaintools.com) можно узнать, что это за IP адрес, кому принадлежит, а простым запросом в bing можно узнать, какие сайты крутятся на этом IP адресе (например, www.bing.com/search?q=ip:204.79.197.200).

    Продолжим и подумаем вот о чём. Веб-сервер может хостить несколько сайтов, и у каждого может быть свой SSL сертификат. Следовательно, наличие просто IP адреса является недостаточным. Веб-сервер, когда к нему приходит первый запрос, должен знать, с каким именно сайтом необходимо установить соединение. Шифрования ещё нет, потому что его ещё необходимо установить. Значит, ещё до начала шифрования клиент должен передать каким-то образом информацию о домене сайта, чтобы веб-сервер мог зароутить клиентский запрос на необходимый ресурс. Следовательно, необходимо посмотреть на самый первый запрос от клиента на сервер, который инициирует начало самого шифрования. Снова возьмём наш любимый WireShark и посмотрим.

    image

    image

    Здесь мы можем найти кое-что интересное:

    1. Первый запрос действительно содержит доменное имя сайта в незашифрованном виде, с которым будет инициироваться HTTPS соединение
    2. Второй запрос возвращает сам сертификат в незашированном виде на клиента, который содержит информацию, для какого домена он выдан. В случае с bing, сертификат ещё включает и расширенное поле Subject Alternative Name, в котором перечисляются домены, для которого сертификат может быть использован (в Bing сертификате можно найти даже адреса на staging среду).

    HTTP проксики типа Fiddler-а (на рисунке выше) уже умеют делать экстракт этой информации из трафика.

    Казалось бы всё, но есть ещё один способ узнать, не прибегая к взлому HTTPS, на какие ресурсы ходил Степан. Когда в браузере он набирает адрес сайта, то первый запрос идёт не на сервер, гда сайт находится, первый запрос идёт на DNS сервер, чтобы получить IP адрес для данного домена. DNS запросы не шифруются, поэтому только слушая DNS трафик, можно составить историю, какие ресурсы Степан посещал, и по IP адресу DNS сервера можно определить даже, где он приблизительно находился в это время.

    image

    Самое время подвести результаты:

    1. Не взламывая трафик мы всё-таки можем отследить какие ХХХ ресурсы (защищённые либо нет) наш Степан посещает вечерком.
    2. Можно написать скрипт для фильтрации и ведения полной истории, что Степан посещал, скажем, за последний год (мы не сможем сказать, что он там делал, но с определённостью можно сказать, что он там точно был).
    3. Если у меня есть непосредственный доступ к трафику (я — админ, который контролирует роутинг, или я — интернет провайдер, через который течёт трафик), то мне даже нет необходимости делать какие-либо действия на клиентской машине, чтобы направить трафик на меня.
    4. Wi-Fi или спутниковый Интернет может быть слабо защищён, и, зная адрес клиента, можно определить с какими ресурсами он работает.
    5. И самое главное. Степан так ничего и не заметил, а мы уже потихоньку собираем о нём информацию.

    Но нам всё-таки мало знать, что и когда посещал наш Степан. Наша задача узнать, что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации). Продолжение следует во второй части.

    Денис Колошко, CISSP
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 35
      +11
      Это прекрасно когда люди открывают для себя wireshark :)
        0

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

          +3
          Представляю глаза игрока, если там текстовый протокол без шифрования
            0

            Сейчас модно все пускать по HTTPS, как уже было сказано в статье — считается что это достаточно. Это действительно достаточно от MITM, но совершенно не мешает игроку с Fiddler'ом. Я раньше для развлечения писал ботов для многих таких игрушек (обычно мобильные или браузерные), делалось все элементарно

          0

          Еще немного, и узнают про SNI :)

          +1
          А разве ssl c 2015-го не tls?
            –2
            нет. TLS это новая версия SSL протоколов. старые версии SSL протокола всё еще поддерживаются, хотя это будет выстрел себе в ногу. некоторые пользователи в первую очередь обращают внимание на то, какие версии SSL и TLS запрещены для использования.
              +2
              Простите, а кто в здравом уме будет включать эти старые версии SSL у себя на сервере?
              0
              Пораньше вроде, TLS1.0 вышел «первый раз» аж в 1999м. А вот то, что SNI пока ещё ходят открытым текстом — это факт (TLS1.3 это намеревается исправить).
              +18

              я что-то не припомню чтоб кто-то говорил что HTTPS прячет факт обмена данными...

                –4
                Особенно напрягает, что судя по последним тенденциям браузеры скоро простой http вообще поддерживать не будут, что сильно увеличит порог входа для новичков и снизит устойчивость сайтов (если сайт на https, его нельзя один раз настроить и забыть на 10 лет, а нужно постоянно контролировать, что там происходит с сертификатами).
                Повторяется ситуация с электронной почтой. Если лет 15 назад почтовый сервер можно было поднять без особых проблем, то сейчас настроить почтовик, который мог бы успешно отправлять почту на тот же gmail, это чрезвычайно сложная задача.
                  0

                  А что там надо контролировать с сертификатами? Let's Encrypt, certbot… и что там контролировать… тем более уже сейчас хостинги это делают бесплатно и быстро, нужна только заявка от пользователя.

                    0
                    Уже сейчас существуют плагины для систем управления сайтами, которые все автоматизируют в несколько кликов. Просто ставите галочку «включить https сайт, переводить трафик с http на https, включить HSTS, сертификат Let's Encrypt» — и все, сайт работает на https.
                    В чем сложность?
                    Если нужно Let's Encrypt не используя панель — консольная команда не намного сложнее.
                    Так что все стало наоборот проще и дешевле.
                      +2

                      Представьте картину — Let's Encrypt внезапно изменяет порядок получения сертификатов. Или вообще перестает выдавать сертификаты, или вдруг какой-нибудь хром перестанет доверять сертификатам от Let's Encrypt.
                      В свете некоторых новостей это все не выглядит таким уж и невозможным.

                        0
                        Автоскрипт поменяет сам себя и продолжит писать в неизменившуюся конфигурацию сервера? Автоскрипт ещё и сам проследит за доверенностями, и при нарушениях может поменять для себя источник ключей, пусть даже это будет первый ключ от гугла.
                      0
                      Добро пожаловать в 2018 год. Я уже года два как пользуюсь Let's Encrypt. Ставил его на FreeBSD, Gentoo, Ubuntu, Debian. Последние версии рекомендуемого клиента certbot на столько развились, что даже если у вас nginx, то он найдёт все твои домены и предложит выбрать для каких из них тебе надо будет получить сертификат. Все необходимые конфиги будут прописаны автоматически. Дальше просто в cron прописываешь задачу на обновление сертификатов и больше о них не вспоминаешь. Ну, или если такой ленивый, то просто заходишь на сервер, когда тебе приходит письмо и руками запускаешь certbot renew и дёргаешь веб-сервер.
                        0
                        А разве последний certbot сам не делает задачу в cron?
                          0
                          От дистрибутива зависит. У меня, вроде, на Gentoo не добавился. На других да, сам добавляет себя в cron.
                      +15
                      А где слабости HTTPS? Не вижу ни одной, всё работает как и задумывалось.
                        0
                        Что составляет 99% передаваемой по сети информации и с какой долей вероятности болванку свежего дебиана будут качать миллионы пользователей.

                        Впрочем вместо болванки можете подставить патч, скрипт, ролик или фильм.
                          –1
                          Вероятно, 99% составляет сейчас видеоинформация, 99% которой в шифровании с точки зрения пользователя не нуждается, так как не содержит его секретов.
                        +11
                        Хм, я думал https для того чтобы зашифровать передаваемые данные, а не сам факт посещения сайта. Кажется автор слегка за уши притянул проблему.
                          +2
                          проблема не в том, что https не скрывает факт посещения сайта, а то, что многие люди это не понимают и думают, что если https, то можно вообще ни о чем не волноваться. Собственно эту проблему автор и пытается решить.
                            +1
                            В общем то он и это не делает. Системы DPI вполне себе успешно заглядывают внутрь, а экзабайты мусора передаются по сети и должны хранится на винчестерах провайдеров, причем за наши деньги
                              0

                              Вот и надо учить людей тому, что https — это способ убедиться, что страница пришла к тебе с оригинального (не подставного) сервера и не была модифицирована по пути. Для этого не обязательно на низком уровне разбирать, как же этот https работает =)

                                +2
                                «оригинального» вводит в заблуждение. «с того, который указан в адресной строке».
                                  0

                                  Ночью не смог вспомнить слово "легитимного"

                            +2
                            Тут вся интрига во второй части, интересно, что нам поведают? Неужели что-то из серии про не зашифрованные заголовки TCP\IP пакетов…
                              0

                              Подозреваю, MitM. Может, Fiddler какой.

                              +2
                              сразу видно, что CISSP)

                              жду с нетерпением вторую часть, там видимо будут зиродеи с burpsuite и импортированным сертификатом
                                +2

                                И надо было писать целую статью о том, что HTTPS — это не TOR?

                                  0
                                  Не все в этом разбираются. Я например до сих пор не понимаю механизмов работы HTTPS, подвержен ли он атаками MITM и какие технические разновидности у этого HTTPS. Кстати о TOR я тоже вообще ничего не знаю, но почитал бы в рамках подобной статьи «для чайников».
                                    0
                                    Если сильно упрощать, то это труба для ваших данных, но почему то люди думают что данные внутри этой «трубы» зашифрованы, и радуются как дети видя «зеленый замочек»
                                      0
                                      https подвержен mitm аттакам только если у аттакующего есть возможность создавать трастовые сертификаты. Но на этот случае есть HPKP на стороне сервера (хотя из моей практики с ним больше проблем чем пользы).
                                    0
                                    Нужно покопатся в прошивках «брендированных» телефонов, скорее всего там стоят сертификат оператора связи.
                                    Так что режь, вставляй, фильтруй и не гусей а трафик пользователя.

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

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