Главная » Гайд

HSTS: Как работает расширение HTTPS

На чтение 9 мин. Просмотров 59 Опубликовано

Все больше и больше интернет-провайдеров стремятся обеспечить своим пользователям безопасный доступ к онлайн-контенту. Протокол шифрования TLS (Transport Layer Security) был создан для использования в Интернете, но впервые стал известен под своим предыдущим названием SSL (Secure Sockets Layer). В то время как соединения с веб-сайтами через HTTP (Hypertext Transfer Protocol) обычно являются незашифрованными, сетевой протокол HTTPS («Hypertext Transfer Protocol Secure» или «Hypertext Transfer Protocol over SSL/TLS») дает пользователям возможность, благодаря шифрованию SSL/TLS, безопасно организовать передачу данных по сети.

Интернет-гигант Google подает хороший пример и предлагает свои высокочастотные веб-сервисы исключительно с шифрованием SSL/TLS. С августа 2014 года HTTPS также используется в качестве фактора ранжирования в алгоритмах органического веб-поиска. Это значительно повышает значимость транспортного шифрования с поддержкой SSL/TLS для операторов веб-сайтов. Однако HTTPS не обеспечивает надежной защиты в конфигурации по умолчанию. ИТ-специалистам постоянно приходится быть начеку и искать бреши в системе безопасности. Наибольшую опасность представляют атаки типа «человек посередине», которые позволяют хакерам обойти шифрование SSL/TLS. Только с 2012 года появился механизм защиты HTTPS-соединений — HSTS, который предотвращает подобные атаки.

Содержание
  1. Слабые места технологии HTTPS
  2. Перенаправление HTTP на HTTPS
  3. Снятие SSL
  4. Что такое HSTS?
  5. Списки предварительной загрузки для сайтов HTTPS
  6. Настройка HSTS: Краткие инструкции для Apache2, Lighttpd и NGINX
  7. Apache HTTP Server
  8. NGINX
  9. Lighttpd
  10. Microsoft IIS

Слабые места технологии HTTPS

Когда доступ к веб-сайту осуществляется с помощью сетевого протокола HTTPS и надежного сертификата SSL/TLS, то зашифрованный транспорт, как правило, безопасен. Однако в прошлом часто происходили атаки на органы сертификации, что приводило к использованию большого количества небезопасных сертификатов. Широко распространенные привычки пользователей и общая небрежность при работе с зашифрованными соединениями также создают множество уязвимых мест для фишинговых атак и атак типа «человек посередине».

Перенаправление HTTP на HTTPS

Пользователи Интернета редко вводят URL-адреса полностью. Вместо этого интернет-адреса сокращаются только до своего домена. Сетевой протокол HTTPS, который должен обеспечивать шифрованное соединение, обычно не указывается. Например, пользователи Интернета вместо https:// example.com набирают в адресной строке браузера example.com, и браузер автоматически преобразует поисковый запрос в стандартный сетевой протокол для доступа к веб-страницам: HTTP.

                example.com -> http:// example.com

Если целевой страницей является зашифрованный веб-сайт, это происходит только после перенаправления HTTP на HTTPS на стороне сервера.

                http:// example.com -> https:// example.com

В конце концов, шифрованное соединение устанавливается, но обходной путь по незашифрованному URL дает хакерам возможность позиционировать себя в качестве «человека посередине» между браузером и сервером. В этом случае весь трафик данных может быть прочитан в открытом виде без необходимости взлома SSL/TLS-шифрования. Если целевой страницей является банк или интернет-магазин, то эта уязвимость может иметь серьезные последствия для пользователей, осуществляющих операции с деньгами в Интернете.

Проиллюстрируем на примере: публичные точки WLAN доступны во многих местах. Люди часто беспечно пользуются этими соединениями, не проверяя, кто на самом деле предоставляет доступ в Интернет. Хакеры пользуются этой беспечностью, устанавливая свой компьютер в качестве точки доступа и записывая весь трафик данных. Если один из пользователей получает доступ к своему интернет-банку через такую псевдо-точку доступа, то хакер может внедрить перенаправление на фишинговый сайт до того, как сервер интернет-банка успеет перенаправить HTTP-соединение на HTTPS.

