Cipher suite: набор алгоритмов в TLS-рукопожатии, как читать названия

Прежде чем защищать данные, две стороны должны выбрать одни и те же алгоритмы. Клиент присылает список поддерживаемых наборов, cipher suites, в порядке предпочтения, а сервер выбирает подходящий. Набор — это не один алгоритм, а комбинация: как обмениваться ключами, как подтверждать подлинность сервера, чем шифровать данные и как проверять их целостность.

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

В TLS 1.2 имя содержит четыре части: обмен ключами, аутентификация, шифр и хеш. Порядок такой: сначала ECDHE или DHE, затем RSA или ECDSA, после слова WITH шифр с режимом, в конце хеш.

В TLS 1.3 набор алгоритмов упростили. Обмен ключами и подпись согласуются отдельными расширениями, а сам набор описывает только шифр и хеш, например TLS_AES_256_GCM_SHA384 или TLS_CHACHA20_POLY1305_SHA256. Таких наборов в стандарте всего несколько, поэтому настраивать почти нечего. О других отличиях версий можно прочитать в статье про TLS 1.3.

Признаки хорошего набора в 1.2: эфемерный обмен ключами ECDHE или DHE, который даёт прямую секретность, и аутентифицированное шифрование AES-GCM либо ChaCha20-Poly1305. Плохие признаки: слова EXPORT и NULL, шифры RC4 и 3DES, режим CBC в устаревших конструкциях, хеш MD5 и обмен ключами прямо через RSA, без эфемерных значений.

Почему это важно, показывают известные атаки, такие как BEAST, POODLE и Sweet32: каждая эксплуатировала конкретный слабый режим или шифр. Их устранили не изменением самого TLS, а отказом от таких наборов в настройках. Прямую секретность обсуждает страница про PFS.

Кто выбирает набор из общего списка: клиент или сервер? По умолчанию во многих конфигурациях порядок задаёт сервер, но иногда включают уважение предпочтений клиента. Это имеет смысл: телефоны без аппаратного ускорения AES эффективнее с ChaCha20, а компьютеры с ускорением быстрее с AES-GCM.

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

В инструментах разработчика браузера на вкладке безопасности отображается набор, который применяется к текущему соединению. Для сервера команда openssl s_client -connect имя:443 в выводе содержит строку Cipher, а с параметром -cipher можно проверить поддержку конкретного набора. Полный список у вашей библиотеки выводит openssl ciphers -v.

Онлайн-сканеры показывают все поддерживаемые сервером наборы и отмечают слабые. Если в списке остались устаревшие, уберите их в настройке веб-сервера и перепроверьте. Общие сведения о самом протоколе даёт страница про TLS.

Стоит пояснить, почему в современных наборах встречаются слова GCM и Poly1305. Они обозначают аутентифицированное шифрование: одновременно с шифрованием вычисляется метка, по которой получатель проверяет, что данные не изменены. Более старый режим CBC требовал отдельной проверки целостности и порождал уязвимости из-за порядка операций. AES-GCM быстр на процессорах с аппаратной поддержкой. ChaCha20-Poly1305 эффективен и без неё, что полезно для слабых телефонов. Оба считаются надёжными, поэтому выбор между ними определяется скорее производительностью, чем стойкостью.