Наборы шифров TLS с названиями в OpenSSL, GnuTLS и NSS

TLS_NULL_WITH_NULL_NULL

Набор-заглушка соединения до завершения первого рукопожатия: без обмена ключами, без аутентификации и без защиты.

TLS_NULL_WITH_NULL_NULL (0x00,0x00) описывает начальное состояние соединения TLS 1.2 (RFC 5246, § 6.1). Он никогда не согласуется: если сервер выбирает этот набор, значит, в его реализации серьёзная ошибка.

TLS_RSA_WITH_RC4_128_SHA

RC4 с SHA-1 и передачей ключа через RSA; когда-то его часто выбирали для защиты от BEAST, теперь он запрещён RFC 7465.

RC4 не был подвержен атакам на CBC 2011–2013 годов и по этой причине недолго был рекомендован, но смещения в его ключевом потоке позволяют злоумышленникам восстанавливать открытый текст, который передаётся многократно, например cookie. Согласно RFC 7465, § 2, клиентам запрещено (MUST NOT) включать наборы RC4 в ClientHello, а серверам — выбирать их.

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Набор, обязательный для реализации в TLS 1.1; из-за 64-битных блоков он уязвим к атаке «дней рождения» Sweet32.

Согласно RFC 4346, § 9, реализации TLS 1.1 были обязаны поддерживать TLS_RSA_WITH_3DES_EDE_CBC_SHA (в OpenSSL — DES-CBC3-SHA). У Triple DES 64-битные блоки, поэтому примерно после 2^32 блоков на одном ключе коллизии раскрывают открытый текст; так атака Sweet32 в 2016 году восстанавливала HTTP-cookie из долгоживущих соединений.

Кроме того, у него нет прямой секретности. Современные библиотеки отключают его по умолчанию, а IANA помечает как нежелательный (Discouraged).

TLS_RSA_WITH_AES_128_CBC_SHA

Набор, обязательный для реализации в TLS 1.2; у него нет прямой секретности, он использует CBC, и теперь RFC 10015 его запрещает.

Согласно RFC 5246, § 9, каждая реализация TLS 1.2 была обязана поддерживать TLS_RSA_WITH_AES_128_CBC_SHA (в OpenSSL — AES128-SHA), поэтому для многих старых клиентов это последний запасной набор. При передаче ключа через RSA (RSA key transport) клиент шифрует предварительный секрет (premaster secret) ключом из сертификата сервера: любой, кто позже получит этот ключ, сможет расшифровать все записанные сеансы.

Режим CBC со схемой MAC-then-encrypt сделал его уязвимым к атакам на оракул дополнения (padding oracle), таким как Lucky Thirteen. Теперь, согласно RFC 10015, § 4, клиентам запрещено (MUST NOT) предлагать, а серверам — выбирать наборы с обменом ключами RSA в TLS 1.2.

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Сигнальное значение, а не настоящий набор: клиент поддерживает безопасное повторное согласование (RFC 5746).

Клиенты добавляют TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) в список наборов шифров, чтобы сообщить о поддержке безопасного повторного согласования, не отправляя расширение. Это значение появилось в RFC 5746, § 3.3, потому что некоторые серверы неправильно обрабатывали расширения; его «нельзя согласовать». Исправление повторного согласования закрыло атаку 2009 года, в которой злоумышленник вставлял собственные данные перед повторно согласованным сеансом клиента.

TLS_AES_128_GCM_SHA256

Набор шифров, который обязана поддерживать каждая реализация TLS 1.3: AES-128 в режиме GCM и SHA-256 для вывода ключей.

Согласно RFC 8446, § 9.1, поддержка TLS_AES_128_GCM_SHA256 обязательна для любой реализации TLS 1.3, и RFC 9846, который пришёл ему на смену, сохраняет это требование. В TLS 1.3 набор задаёт только AEAD и хеш-функцию для HKDF; обмен ключами (например, X25519MLKEM768) и подпись (например, ecdsa_secp256r1_sha256) согласуются в отдельных расширениях.

В OpenSSL наборы TLS 1.3 настраиваются параметром -ciphersuites, а не строкой -cipher, которая служит для TLS 1.2. Поэтому изменение списка шифров на сервере часто никак не затрагивает TLS 1.3.

TLS_AES_256_GCM_SHA384

AES-256-GCM с SHA-384 — один из двух наборов TLS 1.3, которые, согласно RFC 8446, реализациям следует (SHOULD) поддерживать.

