HTTP, HTTPS и TLS: Часть 5 — Версии TLS, шифронаборы, SNI, ALPN, ECH и mTLS

Под словами «тип TLS» обычно имеют в виду разные вещи: версию протокола (1.2 или 1.3), набор алгоритмов шифрования, вид сертификата (DV, OV, EV) или схему, где сертификат предъявляет и клиент (mTLS). В этой части — все четыре, плюс расширения ClientHello, от которых зависит, какой сайт и какой протокол получит клиент: SNI, ALPN и ECH.

Версии протокола

Браузеры отключили TLS 1.0 и 1.1 в 2020 году. На сервере сегодня включают TLS 1.2 и 1.3. Оставлять только 1.3 можно, если среди клиентов нет старого оборудования и программ: Android до 10-й версии, Java 8 без обновлений, старые версии .NET, встроенные клиенты касс и терминалов умеют только 1.2.

Шифронабор

Шифронабор (cipher suite) — сочетание алгоритмов, о котором договариваются клиент и сервер. В TLS 1.2 имя описывает всё сразу:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     │     │        │           └ хеш для вывода ключей
     │     │        └ шифр данных и режим (AEAD)
     │     └ алгоритм подписи сертификата
     └ обмен ключами

В TLS 1.3 обмен ключами и подпись вынесены в отдельные расширения, а шифронабор описывает только шифр и хеш. Их всего пять, и все безопасны:

• TLS_AES_128_GCM_SHA256;
• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256 — быстрее AES на процессорах без аппаратного ускорения AES, например на части ARM;
• TLS_AES_128_CCM_SHA256 и TLS_AES_128_CCM_8_SHA256 — для встраиваемых устройств, в вебе не используются.

Для TLS 1.2 нужно оставить только наборы с обменом ключами ECDHE (прямая секретность) и шифрами AEAD — GCM или ChaCha20-Poly1305. Отключить:

• обмен ключами RSA (TLS_RSA_WITH_...) — нет прямой секретности;
• шифры в режиме CBC — источник атак вроде Lucky13;
• RC4, 3DES, NULL, EXPORT, анонимные наборы.

Обмен ключами и постквантовая криптография. Группы для обмена ключами — x25519, secp256r1, secp384r1. С конца 2024 года Chrome, а затем Firefox и Safari по умолчанию предлагают гибридную группу X25519MLKEM768: классический X25519 вместе с постквантовым алгоритмом ML-KEM. Смысл в защите от сценария «записать сейчас, расшифровать потом», когда трафик сохраняют в расчёте на будущий квантовый компьютер. OpenSSL поддерживает её с версии 3.5 (2025). Ключ ClientHello с этой группой больше 1 КБ и не помещается в один TCP-пакет — некоторые старые межсетевые экраны и балансировщики на этом ломаются.

Готовая настройка для Nginx

Не подбирайте шифры вручную. Mozilla поддерживает генератор конфигураций (ssl-config.mozilla.org) с тремя профилями: modern (только TLS 1.3), intermediate (TLS 1.2 и 1.3, рекомендуется для большинства сайтов) и old (для совместимости с очень старыми клиентами). Профиль intermediate для Nginx выглядит примерно так:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

ssl_ciphers действует только на TLS 1.2: шифронаборы TLS 1.3 в OpenSSL настраиваются отдельно, и значения по умолчанию подходят. ssl_prefer_server_ciphers off отдаёт выбор клиенту — все оставленные наборы безопасны, а клиент лучше знает, есть ли у него аппаратный AES.

Проверить результат можно сервисом SSL Labs (ssllabs.com/ssltest) или локально — утилитой testssl.sh, которая работает и для внутренних адресов.

SNI

SNI (Server Name Indication, RFC 6066) — расширение ClientHello, в котором клиент открытым текстом пишет имя сайта. Без него сервер с несколькими сайтами на одном IP не знает, какой сертификат отдать: рукопожатие идёт раньше, чем приходит заголовок Host.

Что важно знать:

• в Nginx сертификат выбирается по server_name в соответствии с SNI; если SNI нет или имя неизвестно, отвечает default_server для этого listen — и клиент получает чужой сертификат;

• чтобы не раскрывать сертификаты других сайтов на запрос по IP, заведите пустой сервер по умолчанию, который обрывает рукопожатие:

  nginx Copy

  server {
      listen 443 ssl default_server;
      ssl_reject_handshake on;   # Nginx 1.19.4+
  }

• SNI — главный признак, по которому оборудование DPI определяет, на какой сайт идёт трафик, и блокирует его;

• IP-адреса в SNI не передаются: при обращении https://192.0.2.10/ поле пустое.

ALPN

