«HTTP Strict-Transport-Security» или как обезопасить себя от атак «man-in-the-middle» и заставить браузер всегда использовать HTTPS

    Внимание к мелочам рождает совершенство,
    а вот совершенство уже не мелочь.


    Микеланджело Буонарроти


    C 2012 года администраторам веб-ресурсов стала доступна новая технология HTTP Strict Transport Security (HSTS) — механизм, активирующий форсированное защищённое соединение по HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP. Механизм использует особый заголовок HTTP Strict-Transport-Security, для переключения пользователя, зашедшего по HTTP, на HTTPS-сервер [1].
    HSTS направлен на закрытие следующих уязвимостей к атакам:
    Пользователь помещает в закладки или набирает в адресной строке http://example.com/ и становится жертвой атаки «man-in-the-middle» HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена
    Веб-приложение, предполагаемое к использованию строго по HTTPS, по небрежности содержит HTTP-ссылки или отдает контент по HTTP HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена
    Атакующий «man-in-the-middle» пытается перехватить трафик жертвы используя поддельный сертификат в надежде, что пользователь не обратит внимания на сообщение о невалидном сертификате HSTS не даст пользователю пройти дальше сообщения о проблемах с сертификатом
    Включается данная технология проще простого, необходимо возвращать пользователю HTTP-заголовок «Strict-Transport-Security» в тот момент, когда он заходит на сайт по HTTPS:
    Strict-Transport-Security: max-age=expireTime [; includeSubdomains]

    expireTime
        Время в секундах, на которое браузер должен запомнить, что данный сайт должен посещаться исключительно по HTTPS. includeSubdomains (опционально)
        Если указать этот необязательный параметр, правила так же применятся ко всем поддоменам.

    Что это дает

    В случае, если веб-сайт принимает соединения по HTTP и перенаправляет их на HTTPS, пользователь вполне может обратиться к незашифрованной версии сайта до перенаправления если, к примеру, он наберет в адресной строке http://example.com/ или, еще проще, example.com. Это открывает потенциальную возможность проведения атаки «man-in-the-middle», в которой HTTP-перенаправление вместо оригинальной зашифрованной страницы отправит пользователя прямиком на сайт злоумышленника.
    Механизм HTTP Strict Transport Security позволяет веб-сайту проинформировать браузер, что тот не должен использовать HTTP и, вместо этого, автоматически со своей стороны преобразовывать все HTTP-запросы в HTTPS.
    Например, вы подключаетесь к открытой точке доступа Wi-Fi в публичном месте и открываете ДБО своего любимого банка, чтобы проверить баланс и совершить пару платежей. К несчастью, используемая вами точка доступа на самом-то деле — ноутбук злоумышленника, перехватывающего ваши HTTP-запросы и перенаправляющего вас вместо оригинального сайта банка на страничку-клон. Ваши данные попадают прямо ему в руки.
    HSTS решает данную проблему. Если вы хоть раз успешно подключились к веб-сайту банка по HTTPS, использующему «Strict Transport Security», браузер автоматически начнет использовать HTTS для всех запросов. Это предотвратит возможность атак «man-in-the-middle» вышеописанного типа.

    Как поступает браузер

    Первый раз когда сайт посещается по HTTPS и возвращает заголовок «Strict Transport Security», браузер запоминает указанную информацию и все дальнейшие попытки доступа к сайту по HTTP будут автоматически преобразовываться в HTTPS.
    Когда истечет указанный в заголовке «Strict-Transport-Security» таймаут, следующая попытка загрузить сайт по HTTP произойдет в обычном режиме и автоматическое перенаправление на HTTPS не осуществится.
    Всякий раз при получении заголовка «Strict-Transport-Security», браузер обновляет таймаут, т.е. сайты имеют возможность обновлять данную информацию и не допустить истечения таймаута (или наоборот, по каким-либо причинам его уменьшить).
    Кстати: заголовок «Strict-Transport-Security» игнорируется браузером в случае подключения по HTTP, так как атакующий может перехватить HTTP-соединение и подменить заголовок. Браузер поймет, что сайт HTTPS-совместим и должным образом обработает заголовок «Strict-Transport-Security» в том случае, если доступ к сайту происходит по HTTPS без ошибок с сертификатами.

    Поддержка браузерами

    • Chromium и Google Chrome с версий 4.0.211.0
    • Firefox с версии 4 [2]; с Firefox 17, Mozilla внедрила список веб-сайтов, поддерживающих HSTS.
    • Opera с версии 12
    • Safari из комплекта OS X Mavericks

    Детали реализации

    Заголовки «Strict-Transport-Security» должны передаваться только по HTTPS. Клиенты не должны обрабатывать HSTS заголовки, присланные, не в HTTPS-ответах или по HTTPS с невалидными, неверно настроенными сертификатами. Следующие отрывки конфигурации должны находиться внутри контекста SSL и примеры кода предполагаются исключительно в контексте HTTPS ответов.
    Имейте ввиду, что директива «max-age» представлена в секундах. 31536000 секунд (12 месяцев) в примерах ниже м.б. изменены в зависимости от того, как долго администратор веб-сервера предполагает использовать сайт исключительно по HTTPS. Рекомендовано устанавливать значение «max-age» довольно большим вроде 31536000 (12 мес.) или 63072000 (24 мес.). [3]

    Реализация в Apache
    # подгружаем модуль (на примере RHEL/CentOS)
    LoadModule headers_module modules/mod_headers.so
    <VirtualHost 10.0.0.1:443>
       # Use HTTP Strict Transport Security to force client to use secure connections only
       Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    </VirtualHost>

    Реализация в Nginx
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    Предопределенные HSTS сайты

    Существует промежуток в котором пользователь со свежеустановленным браузером и сборошенными настройками оказывается уязвим. По этой причине Chrome и Firefox поддерживают список «предопреденных» HSTS ресурсов. Следующие домены настроены использовать HSTS «из коробки»:
    • Google
    • Paypal
    • Twitter
    • Torproject
    • passport.yandex.ru
    Полный список сайтов доступен по ссылке: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json [4]

    Для самостоятельного изучения:

    1. ru.wikipedia.org: HSTS
    2. developer.mozilla.org: HTTP Strict Transport Security
    3. en.wikipedia.org: HTTP Strict Transport Security
    4. dev.chromium.org: HTTP Strict Transport Security
    5. www.owasp.org: Top 10 2010-A9-Insufficient Transport Layer Protection
    6. security.stackexchange.com: How can a web application protect IE users when this browser doesn't support HSTS?
    7. habrahabr.ru: Все на https, безопасно и дешево
    8. habrahabr.ru: На пути к созданию безопасного веб-ресурса. Часть 1 — серверное ПО
    Поделиться публикацией
    Комментарии 33
      0
      Непонятно, что защитит клиента, который впервые заходит на мой сайт, и использует http, а не https, если нас атакуют с помощью man in the middle.
      Если я отдам редирект на https или в html'ке подсуну ссылку на https, то что помешает человеку-посередине подменить оба адреса на http?
      А итоге мой клиент так никогда и не обратится по https и не узнает о сабжевом чудо заголовке.
        –4
        Похоже, автор считает, что этот «магический» заголовок передастся пользователю голубинной почтой в обход того самого man 'a…
          +1
          "… The HSTS header can be stripped by the attacker if this is the user's first visit. Google Chrome and Mozilla Firefox attempt to limit this problem by including a «pre-loaded» list of HSTS sites.… " и т.д. и т.п. В общем, спорная штука…
            +5
            Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.

            Если у ДБО банка есть HSTS и пользователь дома спокойно им пользовался, то в поездке он в ловушку man'a не попадется.
              +1
              с этим я согласен, не спорю.
            +7
            HSTS не предназначен для защиты _первого_ соединения. Это лишь один из механизмов защиты, вкупе с валидными SSL-сертификатами и проч.
              –4
              Что значит «валидный SSL-сертификат»? Точное определение можно?
                0
                Я очень люблю, как хабровчане с радостью минусуют любой провокационный вопрос. Ищите «rouge gmail ssl certificate», желательно не в Гугле по вполне понятным причинам. И после этого задайтесь вопросом: так что же такое на самом деле «валидный SSL-сертификат»?
                  +1
                  Ну вот вы и сказали бы нам, что должен означать термин "«валидный SSL-сертификат", а не обижаться и посылать всех не в гугл…
                    +1
                    Я не обижаюсь. Просто забавный факт. Термин «валидный SSL-сертификат» имеет смысл только когда известны критерии валидности. Для кого-то это «подписан одним их 'официальных' УЦ», для кого-то может и «все числа в fingerprint чётные», для кого-то это может быть «fingerprint совпадает с полученным через out of band connection для этого домена». В любом случае, надеяться, что раз браузер на сертификат не ругается, то стало быть и всё в порядке как минимум беспечно. И в любом случае необходимо в первую очередь трезво оценивать риски.

                    Историй с дубликатами SSL-сертификатов на текущий момент уже достаточно, чтобы не доверять УЦ. И правильства (Франции в частности) выписывали через УЦ сертификат на gmail.com, чтобы следить за какими-то тёмными личностями, и частная компания умудрилась получить такой же «левый» сертификат для gmail.com для слежки за своими сотрудниками. Взломы УЦ тоже были в прошлом и не всегда было известно сколько времени прошло между самим взломом и обнаружением факта взлома. В общем, получается, что доверять можно только собственноручно созданному корневому сертификату и другим подобным, входящим в твой WoT. Остальное слишком легко обходится при текущей реализации. И рассматривать «валидные SSL-сертификаты» поставляемые с браузером как один из механизмов защиты в контексте HSTS по-моему несколько беспечно.

                    С учётом акций в Турции по запрету Твиттера, много ли доверия нижеследующим сертификатам?

                    TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
                    TURKTRUST_Certificate_Services_Provider_Root_1.pem
                    TURKTRUST_Certificate_Services_Provider_Root_2007.pem
                    TURKTRUST_Certificate_Services_Provider_Root_2.pem

                    А они есть и включены по умолчанию.

                    Кстати, именно вот в гугл я и не посылал. Гугл всё же фильтрует выдачу и успешно «размывает» результаты.
              +2
              Встраивают в браузеры политики самых популярных сайтов
              –1
              Абсолютно от MitM не защищает.

              Простейшая схема: китайские спецлужбы с целью компрометации правозащитника, протестующего против фальсификаций на выборах (на которых было 146%) компрометирует DNS провайдера (пришла с приказом и скомпрометировала), или с помощью прозрачного NAT'а 8.8.8.8 завернула на свой сервер.

              Дальше:

              пользователь хочет зайти на сайт. Ему отдают фальшивый адрес. Пользователь обращается на сайт. Его запрос проксируют на настоящий сайт, удаляют все признаки https/hsts, лишние заголовки, и отдают пользователю по http. У пользователя всё работает, никаких предупреждений.
                –3
                Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.
                  +4
                  При чём тут «пистолет к голове»? Предлагается решение для защиты трафика, в частности, от mitm. При том, что в Китае описанная атака уже вполне используется, а в России с большой вероятностью начнёт использоваться в обозримое будущее (ну там, национал-предателей отлавливать), я показываю, что никакой проблемы предлагаемое решение не решает.
                    0
                    Предлагаете уйти на персональные ключи шифорвания? Как вообще можно от такого сценария защищаться? Если так посудить, можно у провайдера через уязвимость в маршрутизаторе весь трафик абонента собирать. Или жаде проще — через вирус на его ПК, подписанный валидной цифровой подписью (как в stuxnet).
                      0
                      Я могу подарить вам весь мой трафик, идущий через провайдера. Там всё шифрованное. Кроме кук на сайтах типа хабрахабра, но это уже другой вопрос.

                      Так что в нормальной системе mitm не должен быть проблемой.

                      Насчёт «решения» — дурацкую архитектуру костыли не исправят. WoT — наше всё.
                        0
                        В какой-то точке оно же расшифровывается. Не на узлах провайдера, так дальше.

                        Судя по презентациям Сноудена — внутри ДЦ публичных сервисов сплошь HTTP.
                          0
                          Как будто Сноуден знает, что там в ДЦ происходит. В NSA — может быть. В ДЦ — врят ли.

                          Адекватное шифрование не выпускает нешифрованный трафик за пределы хоста. Что бы производители хардварных vpn не говорили.
                            +1
                            Да вот же он, один из самых прекрасных слайдов, от которых google оч оскорбился и клятвенно ч-то там наобещал:


                            Даже если отключить у себя 80й порт полностью и ходить только по https-only ресурсам, между фронтэндом и бэкэндом самого сайта может быть что угодно.
                        0
                        > Как вообще можно от такого сценария защищаться?

                        Так никак же. Собственно, я сюда и зашёл из-за такого многообещающего заголовка — решена одна из фундаментальных проблем, уже начал открывать шампанское, а оказалось… Да, от MitM можно защититься, но при некоторых условиях.
                    +2
                    Если пользователь до этого хотя бы раз зашел не на фальшивый сайт, то Ваша схема не сработает.
                      –1
                      ок, пользователь зашёл на https://github.com

                      Завтра установили mim-атаку. Каким образом «схема не сработает?». Человек пишет github.com, открывается http://github.com. Какой проницательностью нужно обладать, чтобы заметить отсутствие https?
                        +1
                        Браузер сам подставит https://

                        Если сертификат сайта окажется невалидным, не пропустит дальше.
                          –1
                          А, в этом смысле, да. До ближайшей чистки истории.
                            +2
                            Сильно подозреваю (https://support.mozilla.org/ru/questions/919498, не нашёл аналогичной ссылки для chromium), что HSTS обслуживается отдельно от истории.
                              +2
                              не нашёл аналогичной ссылки для chromium


                              А, вот: stackoverflow.com/questions/10629397/how-to-disable-http-strict-transport-security: тоже говорится никак не о чистке истории.
                                +1
                                Тогда HSTS-хранилище пользователя сможет частично компрометировать историю посещений.
                                Потребуются отдельные опции на очистку журнала и HSTS (в firefox, предположительно, галочка «Настройки сайтов» в диалоге «Удалить недавнюю историю»).
                        +2
                        > Простейшая схема: китайские спецлужбы с целью компрометации правозащитника, протестующего против фальсификаций на выборах (на которых было 146%) компрометирует DNS провайдера (пришла с приказом и скомпрометировала), или с помощью прозрачного NAT'а 8.8.8.8 завернула на свой сервер.

                        По-моему, простейшая схема выглядит чуть проще: сосед — студент 4 курса специальности, связанной с ИТ — врезается в провайдерский кабель и модифицирует любой проходящий трафик.
                        +1
                        Почему хорошим людям просто не собраться и не запретить незащищенные соединения? Вычислительная сторона SSL давно перестала быть проблемой для современного железа, разве нет?
                          +2
                          А как же тогда MitM проводить если надо? Не, так не пойдёт.
                            0
                            Если очень надо, можно внедрить бэкдор в алгоритм шифрования.
                              0
                              Или компрометация корневых сертификационных центров, что проще, имхо. Иллюзия безопасности есть и сертификаты можно штамповать без проблем. С самоподписанными сертификатами не пройдет, но кто их будет вручную в браузер ставить?
                          0
                          подскажите, а к ответам сервера вроде 404 или 500 Strict-Transport-Security должен цепляться или по сути все равно?

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

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