TLS_AES_256_GCM_SHA384 сочетает 256-битный ключ AES с SHA-384 при выводе ключей. Согласно RFC 8446, § 9.1, его, как и TLS_CHACHA20_POLY1305_SHA256, следует (SHOULD) поддерживать; его предлагает большинство серверов, а профили, соответствующие CNSA, его требуют.

Алгоритм Гровера в лучшем случае вдвое сократил бы эффективную длину ключа AES для атакующего с квантовым компьютером, поэтому у AES-256 остаётся большой запас; NIST считает достаточным и AES-128, потому что такие атаки плохо распараллеливаются.

TLS_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 — набор TLS 1.3, который быстро работает программно на устройствах без инструкций AES.

TLS_CHACHA20_POLY1305_SHA256 использует потоковый шифр ChaCha20 с аутентификатором Poly1305 (RFC 8439). Он работает за постоянное время без аппаратной поддержки, поэтому стал предпочтительным набором на мобильных устройствах без инструкций AES; серверы обычно уважают выбор клиента, который ставит его первым в списке.

Согласно RFC 8446, § 9.1, реализациям TLS 1.3 следует (SHOULD) его поддерживать. Аналоги в TLS 1.2 — TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 и TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC 7905).

TLS_AES_128_CCM_SHA256

AES-128-CCM для TLS 1.3; применяется в основном на устройствах с ограниченными ресурсами, где уже есть аппаратная поддержка AES-CCM.

CCM сочетает шифрование AES-CTR с AES-CBC-MAC и широко распространён в радиомодулях IoT. IANA помечает TLS_AES_128_CCM_SHA256 как рекомендуемый (Recommended), в отличие от TLS_AES_128_CCM_8_SHA256: IANA не рекомендует его 8-байтный тег для общего использования.

TLS_FALLBACK_SCSV

Сигнальное значение, которое сообщает серверу, что клиент повторяет попытку с более низкой версией протокола (RFC 7507).

Клиентов, которые после неудачного рукопожатия повторяли попытку со старыми версиями протокола, злоумышленник мог вынудить опуститься до SSL 3.0, чем в 2014 году воспользовалась атака POODLE. При такой повторной попытке клиент отправляет TLS_FALLBACK_SCSV (0x56,0x00); тогда сервер, который поддерживает более высокую версию, чем предлагает клиент, прерывает рукопожатие с оповещением inappropriate_fallback, а не продолжает его. Маркер понижения версии в ServerHello.random, появившийся в TLS 1.3, делает этот механизм ненужным, когда обе стороны поддерживают TLS 1.3.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Распространённый набор TLS 1.2 для сертификатов ECDSA: обмен ключами ECDHE, аутентификация ECDSA и AES-128-GCM.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) обеспечивает прямую секретность за счёт эфемерного ключа ECDHE и аутентифицирует сервер по сертификату ECDSA, обычно на кривой P-256. Именно этот набор TLS 1.2 предпочитают браузеры, когда у сервера сертификат ECDSA.

В строках шифров OpenSSL он называется ECDHE-ECDSA-AES128-GCM-SHA256. Сервер, у которого есть только сертификат RSA, не может его согласовать: часть набора TLS 1.2, отвечающая за аутентификацию, должна соответствовать типу ключа в сертификате.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Набор TLS 1.2, обязательный для HTTP/2: обмен ключами ECDHE, аутентификация RSA и AES-128-GCM.

Согласно RFC 9113, § 9.2.2, развёртывания HTTP/2 поверх TLS 1.2 должны поддерживать TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 с кривой P-256. Так у клиента и сервера, которые оба соблюдают ограничения HTTP/2 на TLS 1.2, всегда найдётся общий набор.

В OpenSSL он называется ECDHE-RSA-AES128-GCM-SHA256. Вопреки названию, ключ RSA только подписывает рукопожатие; ключ сеанса получается из эфемерного обмена ECDHE, поэтому у набора есть прямая секретность.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

256-битный вариант самого распространённого набора TLS 1.2: ECDHE, аутентификация RSA, AES-256-GCM и PRF на SHA-384.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) предлагают почти все серверы TLS 1.2 с сертификатом RSA. SHA384 в его названии задаёт хеш-функцию для PRF TLS 1.2; самому GCM отдельный MAC не нужен.

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 для TLS 1.2 с обменом ключами ECDHE и сертификатом ECDSA (RFC 7905).

Этот набор появился в TLS 1.2 в 2016 году и дал серверам, которые ещё не могли предложить TLS 1.3, быстрый в программной реализации AEAD ChaCha20-Poly1305. IANA помечает его как рекомендуемый (Recommended). В OpenSSL он называется ECDHE-ECDSA-CHACHA20-POLY1305.