Почему веб-сайтам нужен заголовок HTTP Strict Transport Security (HSTS)

Перевод статьи: Zbigniew Banach — Why Websites Need HTTP Strict Transport Security (HSTS)

HTTPS стал предпочтительным протоколом для любого серьезного веб-сайта, но для эффективного применения HTTPS вместо HTTP требуется заголовок HTTP Strict Transport Security или HSTS. Отправляя заголовок HSTS с подходящими параметрами, сервер информирует браузер о том, что доступна только HTTPS-версия запрашиваемого сайта, и простой HTTP не будет обслуживаться. Чтобы избежать перенаправлений в начале каждого посещения сайта, браузер запоминает эту информацию на время, указанное в заголовке ответа. В этой статье мы рассмотрим историю HSTS, посмотрим, как он работает и как его настроить, а также узнаем, почему ее использование может привлечь трафик на ваш сайт.

Просто обслуживания HTTPS недостаточно

HTTPS был введен для обеспечения безопасной связи — то, для чего никогда не был предназначен простой текстовый протокол HTTP. Для обеспечения сквозной безопасности вся связь между клиентом и сервером должна быть зашифрована, но до HSTS у веб-сайтов не было возможности обеспечить шифрованную связь или указать, что поддерживается только HTTPS. Это делало пользователей уязвимыми для атак «человек посередине» с разбором SSL (как продемонстрировал в 2009 году Moxie Marlinspike), когда злоумышленник перехватывает запрос браузера на страницу HTTPS и перенаправляет его на сервер в качестве запроса простого HTTP. Затем пользователю предоставляется текстовый HTTP-контент, который злоумышленник может легко просматривать и манипулировать им. Хотя пользователь мог видеть, что используется только HTTP, без HSTS не было бы способа определить, должно ли соединение в первую очередь использовать HTTPS.

В 2012 году IETF опубликовала спецификацию HTTP Strict Transport Security (HSTS) как RFC 6797, чтобы устранить этот пробел в цепочке шифрования HTTPS. В настоящее время все основные веб-браузеры поддерживают HSTS. HTTP-заголовок ответа Strict-Transport-Security позволяет серверам указывать, что контент из запрошенного домена будет обслуживаться только по HTTPS. Если этот заголовок указан в ответах веб-сервера, все попытки получить простую версию HTTP-сайта перенаправляются на версию HTTPS, без допусков на ошибки сертификата. Чтобы избежать перенаправлений во время будущих посещений, сервер также указывает, как долго браузер должен помнить об этом . Давайте посмотрим, как это работает на практике.

Как работает HTTP Strict Transport Security

Большинство пользователей не указывают протокол в URL-адресах, введенных в адресную строку, поэтому, если вы запрашиваете www.netsparker.com (или просто netsparker.com), браузер примет HTTP-протокол по умолчанию и отправит HTTP-запрос на http://www.netsparker.com. Но поскольку сайт Netsparker использует HSTS для обеспечения связи то он отвечает перенаправлением на сайт HTTPS (код ответа 301) и включает заголовок ответа Strict-Transport-Security, указывающий, что будет обслуживаться только версия сайта HTTPS. ,

Заголовок Strict-Transport-Security может иметь три директивы:

• max-age является единственной обязательной директивой и указывает, как долго браузер должен помнить, что сайт только HTTPS. max-age указывается в секундах, поэтому типичные периоды истечения 1 или 2 года соответствуют 31536000 или 63072000. Если max-age равен 0, браузер сразу забудет сайт и при следующем подключении будет рассматривать его как будто это новая попытка.
• includesubdomains является необязательным и указывает, что HTTPS также требуется для всех поддоменов указанного домена. Для максимальной безопасности перенаправление HTTPS с заголовком Strict-Transport-Security должно включать директиву includeubdomains и ссылаться на базовый домен (например, netsparker.com), тогда все его субдомены (особенно субдомен www) покрываются HSTS.
• preload также является необязательным и указывает, что сайт отвечает требованиям для предварительной загрузки HSTS и находится в списке предварительной загрузки HSTS или подал заявку на него — см. ниже для получения дополнительной информации о предварительной загрузке.

Как только браузер получает ответ с Strict-Transport-Security, он знает, что он должен использовать только HTTPS для этого сайта в течение всего периода max-age. Если связь HTTPS недоступна, например, из-за того, что HTTPS не настроен должным образом или истек срок действия сертификата, браузер должен прервать соединение. С этого момента каждый раз, когда вы посещаете этот сайт, ваш браузер будет автоматически отправлять HTTPS-запрос, независимо от того, какой протокол вы указали — netsparker.com и http://www.netsparker.com будут перенаправлять вас на сайт HTTPS. Помимо повышения безопасности, это также сокращает время загрузки, поскольку вам не нужно ждать ответа сервера о перенаправлении каждый раз, когда вы запрашиваете URL, без ввода префикса https://.

Предварительная загрузка: средство от уязвимости Bootstrap

После того, как браузер настроил HSTS для сайта, все коммуникации с этим сайтом будут использовать HTTPS, что устраняет угрозу разрыва SSL и гарантирует безопасную передачу. Но при первом посещении неизвестного сайта браузер полагается на ответы сервера для определения правильного протокола — это принцип доверия при первом использовании (или TOFU для краткости). Злоумышленники или вредоносные программы могут перехватить это первое посещение, чтобы перенаправить вас на небезопасный веб-сайт с помощью атаки «человек посередине». Это не такая редко, как кажется — это просто означает, что сайт отсутствует в базе данных браузера HSTS. Хотя это может быть результатом атаки на основе времени по NTP, это также может произойти, если истек срок действия max-age с момента последнего посещения, браузер является новой установкой, сервер неправильно настроен (например, max-age). был оставлен в 0 после тестирования) и так далее.

Чтобы исправить это и повысить скорость загрузки страниц, все основные браузеры (включая Chrome, Firefox, Internet Explorer и Safari) содержат жестко закодированные списки известных сайтов HTTPS. Это называется предварительной загрузкой и основано на Chromium (Chrome) HSTS preload list. Если сайт указан в списке, браузер всегда подключается к нему по протоколу HTTPS, даже при первом посещении. Это эффективно устраняет единственную существенную уязвимость в применении HTTPS, обеспечивая сквозное шифрование. Единственным недостатком является то, что обновленный список распространяется только с новыми версиями браузеров, поэтому процесс обновления идет медленно, и если вы недавно добавили свой сайт, нет никакой гарантии, что в какой-либо отдельной установке браузера уже будет загружен ваш сайт.

Чтобы добавить свой сайт в список, сначала убедитесь, что он соответствует всем требованиям для предварительной загрузки:

• Настроен действительный сертификат
• Есть перенаправление всех HTTP-запросов с 80 порта на HTTPS
• На сайте все субдомены обслуживаются по HTTPS
• Указаны все директивы заголовка HSTS: max-age должен составлять не менее 31536000 секунд (1 год), а также включать includesubdomains и preload.

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

При правильно реализованной предварительной загрузке HSTS может гарантировать, что браузер инициирует и использует только защищенные соединения с HTTPS-обслуживающими сайтами. Конечно, число защищенных веб-сайтов продолжает расти, поэтому очевидно, что предварительная загрузка является лишь временным решением — в какой-то момент статический список может стать слишком большим для обслуживания и распространения.

NTP-атаки на HSTS

В настоящее время HSTS является довольно надежным способом обеспечения HTTPS-соединений. Единственный практический подход к компрометации HSTS основан на атаках на сетевой протокол времени (NTP), когда пытаются манипулировать системным временем путем фальсификации значений времени с серверов NTP. Это позволяет злоумышленникам обмануть браузер в истечении срока действия записей HSTS и разрешении небезопасных HTTP-соединений. Обратите внимание, что это не является проблемой, свойственной только HSTS — уязвимости NTP также можно использовать для атак на другие технологии и протоколы безопасности, включая SSL/TLS, Kerberos и Active Directory.

Отслеживание браузера с помощью HSTS Supercookies

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

Например, веб-сайт может содержать несколько однопиксельных маяков, каждый из которых запрашивается по HTTP из другого субдомена, контролируемого злоумышленником. Указывая или пропуская заголовки HSTS в конкретных ответах, злоумышленник может сохранить потенциально уникальный шаблон в базе данных HSTS браузера, фактически назначив отпечаток пальца. Когда браузер снова заходит на сайт, он пытается использовать HTTPS для загрузки маяков, которые изначально содержали заголовок HSTS в ответах, и простого HTTP для оставшихся. Читая этот шаблон, злоумышленник может идентифицировать и отслеживать возвращающийся браузер. Файлы cookie в этом случае не используются, и fingerprinting работает в течение нескольких сеансов и независимо от режима инкогнито, поэтому эти идентификаторы были названы «supercookies».

Рисунок 1. Отпечатки в браузере, основанные на поведении HSTS

Насколько уникален этот fingerprinting анализ, зависит от количества используемых маяков. Каждый маяк предоставляет 1 бит информации, поэтому с 5 маяками вы можете получить 2 ^ 5 = 32 значения, но увеличить его до 30 маяков, и у вас будет 2 ^ 30 — это более 1 миллиарда уникальных идентификаторов. Злоумышленники также могут сбросить биты, ранее сохраненные в браузере, отправив max-age = 0 в заголовке ответа, что дает им возможность хранить несколько бит информации в вашем браузере много раз. Хотя кажется, что в настоящее время эта уязвимость является в значительной степени теоретической и в реальности не используется, о ней полезно знать, поскольку без изменения спецификации HSTS невозможно обойти ее.

Преимущества и недостатки включения HSTS

Для пользователей очевидным преимуществом развертывания HSTS является повышенная безопасность благодаря истинному сквозному шифрованию HTTPS. Заголовки HSTS действительны только для HTTPS-соединений, поэтому использование HSTS гарантирует, что незашифрованный HTTP-трафик не будет отправлен. В сочетании с предварительной загрузкой HSTS которая также сокращает время загрузки страницы, устраняя перенаправления сервера с HTTP на HTTPS. Поскольку скорость загрузки страниц является важной частью взаимодействия с пользователем, особенно с мобильных устройств, более быстрая загрузка может улучшить показатели SEO сайта и привлечь больше трафика, поэтому включение HSTS и предварительной загрузки имеет смысл и для бизнеса.

С другой стороны, любое развертывание HSTS должно быть тщательно спланировано и учтено, особенно если вы используете предварительную загрузку. Помните, что после включения HSTS любые попытки подключиться к вашему сайту или веб-приложению с использованием обычного HTTP будут отклонены, и любые проблемы с настройкой вашего веб-сервера (например, сертификат с истекшим сроком действия) могут сделать сайт полностью недоступным. Вы также должны использовать HTTPS для каждой страницы вашего домена и всех его поддоменов (если вы указали includesubdomains), что для сложных сайтов может потребовать дополнительной работы.

Включив HSTS, вы обязуетесь поддерживать HTTPS и выполнять все требования предварительной загрузки непрерывно и в течение потенциально неопределенного времени. Однако, если вы можете убедиться в том, что ваша бизнес-модель поддерживает работу только по протоколу HTTPS, преимущества от повышения безопасности и удобства работы пользователей могут быть значительными.