On Sat, Jan 30, 2021 at 06:49:42PM +0100, Matus UHLAR - fantomas wrote:
> >On Fri, Jan 29, 2021 at 06:53:09PM +0100, Matus UHLAR - fantomas wrote:
> >> yes, but when the policy is encryption required for client-server
> >> connections, aNULL would break that IIUC
> >> - please correct me if I'm wrong
>
> On 29.01.21 15:09, Viktor Dukhovni wrote:
> >You're wrong. The "a" in aNULL ciphers stands for "authentication".
> >These ciphers just do anonymous Diffie-Hellman, but do not authenticate
> >either party. They encrypt the traffic just as well as the ciphers
> >that present certificates that you ignore anyway.
>
> so, the connection/encryption would work, but with aNULL will be
> unauthenticated, which means certificates won't be checked?
No, with aNULL certificates are not even *sent* (exchanged between
client and server). With opportunistic TLS (security level "may")
the "!aNULL" ciphers send server certificates the client never
checks (sends mail anyway, regardless of the content of the
certificate).
When the Postfix TLS security level requires authentication (mandatory
TLS stronger than just "encrypt"), Postfix automatically disables the
aNULL ciphers internally. You never need to do explicitly, except to
satisfy some clueless auditor's checklist.
That said, my support for aNULL ciphers in Postfix is a losing battle
against said clueless auditors and even not so clueless maximalists,
who frown on the opportunistic use-case.
In particular, there are no anonymous E(EC)DH ciphers in TLS 1.3, the
server MUST send a certificate, even when the client is going to ignore
it. The server also has no mechanism to learn that the client intends
to ignore the server's certificate. I think that leaving out the aNULL
ciphers from TLS 1.3 is a bad idea, but despite RFC7435, the maximalists
have not really changed their attitudes.
--
Viktor.
