Сегодня использование HTTPS стало практически обязательным для большинства веб‑приложений. Angie позволяет эффективно обрабатывать HTTPS‑трафик, обеспечивая при этом высокий уровень безопасности. В новых протоколах HTTP/2 и HTTP/3 использование защищённого соединения обязательно. Однако, как обычно, есть много деталей в конфигурации, которые мы последовательно разберём в этой статье.

Навигация по циклу

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на Rutube, VKVideo и YouTube.

Базовые принципы работы HTTPS

По сути HTTPS это использование протокола HTTP поверх протокола шифрования трафика — TLS. Исторически за шифрование отвечали различные версии протокола SSL (Secure Sockets Layer), но после версии 3.0 его решили переименовать в TLS (Transport Layer Security).

На сегодня рекомендованы для применения только две версии TLS: 1.2 и 1.3. В протоколе QUIC (транспорт для HTTP/3) используется аналог TLS 1.3. Подробнее про совместимость и возможности протоколов поговорим ниже.

Для нашей задачи важно разделять два этапа работы с HTTPS:

установление соединения;
обмен данными в режиме запрос-ответ.

Первый этап существенно нагружает процессор, так как основан на асимметричном шифровании. Поэтому основная задача — снизить затраты на этом этапе за счет применения современной криптографии и длительного кэширования установленных сессий. Результатом первого этапа будет получение общего ключа шифрования на стороне сервера и клиента для второго этапа. Необходимость создания TLS‑соединения вносит дополнительные задержки, которые можно снизить за счет современных версий протоколов и других оптимизаций. Дополнительная задержка составляет от 1 RTT (Round Trip Time) до 3 RTT. При повторном подключении теоретически возможна ранняя передача данных (early data), фактически 0-RRT handshake.

Второй этап — это основная часть взаимодействия клиента и сервера, в рамках которой передаются все основные данные. На этом этапе используется симметричное шифрование, которое позволяет эффективно шифровать большие объёмы данных. Здесь также нужно настроить надёжный механизм шифрования, который при этом будет иметь высокую производительность.

База работы протокола TLS это инфраструктура открытых ключей (PKI — Public Key Infrastructure). Каждый клиент имеет набор предустановленных публичных ключей (сертификатов) доверенных центров сертификации (CA — Certificate Authority). Для работы серверу будет необходим свой сертификат (и секретный ключ к нему), выпущенный одним из этих CA. Сертификат будет удостоверять, что владелец сервера смог подтвердить управление доменным именем и на этом основании был выпущен сертификат.

Далее мы будем предполагать, что сертификат уже выпущен. Отличительной особенностью Angie является наличие модуля ACME, который полностью решает вопрос автоматического получения и продления сертификатов. Кроме того, есть набор утилит для работы с бесплатным центром сертификации Let»s Encrypt (и другими): Certbot, Acme.sh, Acmebot и т. д.

Прежде чем переходить к настройке протокола TLS, разберём взаимодействие Angie с SSL‑библиотеками.

Версии OpenSSL

Функциональность Angie в рамках TLS сильно зависит от версии используемой SSL‑библиотеки. Если вы используете стандартный пакет Angie из официальных репозиториев, то скорее всего Angie собран с использованием динамической линковки на системную библиотеку OpenSSL. При необходимости использования других версий OpenSSL или форков (LibreSSL, BoringSSL и т. д.) потребуется сборка Angie с указанием параметра ‑with‑openssl.

Далее приведён список возможностей TLS с указанием версий OpenSSL, которые их поддерживают:

TLS версии 1.3 — OpenSSL => 1.1.1;
механизм ALPN (необходим для HTTP/2) — OpenSSL => 1.0.2;
поддержка QUIC — BoringSSL, OpenSSL => 3.5 (для меньших версий — режим совместимости).

Проверить используемую SSL‑библиотеку в Angie можно командой:

angie -V

В результате можно увидеть библиотеку и её версию:

Angie version: Angie/1.9.0
nginx version: nginx/1.27.4
built on Fri, 11 Apr 2025 08:00:48 GMT
built with OpenSSL 3.0.2 15 Mar 2022

По версии библиотеки можно определить доступные возможности для TLS. Итак, пора переходить к практической настройке TLS в Angie.

Общие настройки TLS

Настройку протокола TLS можно условно разделить на две части: общие настройки и конфигурация сайта. Хотя большинство настроек можно вносить на уровне отдельного сайта, обычно имеет смысл в контексте http настроить все общие директивы, а в конфиге сайта прописать только сертификаты, ключи и специфичные настройки. Хорошим стартом для настройки HTTPS может онлайн‑конфигуратор от Mozilla, однако не стоит бездумно копировать оттуда директивы для использования на сервере.

Первое, что нужно настроить — версии протокола, которые будет поддерживать сервер. Определяется список протоколов директивой ssl_protocols, значение по умолчанию:

ssl_protocols TLSv1.2 TLSv1.3;

Это значение подойдёт для большинства применений, но для читаемости и однозначности конфигурации директиву можно добавить на уровне блока http. Версии TLS определяют совместимость с клиентами (браузерами, CLI‑утилитами, другими клиентами на основе библиотек). Примерный список минимальных версий для поддержки TLS 1.2 следующий: Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 (Windows 7), Java 8u31, библиотека OpenSSL 1.0.1, Opera 20, Safari 9. Подробнее поддержку различных протоколов TLS можно на сервисе Caniuse.

Вторая важная настройка: наборы шифров (cipher suites), их выбор будет определять безопасность соединения, совместимость и возможности выбора при согласовании. Набор шифров включает в себя несколько компонентов:

Key exchange — алгоритмы обмена ключами (DH и варианты);
Authentication — варианты аутентификации (сертификат);
Cipher (Bulk data encryption) — основное (симметричное) шифрование трафика;
Message Authentication Code (MAC) — алгоритмы подтверждения целостности сообщений (хеш‑функции).

По умолчанию используется следующая настройка набора шифров:

ssl_ciphers HIGH:!aNULL:!MD5;

Эта настройка будет использовать макрос библиотеки шифрования для надёжных алгоритмов шифрования как для ассиметричной, так и симметричной фаз соединения. Также поддерживаются оба типа сертификатов: RSA и ECDSA.

В этих наборах нет заведомо небезопасных комбинаций, поэтому мы можем не включать приоритет порядка шифров сервера над клиентскими, что позволит более гибко учитывать предпочтения клиента (оставляем дефолтное значение: ssl_prefer_server_ciphers off). В случае использования более широких наборов шифров, рекомендуется включать приоритет порядка указания серверных шифров над клиентскими (ssl_prefer_server_ciphers on).

Однако нужно учитывать, что для версии TLS 1.3 варианты шифров жестко заданы и управление ими для OpenSSL возможно только через директиву ssl_conf_command. Например, так:

ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

Следующий элемент настройки: кэширование TLS-сессий для ускорения повторных подключений клиентов. Angie поддерживает два способа: кэш сессий на стороне сервера (ssl_session_cache) и кэш с помощью сессионных билетов (ssl_session_tickets), которые хранятся на стороне клиента.

Для серверного кэша сессий нужно установить размер зоны памяти, тип (разделяемый, выделенный) и название. Также необходимо увеличить длительность сессии для повышения вероятности попадания в кэш.

ssl_session_cache	 shared:SSL:10m;
ssl_session_timeout 28h;
ssl_session_tickets on;

Указанного размера 10 МБ достаточно для хранения примерно 40000 сессий. Разделяемый кэш (shared) будет общим для всех рабочих процессов, что обеспечит максимальное попадание в кэш. Эффективность кэширования сессий можно мониторить с помощью API или в консоли Angie Console Light (раздел “Серверные зоны” — соотношение “Повторных использований” и “Рукопожатий”).

