Вопрос «AES‑GCM против ChaCha20‑Poly1305» регулярно всплывает у админов и девопсов — то на ревью настроек Nginx/HAProxy, то при миграции на новые процессоры. К 2025 году картина стала стабильнее: TLS 1.3 везде, HTTP/3 на подъёме, аппаратное ускорение AES распространено на серверных amd64 и большинстве arm64 платформ. Но нюансов меньше не стало — особенно если у вас смешанный парк клиентов (десктоп, Android, старые устройства) и разные типы серверов (от классических Xeon до Graviton/Ampere).
Коротко: кто быстрее и когда
Если крайне кратко и прикладно:
- amd64 с AES‑NI (фактически все современные серверные CPU): AES‑GCM заметно быстрее ChaCha20‑Poly1305, особенно на новых поколениях с ускорениями для умножения в поле (PCLMULQDQ) и расширенными векторными инструкциями.
- arm64 с ARMv8 Crypto Extensions (AES+PMULL) — Neoverse N1/N2/V1/V2, Ampere, Graviton: AES‑GCM обычно сравним или быстрее ChaCha20‑Poly1305. На многих чипах отставание ChaCha20 минимально, но чаще AES‑GCM лидирует.
- Без аппаратного AES (старый ARM, часть мобильных): ChaCha20‑Poly1305 выигрывает в разы по пропускной способности и энергоэффективности.
Итог: на сервере включайте и AES‑GCM, и ChaCha20‑Poly1305. В TLS 1.3 клиент выбирает шифр, и это почти всегда приводит к оптимальному выбору для его CPU. В TLS 1.2 можно сохранить приоритет AES‑GCM, не ломая совместимость.
Что изменилось к 2025 году
Несколько важных трендов, влияющих на выбор шифров:
- TLS 1.3 — по умолчанию. Большая часть браузеров и серверов «живёт» на TLS 1.3. В нём шифры ограничены и современны: AES‑GCM (128/256) и ChaCha20‑Poly1305 (плюс CCM‑варианты, но они почти не встречаются в браузерах).
- Детектирование возможностей CPU на клиенте. Браузеры выбирают порядок шифров с учётом наличия аппаратного AES. На десктопе с AES‑NI первым будет AES‑GCM, на слабом ARM — ChaCha20‑Poly1305.
- arm64 в проде — норма. Большинство облачных arm64 (Graviton, Ampere) имеют Crypto Extensions, поэтому AES‑GCM там смотрится отлично и часто лидирует.
- HTTP/3 (QUIC). Всегда на TLS 1.3; состав шифров тот же, что и для TCP/TLS 1.3, картина производительности аналогична.
Криптофон: чем принципиально отличаются AES‑GCM и ChaCha20‑Poly1305
Оба — AEAD (Authenticated Encryption with Associated Data), то есть дают целостность и конфиденциальность одновременно, без отдельного MAC:
- AES‑GCM — блочный шифр AES в режиме GCM с аутентификацией на базе умножений в поле Галуа. Прекрасно масштабируется с аппаратными ускорениями:
AES‑NI,PCLMULQDQна amd64,AES/PMULLна arm64. - ChaCha20‑Poly1305 — потоковый шифр (ChaCha20) плюс Poly1305‑MAC, хорошо оптимизируется в софте и менее критичен к особенностям кэшей и конвейеров. На CPU без AES‑NI часто заметно быстрее AES‑GCM.
В TLS 1.3 главенствует трио: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. Формально RFC включает ещё CCM‑варианты, но в вебе они редкость, а по производительности для массовых сценариев уступают.
amd64: от AES‑NI к ускоренным реализациям GCM
На x86_64 с AES‑NI AES‑GCM обычно быстрее ChaCha20‑Poly1305 уже много лет. С новыми микроархитектурами ускоряется и сам GCM за счёт улучшений в перемножениях в поле и векторных путях. Дополнительно:
- На загруженных фронтах с TLS‑терминацией ускорение AES‑GCM снижает CPU per connection и tail‑latency.
- При большом объёме статического трафика (CDN/медиа) AES‑GCM даёт экономию энергопотребления на байт, что важно в облаках.
Практика: на современных amd64 серверные OpenSSL 3.x сборки используют быстрые реализации AES‑GCM; в типичных нагрузках вы получите от +30% до многократного выигрыша над ChaCha20‑Poly1305, особенно при больших буферах.
arm64: Crypto Extensions меняют баланс
На arm64 исторически ChaCha20‑Poly1305 был фаворитом на дешёвых и мобильных CPU без ускорений. Но в облаке и на современных SoC почти всегда есть ARMv8 Crypto Extensions:
- Neoverse N1/N2/V1/V2, Ampere Altra/Max, AWS Graviton имеют
AESиPMULL, что «раскрывает» AES‑GCM. - В реальных стендах AES‑GCM часто равен или опережает ChaCha20‑Poly1305, хотя отрыв обычно меньше, чем на x86_64 с AES‑NI.
- На старом ARM без Crypto Extensions ChaCha20‑Poly1305 остаётся лучшим выбором.
Хотите быстро попробовать arm64 под веб‑нагрузкой — поднимите стенд на VDS и сравните профили CPU/latency на своих сервисах. Для практического бэкграунда по ARM см. также замеры PHP/Node на ARM VDS.
OpenSSL vs BoringSSL: кто за что отвечает
В контексте веб‑серверов и балансировщиков:
- OpenSSL 1.1.1/3.x — де‑факто стандарт для Nginx и HAProxy в дистрибутивах. Быстрые пути AES‑GCM есть на amd64 и arm64. Конфигурирование TLS 1.3 шифров в Nginx делается через
ssl_conf_command. - BoringSSL — используется в браузерах и ряде проектов; серверные сборки Nginx на BoringSSL встречаются реже. BoringSSL агрессивнее оптимизирует и динамически учитывает возможности CPU на клиентской стороне.
Ключевая мысль: в TLS 1.3 клиент задаёт порядок шифров. Сервер не может «переприоритизировать» его, в отличие от TLS 1.2. Поэтому на сервере важно просто включить весь «здоровый» набор (AES‑GCM и ChaCha20‑Poly1305) и дать клиенту выбрать оптимум.
Практические рекомендации по наборам шифров на 2025 год
- TLS 1.3: включить
TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_256_GCM_SHA384. Не включать CCM для веб‑клиентов, если нет спец‑требований. - TLS 1.2: держать только современные AEAD:
ECDHE‑ECDSA‑AES128‑GCM‑SHA256,ECDHE‑RSA‑AES128‑GCM‑SHA256, далее ChaCha20‑Poly1305 варианты, затем AES‑256‑GCM. Включить приоритет сервера. - AES‑128 vs AES‑256: в большинстве случаев AES‑128‑GCM быстрее и достаточно безопасен. AES‑256‑GCM — для политик, где это обязательно; держите его после AES‑128 и ChaCha20.
- Отключить: CBC, 3DES, RC4 и прочее наследие. В вебе им не место.
Nginx: безопасные пресеты для OpenSSL
Ниже — аккуратный базовый набор. Обратите внимание: ssl_prefer_server_ciphers on влияет только на TLS 1.2. Для TLS 1.3 используется ssl_conf_command с Ciphersuites.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:TLS:50m;
ssl_session_timeout 10m;
ssl_session_tickets off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;
ssl_ecdh_curve X25519:P-256;
Для сборок на BoringSSL синтаксис ssl_conf_command может отличаться; по умолчанию там и так активны три шифра TLS 1.3.
HAProxy: настраиваем TLS 1.2 и TLS 1.3
В HAProxy различаются параметры для 1.2 и 1.3 — это удобно и прозрачно.
global
ssl-server-verify none
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
ssl-default-bind-options prefer-server-ciphers no-sslv3 no-tls-tickets
frontend https-in
bind :443 ssl crt /etc/haproxy/certs/example.pem alpn h2,http/1.1
default_backend app
HTTP/3 (QUIC): что учесть
HTTP/3 всегда использует TLS 1.3, состав шифров тот же. Для слабых ARM‑клиентов (часть мобильного сегмента) ChaCha20‑Poly1305 часто будет выбран клиентом, а для десктопа с AES‑NI — AES‑GCM. На сервере достаточно держать весь набор; каких‑то особых QUIC‑исключений по шифрам нет. Подробно о практической стороне см. терминация HTTP/3 (QUIC) в HAProxy.
Производительность на практике: где «бутылочное горлышко»
Важно помнить: шифр влияет на симметричную часть TLS, но не на стоимость рукопожатия. В реальных сценариях задержки и CPU уходят в:
- ECDHE (P‑256/X25519) в рукопожатии;
- проверку сертификата у клиента и OCSP у сервера (если включён stapling, он помогает);
- алгоритм подписи (ECDSA быстрее RSA на современных CPU).
Когда соединений много и они длинные (HTTP/2/3, keepalive), именно скорость AEAD‑шифра на больших блоках определяет утилизацию CPU и энергопотребление. Здесь на amd64/arm64 с ускорениями AES‑GCM чаще фаворит. Если вам нужно быстро оформить выпуск и продление, используйте SSL‑сертификаты с OCSP stapling на фронтах.
Как корректно замерять: OpenSSL speed
Быстрый способ сравнить шифры на конкретном сервере — встроенный бенчмарк. Он не идеален, но даёт ориентир:
# Проверить версию и сборку
openssl version -a
# Сравнить AEAD на вашей платформе
openssl speed -evp aes-128-gcm -evp aes-256-gcm -evp chacha20-poly1305
# Оценить влияние размера буферов (пример 16К)
openssl speed -evp aes-128-gcm -bytes 16384
openssl speed -evp chacha20-poly1305 -bytes 16384
Сравнивайте не только «шифры в вакууме», но и профиль реального трафика: доли коротких ответов и крупных отдач, долю мобильных клиентов, наличие TLS‑терминации для gRPC/HTTP/2/3.
Мониторинг: фиксируем выбранный шифр в логах
Nginx
log_format tls '$remote_addr $host $request_method $uri $status $body_bytes_sent TLSv=$ssl_protocol cipher=$ssl_cipher';
access_log /var/log/nginx/tls.log tls;
HAProxy
defaults
mode http
option httplog
log-format '%ci:%cp [%t] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta TLSv=%[ssl_fc_protocol] cipher=%[ssl_fc_cipher] alpn=%[ssl_fc_alpn]'
С недельной выдержкой логи дадут реальную картину: доля TLS 1.2 против 1.3, какой шифр выбирается клиентами, есть ли «хвосты» со старыми стеками.
Частые вопросы
Нужно ли навязывать ChaCha20‑Poly1305 на сервере?
В TLS 1.3 — нет, клиент решает. В TLS 1.2 принудительно ставить ChaCha20 первым на серверах с AES‑аппаратным ускорением обычно невыгодно: вы ухудшите производительность для большинства клиентов, у которых AES быстрый. Лучше оставить AES‑GCM первым и держать ChaCha20 как отличную альтернативу.
AES‑128‑GCM против AES‑256‑GCM
Разница в безопасности для веб‑трафика при корректных параметрах несущественна, а вот разница в скорости — есть. Типовой порядок: AES_128_GCM, затем CHACHA20_POLY1305, затем AES_256_GCM. Если политика требует «только 256», будьте готовы к росту CPU и задержек.
Есть ли смысл включать CCM?
Обычно — нет. Браузерная поддержка слабая, производительность хуже. Для IoT/DTLS‑кейсов — отдельная история, но это вне веб‑фронтов.
Что с HTTP/3 и 0‑RTT?
0‑RTT влияет на семантику и безопасность повторов, но не меняет сравнение AES‑GCM и ChaCha20‑Poly1305. В HTTP/3 используйте тот же набор шифров TLS 1.3.
План внедрения и проверки
- Аудит текущего стека: версии Nginx/HAProxy, OpenSSL; включены ли TLS 1.3, H2/H3; какие шифры активны.
- Приведение к базовой политике: включить три шифра TLS 1.3; в TLS 1.2 оставить только GCM и ChaCha20; включить приоритет сервера.
- Микробенчмарки:
openssl speedна ваших amd64/arm64 узлах, на разных типах инстансов. - Canary‑включение: раскатить пресеты на часть фронтов, следить за CPU, p95/p99, ошибками TLS.
- Наблюдаемость: добавить поля TLS в логи и дашборды; проверить долю старых клиентов на TLS 1.2 и их шифры.
- Оптимизация: если доля слабых клиентов велика, убедиться, что ChaCha20‑Poly1305 доступен. Если почти все — современные, убедиться, что AES‑GCM не ограничен конфигом и сборкой.
Выводы
В 2025 году «соревнование» во многом решено железом и клиентским стеком. На серверных amd64 и arm64 с ускорениями AES‑GCM обычно быстрее и экономичнее, а ChaCha20‑Poly1305 остаётся необходимым для части мобильных и устаревших устройств. Лучшее решение — включать оба и позволить TLS 1.3 клиентам выбирать оптимальный шифр. В TLS 1.2 сохраняем приоритет AES‑GCM, не забывая про ChaCha как надёжную страховку совместимости. Если строите новый фронт или переносите сервисы, проверьте пресеты, метрики и профиль клиентов — это даст и ниже CPU, и ровнее хвосты задержек без компромиссов по безопасности.