Снятие SSL

Мокси Марлинспайк, киберпанк и основатель Open Whisper Systems, еще в 2009 году в рамках конференции по безопасности Black Hat продемонстрировал технику, с помощью которой обычные HTTPS-соединения можно нивелировать с помощью самостоятельно разработанного SSL stripping.

Чтобы показать, где HTTPS уязвим, Марлинспайк разработал прокси-программу SSLStrip. Это программное обеспечение использует брешь в безопасности при перенаправлении HTTP-адресов на HTTPS-адреса и преобразует все HTTPS-запросы браузера в идентичные HTTP-запросы. В то время как SSLStrip создает незашифрованное HTTP-соединение с браузером пользователя, программа взаимодействует с сервером на уровне HTTPS. Пользователя обманывает отображение значка замка в строке браузера, который обычно ассоциируется с безопасным соединением. Предпосылкой для подобной атаки является то, что хакер может прочитать сообщение между браузером и сервером.

Одно из решений проблемы безопасности, на которую указал Марлинспайк, было представлено Целевой группой инженеров Интернета (IETF) три года спустя: В 2012 году расширение HTTPS HTTP Strict Transport Security (HSTS) было указано в RFC 6797.

Что такое HSTS?

HSTS (HTTP Strict Transport Security) — это механизм безопасности, который был разработан для защиты HTTPS-соединений от атак типа «человек посередине» и перехвата сеанса. С помощью расширения HTTPS операторы веб-сайтов могут сигнализировать веб-браузерам посредством дополнительной информации заголовка HTTP, что сайт может быть получен в зашифрованном SSL/TLS виде в течение определенного периода времени. На стороне сервера используется поле заголовка Strict-Transport-Security. Оно содержит обязательную директиву max-age и может быть расширено необязательными директивами includeSubDomains и preload:

                Strict-Transport-Security: max-age=31536000

Директива max-age указывает, в течение какого времени веб-сайт должен быть доступен исключительно в зашифрованном виде. Этот период времени определяется в секундах. Значение max-age в 31 536 000 секунд означает период в один год.

