HTTPS — это HTTP, передаваемый по соединению, защищённому TLS. Важно понимать, какие гарантии даёт эта защита и где заканчивается её действие.
1. Что защищает HTTPS
HTTP описывает обмен между клиентом и сервером: метод и путь, заголовки, коды состояния, а иногда и тело сообщения. TLS добавляет конфиденциальность, целостность и подтверждение подлинности сервера, если клиент правильно проверяет его сертификат. На практике это помогает не дать посредникам прочитать или незаметно изменить HTTP-содержимое при передаче между конечными точками TLS.
Границы этой защиты имеют значение. HTTPS не гарантирует честность сайта, безвредность загруженного файла или безопасное хранение данных на сервере. Он также не скрывает все метаданные соединения. Наблюдатели могут видеть IP-адреса, время передачи и объёмы трафика; в зависимости от поддержки протоколов и их настройки они также могут узнать имя узла из DNS или метаданных TLS. Индикатор защищённого соединения в браузере подтверждает свойства соединения, а не благонадёжность сайта в целом.
2. Сертификат связывает имя с ключом
Сертификат содержит открытый ключ, имена, на которые он распространяется, срок действия и другие сведения. Его подписывает удостоверяющий центр. Браузер проверяет цепочку подписей до доверенного корневого сертификата, соответствие имени узла, срок действия и применимые ограничения, а также учитывает собственные правила работы с сертификатами. Действительный сертификат для одного имени не распространяется автоматически на другое имя или IP-адрес.
Соответствующий закрытый ключ остаётся у сервера или компонента, на котором завершается TLS. Никогда не публикуйте его, не помещайте в корневой каталог сайта и не прикладывайте к переписке со службой поддержки. Сами сертификаты, как правило, публичны; закрытые ключи — нет. При автоматическом обновлении сертификата нужно также предусмотреть загрузку новых файлов обслуживающим процессом, обычно через плавное перечитывание конфигурации.
Проверка домена подтверждает управление именем с помощью предусмотренного проверочного задания. Она не удостоверяет все утверждения, размещённые на сайте. Сертификат может быть действителен, когда приложение возвращает ошибку. И наоборот, исправное приложение может стать недоступным в браузере из-за истёкшего сертификата. Поэтому состояние сертификатов и состояние приложения следует проверять отдельно.
3. Как в общих чертах проходит согласование
При обычном соединении TLS 1.3 клиент отправляет поддерживаемые параметры и сведения для обмена ключами. Сервер выбирает совместимые параметры, передаёт свою часть обмена ключами и подтверждает подлинность согласования сертификатом и подписью. Обе стороны получают ключи для передачи данных и проверяют согласование, прежде чем использовать защищённый канал для обычных данных приложения. Возобновление сеанса позволяет сократить последующие согласования.
Открытый ключ из сертификата обычно не используется для непосредственного шифрования каждой страницы. Современный TLS применяет аутентифицированный обмен ключами, чтобы получить симметричные ключи передачи данных. Это различие объясняет, почему простое копирование сертификата не позволяет выдать себя за сервер: для подтверждения подлинности также нужен соответствующий закрытый ключ. Оно также объясняет, почему перехваченный зашифрованный трафик не обязательно получится расшифровать позднее лишь из-за компрометации долговременного ключа подписи — при условии подходящего обмена временными ключами и корректной реализации.
Расширение SNI, или Server Name Indication, позволяет клиенту указать имя узла при установлении соединения. Благодаря этому сервер с несколькими именами выбирает подходящую конфигурацию. ALPN, или Application-Layer Protocol Negotiation, позволяет сторонам согласовать прикладной протокол, например HTTP/2. Эти механизмы помогают выбрать способ обслуживания соединения, но отделены от пути HTTP-запроса, который передаётся уже после согласования.
4. Перенаправления, смешанное содержимое и HSTS
Перенаправление с HTTP на HTTPS переводит клиента с незашифрованного адреса на зашифрованный. При этом первый HTTP-запрос всё ещё передаётся без шифрования. Механизм HSTS, или HTTP Strict Transport Security, предписывает поддерживающим его браузерам использовать HTTPS при следующих посещениях в течение срока действия политики. Включать его следует осознанно: длительная политика, особенно распространяющаяся на поддомены, может сделать неправильно настроенные службы недоступными для таких браузеров.
Страница HTTPS должна загружать скрипты, стили, изображения и другие ресурсы через HTTPS либо по относительным адресам с того же источника. Подмешивание незащищённых ресурсов в защищённый документ может ослабить его защиту, поэтому браузеры блокируют многие виды смешанного содержимого. Локальное размещение ресурсов также уменьшает зависимость от сторонних сервисов и упрощает устройство небольшого сайта. Политика Content Security Policy дополнительно ограничивает источники ресурсов, которые документу разрешено загружать.
5. Изучите настоящий ответ
При наличии соответствующих утилит эти команды проверяют обычный публичный пример сервиса, не изменяя состояние сервера:
curl --head https://example.com/
openssl s_client -connect example.com:443 \
-servername example.com -verify_hostname example.com \
-verify_return_error < /dev/nullcurl по умолчанию проверяет TLS и показывает заголовки ответа на запрос HEAD. Успешный ответ подтверждает больше, чем открытый порт: клиент завершил согласование TLS и получил ответ HTTP. Команда OpenSSL явно передаёт SNI и запрашивает проверку имени узла и цепочки сертификатов. Для этого локальная установка OpenSSL должна иметь подходящее хранилище доверенных сертификатов. Диагностический вывод подробнее, однако одно лишь успешное TCP-соединение ещё не означает успешную проверку подлинности.
Не «исправляйте» ошибку сертификата привычным отключением проверки через небезопасный параметр клиента. Проверьте запрашиваемое имя, системные часы, срок действия сертификата, отправляемую сервером цепочку и хранилище доверия клиента. Если TLS завершается на обратном прокси, исследуйте именно эту конечную точку, а не предполагайте, что браузер получает сертификат внутреннего приложения.
6. Помните о границах защиты
Шифрование заканчивается в точке завершения TLS. Прокси может прочитать HTTP-запрос перед передачей дальше, а журналы обращений могут сохранять пути и строки запроса. По возможности не помещайте секреты в URL и выбирайте правила журналирования с учётом характера данных. HTTPS защищает передачу, но разумное управление доступом, аккуратное журналирование и безопасная обработка данных на каждой конечной точке по-прежнему решают собственные задачи.