Дополнительно можно регулировать размер буфера при работе с TLS (ssl_buffer_size). Значение по умолчанию (16k) соответствует минимальным накладным расходам, но если стоит задача минимизировать время получения первых байтов ответа и их расшифровки, то буфер можно уменьшать (настройка доступна в контекстах http и server).

Еще одна настройка для сокращения задержек в случае повторных соединений включает механизм Early Data в TLS 1.3.

ssl_early_data on;

При использовании этого расширения клиент может отправлять полезные данные сразу во время установления соединения (0-RTT handshake). Однако, использование этого метода может быть опасно — возможны атаки повторного воспроизведения запросов (replay attack).

По умолчанию Angie для обработки HTTPS использует SSL‑библиотеку, указанную при сборке, то есть в пользовательском пространстве. Но существует способ подключить специальный модуль ядра и передать ему работу по шифрованию трафика. Поддержка kTLS появилась в Linux 4.13, но рекомендуется версия не ниже 5.2. Основным преимуществом такого подхода будет возможность использования механизма sendfile (SSL_sendfile) для HTTPS‑сайтов. Применение sendfile полезно для передачи статических файлов или кэшированных элементов.

Сравнение производительности на ядре 6.8 и OpenSSL 3.0.2 показывает преимущество kTLS с sendfile перед обычным режимом около 20% при использовании AES-256-GCM. В тесте производились запросы к файлу размером 1 ГБ с использованием TLS 1.3. Однако, не стоит использовать kTLS с HTTP/2 — из‑за особенностей работы протокола включение kTLS приводит к деградации производительности около 40–50%.

Конфигурация сайта

Для настройки HTTPS‑сайта достаточно указать сокет, сертификат и ключ. Дополнительно можно включить поддержку протоколов HTTP/2 и HTTP/3.

В Angie поддерживается одновременная конфигурация RSA и ECDSA‑сертификатов. Сегодня RSA сертификаты стоит использовать только для совместимости. Практически все клиенты поддерживают ECDSA (не поддерживают Android <= 5.0, IE 11 Win7–8.1, Safari < 9), поэтому можно использовать их как единственный вариант. RSA‑сертификаты обладают еще более широкой поддержкой у клиентов, но создают гораздо большую нагрузку на сервер при подключении. При указании обоих типов современные клиенты будут использовать ECDSA, что и требуется.

Конфигурация будет выглядеть приблизительно так:

server {
  listen 443 ssl;
  http2 on;

  server_name example.com www.example.com;

  ssl_certificate      /etc/ssl/certs/1.ru.rsa.pem;
  ssl_certificate_key  /etc/ssl/private/1.ru.rsa.key;
  ssl_certificate      /etc/ssl/certs/1.ru.ecdsa.pem;
  ssl_certificate_key  /etc/ssl/private/1.ru.ecdsa.key;

  add_header Strict-Transport-Security "max-age=63072000" always;
}

Здесь мы подключили для сайта HTTPS с поддержкой HTTP/2, указали две пары директив для сертификата (ssl_certificate) и ключа (ssl_certificate_key). Если вы собираете файл с цепочкой сертификатов самостоятельно, важно соблюдать порядок сертификатов в файла: от частного к общему. То есть сначала в файле будет сертификат для домена, далее промежуточный сертификат CA, далее более высокоуровневый сертификат CA и т.д. При этом сертификаты корневого уровня (root) указывать не нужно — они уже есть на устройстве клиента.

Также для сайта установлен заголовок HSTS (HTTP Strict Transport Security), который будет инструктировать браузеры использовать только HTTPS для доступа к этому сайту. Осторожно: заголовок имеет большой срок действия и жестко кэшируется на стороне браузера, поэтому устанавливать его нужно только если вы полностью уверены, что HTTP-доступ больше не понадобится.