Когда пользователь Интернета впервые посещает веб-сайт, защищенный HSTS, браузер получает следующие директивы из поля заголовка Strict-Transport-Security:

  • Все незашифрованные ссылки на соответствующий веб-сайт должны быть перезаписаны зашифрованными ссылками (http:// — https://).
  • Если безопасность соединения не может быть гарантирована (например, на основании недействительных сертификатов), то оно должно быть прервано. Пользователю показывается сообщение об ошибке.

По желанию данные HSTS могут быть распространены на поддомены. В этом случае поле заголовка Strict-Transport-Security дополняется директивой includeSubDomains. Это сигнализирует браузеру, что заголовок HSTS предназначен не только для текущего хоста (например, www.example.com), но и для всех поддоменов под указанным доменом (например, также для blog.example.com или adserver.example.com).

                Strict-Transport-Security: max-age=31536000; includeSubDomains

Директива preload позволяет пометить сайт для так называемой предварительной загрузки и таким образом избежать «проблемы первого посещения».

                Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Без параметра предварительной загрузки HSTS влияет только на будущие посещения веб-страниц: Если браузеру известна информация в заголовке HSTS веб-сайта, то будущий доступ осуществляется соответствующим образом. В противном случае, при первом посещении сайта мера безопасности не работает. Разработчики браузеров, такие как Google и Mozilla, также предлагают возможность вносить сайты в списки предварительной загрузки. Доступ к сайтам, которые были зарегистрированы для предварительной загрузки, осуществляется исключительно по протоколу HTTPS. Списки предзагрузки управляются централизованно разработчиками браузеров и передаются в браузеры пользователей через обновления.

Списки предварительной загрузки для сайтов HTTPS

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

Теоретически, любой оператор веб-сайта может бесплатно внести свой домен в список предварительной загрузки HSTS. Но включение сайта связано с соблюдением основных требований, обеспечивающих качество системы контроля:

  • Все веб-сайты должны иметь действующий SSL-сертификат.
  • HTTP URL должны быть направлены на HTTPS URL того же хоста.
  • Все поддомены (включая поддомен www) должны быть доступны через HTTPS.
  • Заголовок HSTS должен быть доставлен через основной домен со следующими параметрами:
    • Значение max-age должно быть не менее восьми недель (4,838,400 секунд).
    • Заголовок HSTS должен содержать директиву includeSubDomains.
    • Заголовок HSTS должен содержать директиву preload.
    • Все дополнительные перенаправления с сайта HTTPS должны содержаться в заголовке HSTS.

Среди известных пользователей функции предварительной загрузки HSTS — Google, Paypal, Twitter и LastPass. Полный список введенных доменов можно найти на сайте проекта Chromium.

Настройка HSTS: Краткие инструкции для Apache2, Lighttpd и NGINX

Для использования HSTS на HTTP-сервере Apache сначала необходимо активировать модуль заголовков Apache (mod_headers). Операторы сайта вводят в терминале следующую команду:

Apache HTTP Server

Для использования HSTS на HTTP-сервере Apache необходимо сначала активировать модуль заголовков Apache (mod_headers). Операторы веб-сайта вводят в терминал следующую команду:

sudo a2enmod headers

Если модуль заголовков Apache активирован, то необходимо перезапустить сервер:

sudo service apache restart

HTTP-сервер Apache дает вам возможность запускать различные домены на одном сервере. Каждый из этих доменов в терминологии Apache называется VirtualHost (vhost) и настраивается независимо от других доменов на сервере. Поскольку HSTS является расширением для HTTPS, этот механизм безопасности доступен только для VirtualHosts с портом номер 443 — портом по умолчанию для HTTPS. Чтобы принудительно установить зашифрованное соединение с HTTPS-сайтом для последующих посещений, операторы сайтов добавляют нужный VirtualHost в конфигурационный файл Apache https.conf в следующей строке кода:

Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"

Для этого поле заголовка Strict-Transport-Security записывается в контейнер VirtualHost вместе с другими директивами:

<VirtualHost *:443>
    ServerAdmin support@example.com
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key
    […]
    Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"
    DocumentRoot /var/www/
</VirtualHost>

При каждом обращении к браузеру, настроенному таким образом, Apache выводит заголовок HSTS с нужными параметрами. В данном примере браузеру предписано в течение следующих восьми недель получать доступ к веб-сайтам под доменом example.com, включая поддомены, исключительно с использованием SSL/TLS-шифрования.

Чтобы конфигурация была принята, Apache должен быть перезапущен.

NGINX

В NGINX соединения с шифрованием SSL/TLS также могут быть принудительно установлены с помощью простой строки кода:

add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";

Настройка производится в конфигурации файла /etc/nginx/nginx.conf. Вместо VirtualHosts, NGINX использует серверные блоки для определения директив:

server {
    listen      443 ssl;
    server_name    example.com;
    ssl_certificate  www.example.com.crt;
    ssl_certificate_key  www.example.com.key;
    […]
    add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
}

NGINX также должен быть перезапущен после настройки.

Lighttpd

Чтобы активировать HSTS для Lighttpd, необходимо настроить конфигурационный файл /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}

Настройки будут приняты после перезапуска сервера.

Microsoft IIS

В отличие от Apache, NGINX и Lighttpd, сервер Microsoft Internet Information Services (IIS) настраивается через графический интерфейс пользователя. Чтобы активировать HSTS, операторы веб-сайтов выполняют следующие действия:

  • Запустите менеджер IIS и выберите нужный веб-сайт.
  • Выберите пункт меню «Заголовок ответа HTTP» и нажмите кнопку «Добавить».
  • Введите Strict-Transport-Security в диалоговом окне «Add Custom HTTP Response Header» в поле «Name», а в поле «Value» задайте желаемый период времени (в секундах).

Для завершения работы перезапустите IIS.

Оцените статью
cdelat.ru
Добавить комментарий