ALPN (Application-Layer Protocol Negotiation, RFC 7301) — расширение, в котором клиент перечисляет протоколы, а сервер выбирает один: h2, http/1.1, h3 для QUIC. Так договариваются о HTTP/2 без лишних кругов обмена. ALPN используют и другие протоколы поверх TLS: acme-tls/1 для проверки домена Let’s Encrypt методом TLS-ALPN-01, dot для DNS-over-TLS.

ECH

SNI и ALPN идут в ClientHello открытым текстом. Расширение ECH (Encrypted Client Hello, RFC 9849, март 2026) шифрует их ключом, который сервер публикует в DNS-записи типа HTTPS, — наблюдатель видит только общее имя провайдера. Как ECH устроен, где работает и почему в России соединения с ним блокируются, разобрано в статье «Что такое ECH».

Виды сертификатов: DV, OV, EV

Разница только в том, что проверил удостоверяющий центр перед выдачей, — шифрование у всех одинаковое.

• DV (Domain Validation) — проверено только управление доменом: файл на сайте (HTTP-01) или запись в DNS (DNS-01). Выдаётся автоматически за минуты. Let’s Encrypt, ZeroSSL, Google Trust Services выдают только DV — и этого достаточно для любого сайта.
• OV (Organization Validation) — дополнительно проверена организация. Название компании видно в деталях сертификата, но браузер никак его не выделяет.
• EV (Extended Validation) — расширенная проверка. Раньше браузеры показывали название компании зелёным в адресной строке, с 2019 года этого не делают. Преимуществ для пользователя EV больше не даёт.

Отдельно по охвату имён: однодоменный, мультидоменный (несколько имён в SAN) и wildcard (*.example.ru). Wildcard у Let’s Encrypt выпускается только через проверку DNS-01.

Российские сертификаты. С 2022 года Минцифры выпускает сертификаты для российских сайтов от собственного удостоверяющего центра (Russian Trusted Root CA). Этого корня нет в хранилищах Chrome, Firefox и Safari; его поддерживают Яндекс Браузер и Атом, в других браузерах и в ОС корень нужно устанавливать вручную. Отдельно существует TLS на российских алгоритмах ГОСТ — он используется в государственных системах и требует сертифицированных криптосредств на обеих сторонах.

mTLS: сертификат у клиента

В обычном HTTPS сертификат предъявляет только сервер. При взаимной аутентификации (mutual TLS, mTLS) сервер запрашивает сертификат и у клиента и пропускает только тех, чей сертификат подписан доверенным CA. Применяется для доступа к административным панелям, связи между микросервисами, приёма вебхуков, API для партнёров.

Настройка в Nginx:

server {
    listen 443 ssl;
    server_name admin.example.ru;

    ssl_certificate     /etc/letsencrypt/live/admin.example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/admin.example.ru/privkey.pem;

    ssl_client_certificate /etc/nginx/client-ca.crt;  # CA, выпускающий клиентские сертификаты
    ssl_verify_client on;                             # optional — пускать и без сертификата
    ssl_verify_depth 2;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Client-DN $ssl_client_s_dn;
    }
}

Выпустить свой CA и клиентский сертификат:

# CA
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout client-ca.key -out client-ca.crt -days 3650 -subj "/CN=Example Client CA"

# ключ и запрос клиента
openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout ivanov.key -out ivanov.csr -subj "/CN=ivanov"

# подпись запроса
openssl x509 -req -in ivanov.csr -CA client-ca.crt -CAkey client-ca.key \
  -CAcreateserial -out ivanov.crt -days 365

Проверка:

curl https://admin.example.ru/                                   # 400 No required SSL certificate was sent
curl --cert ivanov.crt --key ivanov.key https://admin.example.ru/ # 200

Для браузера сертификат упаковывают в PKCS#12: openssl pkcs12 -export -in ivanov.crt -inkey ivanov.key -out ivanov.p12 — и импортируют в систему.

Клиентскому CA не нужно быть публичным, наоборот: если указать в ssl_client_certificate публичный CA, пройдёт любой, кто купит у него сертификат. Для отзыва клиентских сертификатов — ssl_crl. Если перед Nginx стоит CDN или балансировщик, который сам принимает TLS, mTLS нужно настраивать на нём.

Типичные ошибки

• TLS 1.0 и 1.1 остались включены «для совместимости» — сканеры безопасности и требования PCI DSS отмечают это как уязвимость.
• В конфиге длинный список шифров, скопированный десять лет назад, с CBC и RSA-обменом — используйте генератор Mozilla.
• Нет пустого default_server с ssl_reject_handshake — по запросу к IP-адресу сканеры получают сертификат со всеми вашими доменами.
• Wildcard-сертификат копируется на десятки серверов — компрометация одного раскрывает все поддомены. Лучше отдельные сертификаты через ACME.
• mTLS с ssl_verify_client optional без проверки $ssl_client_verify в приложении — клиент без сертификата проходит.