tls-cipher-server-preference

<transmissions-api-listener>

Кто выбирает шифр на входе Transmissions API — узел или клиент
в конфигурации это строкаtls-cipher-server-preference falseвнутри блока <transmissions-api-listener>
То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Чьё слово последнее при выборе шифра

В рукопожатии клиент присылает список того, что умеет, а сервер выбирает. По умолчанию вход берёт первый подходящий из списка клиента — решает клиент. Со значением true порядок меняется: вход идёт по своему списку и берёт первое, что клиент поддерживает.

Без этой строки сортировка своего списка бессмысленна. Запись @STRENGTH в tls-ciphers упорядочивает список по стойкости, и этот порядок ни на что не влияет, пока выбирает клиент.

Настройка касается обеих версий: и списка до 1.2, и наборов tls-v1.3-ciphersuites.

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

Смысл появляется только вместе со своим списком:

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

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

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

Сортируют список и оставляют выбор клиенту

§ 3.3.21.11

Чем чреватоПорядок списка не используется. Клиент берёт то, что удобно ему, — часто более быстрый и менее стойкий шифр.
Как заметитьСогласуется не то, что стоит первым в списке узла.
Как правильноПоставить true.

Включают, не задав своего списка

наш опыт

Чем чреватоНастойчивость есть, а настаивать не на чем: порядок берётся из умолчания. Строка вводит в заблуждение читающего конфигурацию.
Как заметитьВ блоке есть строка, а списка шифров рядом нет.
Как правильноЛибо задать свой список, либо убрать строку.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
tls-cipher-server-preference <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.21.11
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка действует внутри своего <transmissions-api-listener>. У каждого входа своё решение.
Как проверить на узле
Прямого показания у настройки нет — её видно по тому, что выбрано:
openssl s_client -connect NODE:8585 -tls1_2 -brief </dev/null
Сравните Ciphersuite: с началом своего списка. Совпало — решает узел; не совпало, а соединение прошло — решает клиент.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла