Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api-listener>›Directive§ 3.3.21.10

tls-v1.3-ciphersuites

<transmissions-api-listener>

Transmissions API input cipher suites for TLS 1.3
in the configuration this is a linetls-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_SHA256inside the block <transmissions-api-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
API input ciphers on version 1.3

A separate list — in version 1.3 suites are arranged differently than in earlier ones, and they share no common description language. tls-ciphers does not apply on 1.3.

The default lists five suites — from TLS_AES_256_GCM_SHA384 to TLS_AES_128_CCM_8_SHA256.

All five are modern. There are no weak suites in version 1.3: the committee threw them out of the standard. There is nothing to narrow the list “for hardening” here.

The main trap is narrowing to one suite. Security will not grow, and a submitting client without that suite will either fall back to 1.2 or not connect at all.
What the Hub does. It does not write it: our submission goes over SMTP, and there is no API entry point block in the configuration.
Recommended values

The line is rarely needed — on a policy requirement, not for security:

Value When
do not set (default) always
two or three suites an external policy requirement
one suite never
The default of five suites and separation from the list for versions up to 1.2 come from the manual (§ 3.3.21.10). The advice not to narrow to one is ours.
Example configuration
# narrowing to two suites — by policy requirement, not “for hardening”
<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>
The manual’s example. Both suites are strong; the point of the line is conformity to someone else’s list, not better encryption.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Narrowing to one suite “for hardening”

our experience

What it costsSecurity does not grow — all five suites are modern — while a submitting client without that suite falls back to 1.2 or drops off.
How to spot itPart of the submission suddenly goes over 1.2.
How to do it rightReturn the default or leave at least two suites.

Writing cipher names from the list for versions up to 1.2 here

§ 3.3.21.9

What it costsVersion 1.3 does not understand entries like HIGH. The list will turn out empty, and negotiation over 1.3 will stop succeeding.
How to spot itProtocol version: TLSv1.2 where there used to be 1.3.
How to do it rightWrite only names like TLS_* here, and the older ones into tls-ciphers.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
tls-v1.3-ciphersuites <string>
Values
a list of TLS 1.3 suites, colon-separated
Default
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
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<transmissions-api-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line applies inside its own <transmissions-api-listener>. Each input has its own list.
⇄

Related directives

2 relations

Same name in other blocks

tls-v1.3-ciphersuites<smtp-listener>The same-named line of the mail listener; here it is about a separate entry point, the API’s own. § 3.3.21.10

Works together with

tls-cipher-server-preference<transmissions-api-listener>The order here decides the matter only when the server chooses. § 3.3.21.11

Referenced from

tls-ciphers<transmissions-api-listener>The two lists split the work by protocol version: this one ends at TLS 1.2. § 3.3.21.10

How to check on the node
We look at which suite was negotiated on version 1.3:
openssl s_client -connect NODE:8585 -tls1_3 -brief </dev/null
The line Ciphersuite: shows the chosen suite. If it is not from your list, the connection went over another version — check Protocol version in the same output.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <transmissions-api-listener>:tls-min-versiontls-certificatetls-ca-filetls-cipher-server-preferencetls-ciphersAll 15 directives of the block →