Для поддержки протокола HTTP/3 потребуется указать дополнительный сокет и директиву http3. Например, так:

server {
  listen 443 ssl;
  listen 443 quic reuseport;
  http2 on;
  http3 on;

  server_name example.com www.example.com;
  add_header Alt-Svc 'h3=":443"; ma=86400';
  add_header Strict-Transport-Security max-age=31536000;
}

В примере выше можно заметить, что у директивы listen для протокола quic (транспорт для HTTP/3) указан параметр reuseport. Этот параметр можно указывать только один раз для каждого сокета, он используется распределения пакетов между рабочими процессами, а в нашем случае — необходим для работы с HTTP/3. Кроме того, добавляется заголовок Alt-Svc, который даст браузеру знать о поддержке HTTP/3 со стороны сервера на 443 порту UDP. После этого, браузер попробует создать QUIC‑подключение и перейти на HTTP/3 (а также запомнит поддержку h3 на сутки: ma=86400). Поэтому, при обычной сессии работы с сервером первые запросы будут отправлены по HTTP/2 и только последующие будут использовать HTTP/3. Существует и второй метод переключения на HTTP/3 — с помощью DNS‑записей типа HTTPS, о которых мы поговорим позже. Заголовок Alt-Svc не требуется для всех ресурсов, поэтому его можно подключить только при выдаче динамических документов (например, в location /).

Директивы ssl_certificate и ssl_certificate_key поддерживают переменные. При использовании переменных есть смысл воспользоваться директивой ssl_certificate_cache, которая позволит кэшировать сертификаты указанные таким образом. Пример конфигурации:

server {
  ssl_certificate       $ssl_server_name.crt;
  ssl_certificate_key   $ssl_server_name.key;
  ssl_certificate_cache max=1000 inactive=20s valid=1m;
}

Логичный шаг после успешной настройки HTTPS — безусловное перенаправление всех запросов с HTTP на HTTPS, проще всего это сделать в отдельном блоке server:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request_uri;
}

С такой конфигурацией все запросы на HTTP будут перенаправлены на фиксированный домен с сохранением адреса и GET‑параметров запроса.

После внесения изменений в конфигурацию не забываем выполнить:

angie -t

Для тестирования подключения можно использовать стандартную утилиту curl, а для подробностей задействовать клиента openssl:

openssl s_client -servername test.ru -connect test.ru:443

Эта команда будет создавать подключение с расширением SNI (Server Name Indication), то есть максимально похоже на реальный браузер. В выводе можно увидеть свойства сертификата и согласованные параметры TLS.

Чтобы посмотреть свойства сертификата на диске можно также использовать openssl:

openssl x509 -text -noout -in unk.crt

Конечно, можно использовать средства разработчика браузера для просмотра свойств TLS‑подключения. Также полезно использовать онлайн-тесты (например, SSLlabs), которые позволяют протестировать совместимость сервера за счет эмуляции разнообразных клиентов, а также указывают потенциальные проблемы в конфигурации (уязвимости, слабые шифры, проблемы с цепочкой сертификатов и т. д.)

HTTPS-записи в DNS

Помимо настройки сервера, мы можем использовать систему DNS для тонкой настройки HTTPS. Для этих задач разработаны специальные записи типа HTTPS, содержащие информацию о поддерживаемых протоколах и адресах в рамках домена. Например, поддержку протокола HTTP/3 можно декларировать через такую запись в DNS:

example.com 3600 IN HTTPS 1 . alpn=”h3,h2”

Итоги

В статье затронуты основные вопросы настройки TLS в веб‑сервере Angie. За пределами повествования остался вопрос получения сертификатов, который логично разобрать отдельно, с учетом наличия модуля ACME в Angie. Надеюсь, статья была вам полезна, дополнения и уточнения можно писать в комментариях.

Следующая статья цикла: Настройка Angie в роли обратного HTTP-прокси.

Настройка TLS в Angie: безопасность и скорость