On Wed, Nov 07, 2018 at 08:07:40AM -0800, pg...@dev-mail.net wrote:
> On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> > Check your logs for evidence of TLS <= 1.2 ciphers
>
> Doing the quick check you mentioned, first for my messy 'test' server,
> results are just
>
> 11 TLS_AES_256_GCM_SHA384
That's TLS 1.3, which as I mentioned is a different beast. It
always does PFS, and never RSA key exchange, but this is not reflected
in the cipher name, because the ciphers no longer specify the key
exchange method.
> /var/log/postfix/postfix.log:Nov 4 15:21:45 mx
> postfix/postscreen-internal/smtpd[15675]: Anonymous TLS connection
> established from mx.example.com[XX.XX.XX.XX]: TLSv1.3 with cipher
> TLS_AES_256_GCM_SHA384 (256/256 bits)
>
> IIUC (?), 'something' in my current config, is enabling that internal use of
> the TLS_AES_256_GCM_SHA384 cipher ... and, if I were to disable
> 'keyEncipherment' and generate/use new certs, I'd likely drop to cleartext?
>
No, you just did not read my post carefully enough... :-)
The TLS 1.3 connections are out of scope and can be ignored.
> If, in fact, I need to NOT use the "non-PFS RSA key transport",
> even for that internal transport, would I need to specifically,
> additionally exclude a particular cipher/protocol here?
If you wanted to avoid RSA key transport, you could add 'kRSA' to
your list of *smtpd* TLS cipher exclusions. I'm not saying that
you should do that, but if RSA key transport is never used in
practice, it may be reasonable to disable it.
Outbound, I still see a handful of kRSA connections to sites that
don't have PFS turned on:
6 omgi.iij.ad.jp AES128-GCM-SHA256
1 nibbler.inwx.net AES256-GCM-SHA384
and it is the *server* operator's job to define the appropriate
policy for their own keys/certs. So I would not at this time suggest
any similar exclusion for the SMTP client.
Keep in mind that TLS in SMTP is still predominantly opportunistic,
and generally even less than perfect encryption is still better
than none.
--
Viktor.
