tls-ciphers

<transmissions-api-listener>

Набор шифров входа Transmissions API для версий до TLS 1.2
в конфигурации это строкаtls-ciphers HIGH:!ADH:@STRENGTHвнутри блока <transmissions-api-listener>
То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Шифры второго способа подачи

Список допустимых шифров для соединений этого входа. Запись — как у команды OpenSSL ciphers, умолчание HIGH:!ADH:@STRENGTH: только сильные наборы, без анонимного обмена ключами, отсортированные по стойкости.

Действует по TLS 1.2 включительно. У версии 1.3 свой список — tls-v1.3-ciphersuites.

Порядок значим только вместе с tls-cipher-server-preference: по умолчанию шифр выбирает клиент, и сортировка @STRENGTH ни на что не влияет.

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

Умолчание разумно; менять только по внешнему требованию:

Значение Когда
HIGH:!ADH:@STRENGTH (умолчание) всегда
своё сужение требование аудита, с проверкой подачи до применения
версия 1.3 этой строкой не задаётся
Умолчание и ограничение версиями до 1.2 — из руководства (§ 3.3.21.9). Замечание про остановленную подачу — наше.
Пример в конфигурации
# умолчание, записанное явно
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-ciphers HIGH:!ADH:@STRENGTH</transmissions-api-listener>
Пример руководства. Сужать имеет смысл только по внешнему требованию и проверив, что подающий клиент ещё подключается.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

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

наш опыт

Чем чреватоПодача останавливается целиком: клиенту нечем договориться, и письма в MTA не попадают. Заметно это не по журналу отправки, а по её отсутствию.
Как заметитьОчередь пуста, а подающая платформа копит ошибки соединения.
Как правильноВернуть умолчание, проверить сужение на одном клиенте и только потом класть на все узлы.

Задают этой строкой шифры версии 1.3

§ 3.3.21.10

Чем чреватоСписок действует по 1.2 включительно. Имена наборов 1.3 в нём ничего не значат, а нужные остаются в умолчании.
Как заметитьСписок задан, а на 1.3 согласуется набор не из него.
Как правильноПисать наборы 1.3 в tls-v1.3-ciphersuites.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
tls-ciphers <string>
Значения
строка списка шифров в записи команды OpenSSL ciphers
Умолчание
HIGH:!ADH:@STRENGTH § 3.3.21.9
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка действует внутри своего <transmissions-api-listener>. Списки почты — smtp-server-tls-ciphers на приёме и smtp-tls-ciphers на отправке — к этому входу отношения не имеют.
Как проверить на узле
Смотрим, какой шифр согласовался на самом деле:
openssl s_client -connect NODE:8585 -tls1_2 -brief </dev/null
Строка Ciphersuite: показывает выбранный набор. Ошибка согласования вместо неё означает, что список слишком узок для подающего клиента.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла