tls-v1.3-ciphersuites

<transmissions-api-listener>

Наборы шифров входа Transmissions API для TLS 1.3
в конфигурации это строкаtls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256внутри блока <transmissions-api-listener>
То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Шифры входа по API на версии 1.3

Отдельный список — в версии 1.3 наборы устроены иначе, чем в прежних, и общего языка описания у них нет. tls-ciphers на 1.3 не действует.

Умолчание перечисляет пять наборов — от TLS_AES_256_GCM_SHA384 до TLS_AES_128_CCM_8_SHA256.

Все пять современные. В версии 1.3 слабых наборов нет: комитет выкинул их из стандарта. Сужать список «ради усиления» здесь нечего.

Главная ловушка — сузить до одного набора. Стойкость не вырастет, а подающий клиент без этого набора либо откатится на 1.2, либо не подключится вовсе.
Что делает Хаб. Не пишет: подача у нас идёт по SMTP, блока входа по API в конфигурации нет.
Рекомендуемые значения

Строка нужна редко — по требованию политики, не ради стойкости:

Значение Когда
не задавать (умолчание) всегда
два-три набора требование внешней политики
один набор никогда
Умолчание из пяти наборов и отдельность от списка для версий до 1.2 — из руководства (§ 3.3.21.10). Совет не сужать до одного — наш.
Пример в конфигурации
# сужение до двух наборов — по требованию политики, не «для усиления»
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256</transmissions-api-listener>
Пример руководства. Оба набора сильные; смысл строки — соответствие чужому списку, а не улучшение шифрования.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Сужают до одного набора ради «усиления»

наш опыт

Чем чреватоСтойкость не растёт — все пять наборов современные, — а подающий клиент без этого набора откатывается на 1.2 или отваливается.
Как заметитьЧасть подачи внезапно идёт по 1.2.
Как правильноВернуть умолчание либо оставить минимум два набора.

Пишут сюда имена шифров из списка для версий до 1.2

§ 3.3.21.9

Чем чреватоЗаписи вида HIGH версия 1.3 не понимает. Список окажется пустым, и согласование по 1.3 перестанет проходить.
Как заметитьProtocol version: TLSv1.2 там, где раньше была 1.3.
Как правильноПисать сюда только имена вида TLS_*, а прежние — в tls-ciphers.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
tls-v1.3-ciphersuites <string>
Значения
список наборов TLS 1.3 через двоеточие
Умолчание
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256 § 3.3.21.10
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка действует внутри своего <transmissions-api-listener>. У каждого входа список свой.
Как проверить на узле
Смотрим, какой набор согласовался на версии 1.3:
openssl s_client -connect NODE:8585 -tls1_3 -brief </dev/null
Строка Ciphersuite: показывает выбранный набор. Если он не из вашего списка, соединение прошло по другой версии — проверьте Protocol version в той же выдаче.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла