Набор шифров (cipher suite).

Набор шифров определяет связку алгоритмов, которую защищённый протокол использует для защиты сессии. В TLS 1.2 (RFC 5246) набор вида TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 выбирает ECDHE для обмена ключами, RSA для аутентификации, AES-128-GCM для шифрования и SHA-256 для PRF. TLS 1.3 (RFC 8446) упростил модель, согласуя обмен ключами и подписи отдельно от AEAD: осталось всего пять наборов (например, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256), и каждый из них обеспечивает прямую секретность (forward secrecy).

Почему унаследованные наборы опасны. Слабые наборы породили целое десятилетие практических атак. RC4 был официально запрещён в TLS документом RFC 7465 после того, как смещения в его потоке ключей позволили восстанавливать открытый текст. 3DES и другие блочные шифры с 64-битным блоком уязвимы к атаке «дней рождения» Sweet32 (CVE-2016-2183), которая восстанавливает открытый текст примерно после 32 ГБ трафика на одном ключе. Криптография экспортного уровня сделала возможными FREAK (CVE-2015-0204) и Logjam, понижавшие соединения до взламываемых 512-битных RSA и Diffie-Hellman. Анонимные наборы (aDH/aECDH) полностью опускают аутентификацию и открывают путь для активного перехвата.

Усиление защиты (hardening). Отключите RC4, 3DES, экспортные и анонимные наборы, а также обмен ключами на статическом RSA; предпочитайте наборы AEAD с ECDHE (или значения по умолчанию TLS 1.3). Такие инструменты, как Qualys SSL Labs, testssl.sh, а также конфигурационные профили Mozilla, NIST SP 800-52r2 и немецкого BSI, закрепляют безопасные значения по умолчанию.

flowchart TD
  A[Client Hello:<br/>предложенные наборы шифров] --> B[Сервер выбирает один набор]
  B --> C[Обмен ключами<br/>ECDHE / RSA]
  C --> D[Аутентификация<br/>подпись сертификата]
  D --> E[Шифрование данных<br/>AES-GCM / ChaCha20]
  E --> F[Целостность<br/>тег AEAD / HMAC]
  F --> G[Защищённая сессия]