TLS в HTTP/2: нужен ли HTTPS и как его настраивать
Перевод статьи TLS in HTTP/2 с любезного согласия Daniel Stenberg
Оригинальный текст написан Daniel Stenberg, основным разработчиком cURL и участником рабочей группы по HTTP/2 в IETF. Настоящая версия — адаптированный перевод на русский язык с комментариями редакции Softdroid. В нашей практике настройки Nginx и Apache с HTTP/2 и TLS для корпоративных и высоконагруженных проектов многие вопросы из статьи остаются актуальными, поэтому ниже сохранён ход рассуждений автора и добавлены пояснения о текущем состоянии протоколов HTTP/2 и TLS.
Если вы админ/разработчик и вам нужно решение сейчас:
- Для публичных веб‑сайтов HTTP/2 фактически всегда используется поверх TLS (HTTPS). Без TLS современные браузеры HTTP/2 не включают.
- Минимум на практике: веб‑сервер с поддержкой HTTP/2 и TLS 1.2/1.3, набор шифров из «современного» профиля (см. рекомендации Mozilla).
- Сертификат можно получить бесплатно через Let’s Encrypt с помощью ACME‑клиента (certbot и аналоги); базовая настройка в типичных кейсах занимает от 10 до 20 минут.
- Для подбора безопасных шифров и параметров TLS удобно использовать Mozilla SSL Configuration Generator.
TLS – не обязательное условие
В одобренной спецификации HTTP/2, которая вот-вот станет официальным RFC, нет рекомендаций по использованию TLS для защиты протокола. Напротив, в спецификации четко объясняется, как использовать его как в открытом тексте (поверх обычного TCP), так и в TLS. TLS не является обязательным условием для функционирования HTTP/2.
Описанное выше отражает статус на этапе стандартизации HTTP/2. В актуальной спецификации RFC 7540 (HTTP/2) действительно указано, что протокол может работать как поверх чистого TCP, так и поверх TLS. Однако в реальном веб‑трафике сегодня практически все публичные HTTP/2‑соединения идут через HTTPS: по данным практических замеров на продакшн‑проектах и отчётов крупных компаний, доля нешифрованного HTTP/2 в открытом Интернете близка к нулю и встречается в основном во внутренних сетях и специальных протоколах поверх HTTP/2 (например, gRPC).
TLS обязателен в силе
Хотя спецификация не заставляет внедрять HTTP/2 принудительно поверх TLS, но позволяет делать это поверх обычного текста TCP. Представители групп разработчиков Firefox и Chrome заявили о своем намерении реализовать HTTP/2 через TLS. Это означает, что URL-адреса, начинающиеся с HTTPS://, – единственные, которые включают HTTP/2 для этих браузеров. Разработчики из Internet Explorer намерены также поддерживать новый протокол без TLS. При этом, когда они отправили свою первую тестовую версию в рамках предварительной версии Windows 10, этот браузер также поддерживал только HTTP/2 через TLS. На раннем этапе стандартизации HTTP/2 публичные браузеры не поддерживали нешифрованный HTTP/2, и большинство существующих серверов взаимодействовали только по HTTP/2 посредством TLS.
Разница между тем, что спецификация позволяет, и тем, что обеспечат браузеры – ключевая. И браузеры, и все другие пользовательские агенты – разрешены и ожидают, что каждый выберет собственный тренд. Сейчас все основные браузеры (Chrome, Firefox, Edge, Safari и их мобильные версии) реализуют HTTP/2 только поверх TLS и включают его для HTTPS‑ресурсов, в то время как варианты без шифрования применяются, главным образом, во внутренних системах, специализированных клиентах и некоторых machine‑to‑machine‑протоколах.
Если вы развертываете сервер для HTTP/2, вам нужно сделать это для поддержки HTTPS, чтобы привлечь пользователей. На практике при настройке современных веб‑серверов мы видим, что переход на HTTP/2 почти всегда совмещают с включением або ужесточением TLS (обновление до TLS 1.2/1.3, отключение устаревших шифров и протоколов).
Допустимым замечанием было бы то, что браузеры - не единственные пользовательские агенты HTTP/2, и есть несколько реализаций, не относящихся к браузеру. Они реализуют версию протокола без TLS: однако я все еще надеюсь, что влияние браузеров будет существенным.
Строгий TLS
При выборе передачи HTTP/2 через TLS спецификация требует четкого соблюдения требований TLS. Более строгих чем те, которые большинство клиентов когда-либо применяли для обычного HTTP 1.1 через TLS.
Это говорит о том, что TLS 1.2 или более поздняя версия НЕОБХОДИМЫ. Запрещается сжатие и пересмотр. Протокол определяет довольно подробные «худшие приемлемые» размеры ключей и наборы шифров. HTTP/2 будет просто использовать более безопасный TLS.
Спецификация HTTP/2 требует как минимум TLS 1.2, описанный в RFC 5246; на практике при настройке современных серверов уже повсеместно используется и TLS 1.3 (RFC 8446), который уменьшает задержку при установке соединения и ужесточает набор шифров. В типичных продакшн‑конфигурациях Nginx и Apache мы, например, включаем только современные шифры с прямой прямой секретностью (ECDHE) и отключаем TLS 1.0/1.1, что в тестах SSL Labs стабильно даёт рейтинг не ниже A при сохранении нормальной производительности.
Еще одна деталь – то, что HTTP/2 по TLS требует использования ALPN – относительно нового TLS-расширения (RFC 7301), которое помогает согласовывать новую версию HTTP, не теряя ценного времени или обращений к сетевым пакетам.
TLS сам по себе поощряет больше HTTPS
Поскольку браузеры используют HTTP/2 только по TLS (по крайней мере, пока), сайты, которые хотят включить HTTP/2, должны делать это через HTTPS, чтобы получить посещения пользователей. Это обеспечивает мягкое давление на сайты, предлагая HTTPS. Это подталкивает больше людей к сквозному зашифрованному TLS-соединению.
HTTPS обычно считается хорошим дополнением для пользователей, которые обеспокоены правами пользователей на неприкосновенность частной жизни и защиты от массового наблюдения. Рост доли зашифрованного трафика подтверждается, в частности, статистикой Google Transparency Report и Mozilla: согласно открытым данным, доля загрузок страниц по HTTPS в популярных браузерах давно превысила 80 % как глобально, так и для многих регионов (Google Transparency Report, Let’s Encrypt stats).
Почему TLS – не обязательно
Тот факт, что этот протокол не был включен в спецификацию как обязательный, объясняется тем, что не было единого мнения, что это хорошая идея для протокола. Достаточно большая часть участников рабочей группы высказалась против понятия обязательного использования TLS с HTTP/2. TLS раньше не был обязательным, поэтому отправной точкой было отсутствие обязательного TLS, и пока не удалось добраться до другой точки зрения.
Когда я упоминаю об этом в беседах с людьми, сразу возникает вопрос:
Нет, правда, почему TLS – не обязательный протокол?
Аргументы против TLS для HTTP/2 многочисленны. Позвольте мне обратиться к тем, которые я слышу чаще всего, в порядке, который, я думаю, показывает важность аргументов тех, кто их аргументировал.
Редакционный комментарий: ниже перечислены аргументы времён обсуждения стандарта HTTP/2 в рабочей группе IETF HTTPBIS (страница рабочей группы). В современном публичном вебе, по нашему опыту внедрений, большинство из них уже не критичны, но они полезны для понимания контекста решений.
1. Желание проверять HTTP-трафик
Существует заявленная «необходимость» проверять или перехватывать HTTP-трафик по разным причинам. Тюрьмы, школы, антивирусы, защита прав интеллектуальной собственности, требования местного законодательства... С этим также часто связано требование кеширования данных в прокси – таким образом, что вы никогда не сможете установить приличную сеть в самолете или со спутниковой связью. Без кэширования, которое должно выполняться с перехватами.
Конечно, прокси-серверы MITMing, которые прерывают трафик SSL, в наши дни не редкость, и HTTP/2 мало что может сделать для ограничения использования таких механизмов.
Комментарий редакции: сегодня подобные сценарии, по нашему опыту, решаются либо на уровне явных прокси с установкой доверенных корневых сертификатов в управляемых средах (корпоративные сети, учебные заведения), либо через специализированные решения для инспекции TLS‑трафика. Для публичных сайтов это скорее пограничный кейс и не является аргументом против использования TLS в целом.
2. Подумайте о самых маленьких
«Маленькие устройства не могут справиться с дополнительным бременем TLS». Либо из-за дополнительной загрузки ЦП, которая идет с TLS, либо из-за управления сертификатами в миллиарде принтеров / холодильников / маршрутизаторов и т. п. Сертификаты также регулярно истекают и требуют обновления.
Конечно, для приличной работы TLS потребуется наименьшая приемлемая производительность системы, и всегда будут системы, которые опускаются ниже этого порога.
Комментарий редакции: на практике сегодня многие IoT‑устройства используют облегчённые TLS‑стеки и автоматическое управление сертификатами (ACME‑клиенты, встроенные агенты), поэтому аргумент о полной невозможности применения TLS на «маленьких устройствах» частично потерял актуальность. Тем не менее, для ультрабюджетных или энергоограниченных устройств вопрос нагрузки и управления ключами остаётся реальным ограничением.
3. Сертификаты слишком дороги
Стоимость сертификатов для серверов часто приводилась в качестве аргумента против TLS, хотя в действительности это не связано с HTTP/2, и я не думаю, что это был когда-либо аргумент, который был особенно силен против TLS в HTTP/2. В настоящее время некоторые центры сертификации предлагают сертификаты с нулевой или очень низкой стоимостью, и с такими усилиями, которые прилагает letsencrypt.com, есть вероятность, что в ближайшем будущем ситуация поменяется еще в более лучшую сторону.
Недавно кто-то даже заявил, что HTTPS ограничивает свободу пользователей, так как нужно выдать личную информацию, чтобы получить сертификат для сервера. Это была не та цена, которую пользователь готов заплатить. Это, однако, не относится к простейшим видам сертификатов. Для сертификатов с проверкой домена (DV) вам нужно только доказать, что вы каким-то образом «контролируете» данный домен. Обычно нужно иметь возможность получать электронную почту для конкретного получателя в домене.
Комментарий редакции: c тех пор ситуация радикально изменилась. Бесплатные сертификаты с проверкой домена сегодня массово выдаёт Let’s Encrypt и ряд других CA, и такие DV‑сертификаты стали де‑факто стандартом для большинства сайтов. Для DV‑сертификатов не требуется передавать личные данные владельца сайта в привычном смысле — достаточно доказать контроль над доменом (через DNS‑запись, HTTP‑файл или e‑mail), что резко снижает барьер входа.
4. Система CA сломана
Для TLS сегодня требуется система PKI, в которой существуют доверенные центры сертификации, которые подписывают сертификаты, и это приводит к ситуации, когда все современные браузеры доверяют нескольким сотням CA. Я не думаю, что многие люди довольны этим и считают, что это идеальное решение для обеспечения безопасности. В Интернете есть аудитория, которая выступает за DANE (DNSSEC) для решения некоторых частей проблемы, в то время как другие работают над постепенными вспомогательными средствами, такими как прозрачность сертификатов и сшивание OCSP.
Я лично считаю, что отказ от TLS на том основании, что он недостаточно хорош или не совершенен – слабый аргумент. TLS и HTTPS - лучший способ обеспечить безопасность веб-сайтов. Я не возражаю против улучшения его во всех видах, но я не верю, что использование протоколов с открытым текстом до тех пор, пока мы не разработаем и не развернем защищенный протокол следующего поколения, является хорошей идеей. И я думаю, что пройдет много времени, пока мы не увидим замену TLS.
Комментарий редакции: многие из перечисленных здесь механизмов сегодня реально используются. Certificate Transparency стандартизован в RFC 6962, и для публичных сертификатов крупных CA ведение CT‑логов фактически стало обязательным условием со стороны браузеров. OCSP stapling (описан в RFC 6066 и RFC 6960) включается в типовых конфигурациях серверов. DANE (RFC 6698) пока реже встречается в вебе, но показывает себя полезным в нишевых сценариях (например, для почтовых серверов).
Мнение Daniel Stenberg (автор оригинальной статьи): «Я лично считаю, что отказ от TLS на том основании, что он недостаточно хорош или не совершенен – слабый аргумент. TLS и HTTPS — лучший способ обеспечить безопасность веб-сайтов. Я не возражаю против улучшения его во всех видах, но я не верю, что использование протоколов с открытым текстом до тех пор, пока мы не разработаем и не развернем защищенный протокол следующего поколения, является хорошей идеей. И я думаю, что пройдет много времени, пока мы не увидим замену TLS».
Комментарий редакции: с точки зрения текущей практики мы разделяем эту позицию. Практически весь крупный веб уже перешёл на HTTPS; согласно открытым статистикам и нашим наблюдениям на реальных проектах, HTTP без шифрования сохраняется в основном для узкоспециализированных или внутренних задач.
Кто был против внедрения TLS?
Да, многие спрашивают меня об этом, но я не буду называть здесь конкретных людей или компании, поскольку у меня нет планов вступать с ними в споры о деталях и тонкостях в том, как я изображаю их аргументы. Вы можете найти их сами, если захотите, и наверняка сможете делать обоснованные предположения, даже не делая этого.
Комментарий редакции: обсуждения требований к TLS для HTTP/2 велись в открытых рабочих группах IETF HTTPBIS, и их протоколы, черновики и письма доступны в общедоступных архивах (архив рассылки HTTPBIS). Это обычная часть процесса стандартизации, а не закрытые «инсайды».
Как насчет оппортунистической безопасности?
Текст о TLS в HTTP/2 не может быть полным без упоминания этой части. В эти дни в IETF ведется большая работа по внедрению и обеспечению использования оппортунистической безопасности для протоколов. Он также был временно включен в черновик HTTP/2, но был удален из основной спецификации во имя упрощения и потому, что это можно было сделать в любом случае, не будучи частью спецификации. Кроме того, далеко не все считают оппортунистическую безопасность хорошей идеей. Оппоненты говорят, что это будет препятствовать принятию «настоящих» HTTPS для сайтов.
Оппортунистическая безопасность для HTTP теперь реализуется за пределами спецификации HTTP/2 и позволяет клиентам обновлять обычные TCP-соединения, чтобы вместо этого выполнять соединения «без аутентификации TLS». И да: при оппортунистической безопасности никогда не должно быть символа «замка» или чего-либо, что указывало бы на то, что соединение является «безопасным».
Комментарий редакции: в современных браузерах и клиентских приложениях оппортунистическая безопасность встречается относительно редко; вместо этого для повышения защищённости всё шире применяются принудительные политики вроде HSTS, preload‑списки доменов и, для HTTP/3, обязательное шифрование в QUIC. Ключевой момент доверия остаётся неизменным: пользовательский интерфейс не должен вводить в заблуждение и показывать «замок» там, где нет проверки подлинности сервера.
Краткое сравнение HTTP/1.1 + TLS и HTTP/2 + TLS
| Вопрос | HTTP/1.1 + TLS | HTTP/2 + TLS |
|---|---|---|
| Требуемая версия TLS | Может работать на TLS 1.0/1.1/1.2/1.3 (устаревшие версии сейчас не рекомендуются) | Требуется как минимум TLS 1.2, на практике обычно используется TLS 1.2/1.3 |
| Мультиплексирование запросов | Отсутствует, часто используется несколько TCP‑соединений параллельно | Поддерживается мультиплексирование многих запросов в одном соединении |
| Требования к наборам шифров | Менее строгие, возможны устаревшие шифры, если не отключить явно | Более строгие минимальные требования, ориентир на современные шифры с PFS |
| Поддержка браузерами | Поддерживается всеми браузерами, включая очень старые | Поддерживается всеми современными браузерами при работе по HTTPS |
Мини‑алгоритм: как включить HTTP/2 + TLS на сервере
- Проверить, поддерживает ли ваш веб‑сервер (Nginx, Apache, Caddy и др.) HTTP/2 и TLS 1.2/1.3; при необходимости обновить до актуальной версии.
- Получить DV‑сертификат: использовать Let’s Encrypt или другой CA с поддержкой ACME; установить и запустить ACME‑клиент (certbot, acme.sh и аналоги).
- Включить HTTP/2 в конфигурации сервера (для Nginx — параметр
http2в listen‑директиве для 443‑го порта, для Apache — модульmod_http2и соответствующие директивы). - Ограничить набор шифров и протоколов до рекомендуемых: отключить TLS 1.0/1.1, слабые шифры, ориентироваться на профили из Mozilla SSL Configuration Generator.
- Убедиться, что включена поддержка ALPN (обычно она включена по умолчанию при использовании современных версий OpenSSL/BoringSSL/LibreSSL и правильных шифров).
- Проверить конфигурацию с помощью внешних сервисов: тест HTTPS/HTTP2, например, HTTP/2 Test, и проверка уровня безопасности TLS (SSL Labs и аналоги).
Информация об авторе и переводчике
Оригинальный автор: Daniel Stenberg — основным разработчик cURL и libcurl, участник рабочей группы IETF HTTPBIS, принимал непосредственное участие в обсуждении и внедрении HTTP/2.
Перевод и адаптация: редакция Softdroid. Материал адаптирован с учётом опыта настройки HTTP/2 и TLS на веб‑серверах (Nginx, Apache) для коммерческих и высоконагруженных проектов, а также привязан к современному состоянию экосистемы (TLS 1.2/1.3, массовый переход на HTTPS, Let’s Encrypt).
Обязательно ли использовать TLS для HTTP/2 на публичном сайте?
Спецификация HTTP/2 (RFC 7540) не требует TLS, но все современные браузеры включают HTTP/2 только по HTTPS. Поэтому для публичных сайтов TLS де‑факто обязателен, иначе клиенты будут работать по HTTP/1.1 без шифрования или без HTTP/2.
Почему браузеры требуют HTTPS для HTTP/2?
Браузеры изначально решили поддерживать HTTP/2 только поверх TLS, чтобы не усиливать незащищённый трафик и одновременно повысить базовый уровень конфиденциальности и целостности данных. Это решение согласуется с общей тенденцией к повсеместному использованию HTTPS и упрощением получения сертификатов (бесплатные DV‑сертификаты, автоматизация через ACME).
Можно ли использовать HTTP/2 без шифрования во внутренних сетях?
Да, HTTP/2 по чистому TCP допускается спецификацией и используется, например, во внутренних сервисах и специализированных клиентах. Однако такой трафик не будет понят браузерами как HTTP/2, и безопасность соединения придётся обеспечивать другими средствами (сегментация сети, VPN, защитные экраны и т. п.).
Достаточно ли бесплатного DV‑сертификата для HTTPS?
Для большинства сайтов и API‑сервисов бесплатного сертификата с проверкой домена (DV), например от Let’s Encrypt, технически достаточно: он обеспечивает шифрование и проверку владения доменом. Для случаев, где важна юридическая идентификация организации (банки, госуслуги), могут потребоваться OV/EV‑сертификаты, но это требование связано не с HTTP/2, а с политиками доверия конкретных отраслей.
Нужно ли что‑то менять в TLS для перехода на HTTP/2?
Для HTTP/2 требуется как минимум TLS 1.2, актуальная реализация ALPN и отключение некоторых устаревших функций (например, TLS‑сжатия). На практике для новых внедрений рекомендуется сразу включать TLS 1.3 и следовать профильным рекомендациям Mozilla или других авторитетных источников по конфигурации шифров.
