Кратко

  • RFC 3268 не заменил механизм согласования TLS. Он добавил в существующий список двенадцать идентификаторов наборов AES: шесть сочетаний обмена ключами и аутентификации, каждое с двумя длинами ключа.
  • AES-256 сам по себе не удостоверяет собеседника и не обеспечивает прямую секретность: это зависит от выбранного рукопожатия и его реализации.

Новому шифру потребовалось имя в общем меню

Стандартизация AES ещё не означала, что клиент и сервер TLS смогут договориться о его параметрах. Нужен был общий способ назвать полный набор. В TLS 1.0 такой механизм уже существовал: клиент перечислял наборы в ClientHello, а сервер выбирал поддерживаемый. RFC 2246 определял набор как сочетание обмена ключами, шифрования данных и алгоритма аутентификации сообщений.

RFC 3268, опубликованный в июне 2002 года, поместил AES в эту рамку: CBC и HMAC-SHA-1. Но это был не один пункт «AES». Спецификация перечислила шесть семейств рукопожатия: RSA; статический DH с сертификатом DSS или RSA; эфемерный DHE с подписью DSS или RSA; и анонимный DH. Для каждого предусмотрели ключ AES длиной 128 или 256 бит. Так появились двенадцать идентификаторов.

Одинаковый блочный шифр не уравнивал эти схемы. RSA, аутентифицированный DH и анонимный DH по-разному отвечают на вопрос, кому можно доверять. DHE может дать прямую секретность, если эфемерные ключи не повторяются, надёжно уничтожаются, а генератор случайных чисел не раскрывает прежние выходы. Анонимный DH не аутентифицирует участника и допускает атаку посредника, если другая процедура не связывает стороны с одним сообщением Finished TLS. Длина ключа AES этого не меняет.

AES допускает ключи 128, 192 и 256 бит, однако RFC 3268 включил только 128 и 256, чтобы не раздувать перечень имён. Все двенадцать вариантов используют 128-битный блок AES: более длинный ключ не увеличивает блок. CBC и SHA-1 в HMAC также входят в определение. «AES» — только одна часть пакета.

Совместимость увеличила поверхность выбора

Во введении RFC сказано, что доступные тогда наборы DHE в основном опирались на Triple-DES, а некоторые экспортные варианты имели неудовлетворительную длину ключа. AES можно было добавить, сохранив ClientHello и согласование TLS 1.0. Но каждой комбинации требовались собственный код, имя, политика предпочтения и реализация.

Запись в реестре не доказывает поддержку в продуктах, предпочтение сервера или переговоры в реальном соединении. Дальнейшая эволюция показывает смещение границ: многие наборы TLS 1.2 всё ещё объединяли несколько решений; TLS 1.3 оставил в идентификаторе набор AEAD и хеш, а группы обмена ключами и алгоритмы подписи вынес в отдельные параметры. Поэтому RFC 3268 рассказывает не только о приходе AES, но и о том, где TLS размещает криптографические решения.

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

Источники