On Mon, Jul 31, 2017 at 03:19:29PM -0700, robg...@nospammail.net wrote:
> > (Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:...").
>
> Yeah noticed that. Not clear what the diff is yet, but sticking with the
> "aNULL:-aNULL" for this.
The difference is rather large. The OpenSSL cipherlist specification
is a tiny and somewhat subtle programming language. The "!spec"
form irrevocable disables the ciphers matching "spec". There's no
way to bring "spec" back after that directive. While "-spec"
removes "spec" from the working list, but the ciphers in question
can be added back with later directives. The effect of:
"spec:-spec"
is to put the ciphers matching "spec" at the front of the list of
not yet included ciphers. Thus "spec:-spec:ALL" ensures that
the ciphers matching "spec" are listed first, pending any other
directives that change the order.
> > You're not expected to need to know about or tweak the cipherlists.
>
> Well I have to tweak a bit anyway. I need to get ChaCha20 working. And
> I intend to know about it if only not to screw things up.
That's an interesting use of "have to" that I'm not familiar with. :-)
There's nothing sufficiently wrong with AES (which has hardware support
on most modern CPUs) to warrant switching to CHACHA20 for SMTP, where
the biggest of disclosure is not attacks on the crypto.
https://xkcd.com/538/
> Unless I set the cipherlist manually to include the cipher, eg testing
>
> "aNULL:-aNULL:ECDHE-ECDSA-CHACHA20-POLY1305:HIGH:MEDIUM:@STRENGTH"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you want CHACHA20 to be preferred over AES (OpenSSL 1.1.0 I
assume, there's no CHACHA20 in OpenSSL 1.0.x IIRC) then the right
way to do it is:
tls_high_cipherlist = CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
tls_medium_cipherlist =
CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
This leaves the existing aNULL ciphers first, then non-aNULL CHACHA,
AES and CAMELLIA. Since Google does not do aNULL, the effect is still
to use aNULL where available, and otherwise CHACHA20 first.
Frankly, I am surprised you feel compelled to prefer the still
relatively new CHACHA20, which is likely slower than AES on your
hardware, and could (though we hope not) turn out to be weaker
than AES. It takes a long time to gain confidence in a symmetric
cipher algorithm.
> Jul 29 14:31:28 maryland postfix/mailout/smtp[6707]: Trusted TLS
> connection established to gmail-smtp-in.l.google.com[74.125.28.26]:25:
> TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
>
> That log snip above is from a send TO someone at gmail FROM my server.
>
> I'm confused about the "Trusted TLS" bit.
>
> I'm not authenticating to google as a user, just sending mail to it. So I
> thought that means I'd be 'ananoymous' to it.
The log entry is showing whether Google's certificate is authenticating
it to your SMTP client. Google is presenting a certificate that
chains to a locally trusted CA. You must have configuned a non-empty
"smtp_tls_CAfile" or "smtp_tls_CApath". These are largely pointless
unless you're actually doing WebPKI authentication.
> So since I'm NOT authenting, and DO have "aNULL:-aNULL" in there why am
> I successfully using the ECDHE-ECDSA-CHACHA20-POLY1305 cipher? Shouldn't
> I HAVE to remove aNull support?
Your server offers both aNULL (first) and non-aNULL (second) ciphers.
Google's servers don't enable aNULL, so you negotiate a ciphersuite
that employs (RSA) certificates, which you largely ignore, but you
do log that they could be authenticated if you cared to.
> > It is somewhat unfortunate that to work around some quirks in Exchange 2003
> > (mostly gone now) I've had to post examples of pruned cipherlists that make
> > TLS work against these crippled servers:
> >
> > smtp_tls_exclude_ciphers = ...
>
> Yeah, started looked at that too as part of the bunch of
>
> smtpd_tls_ciphers
> smtpd_tls_mandatory_ciphers
> smtpd_tls_exclude_ciphers
> smtpd_tls_mandatory_exclude_ciphers
>
> smtp_tls_ciphers
> smtp_tls_mandatory_ciphers
> smtp_tls_exclude_ciphers
> smtp_tls_mandatory_exclude_ciphers
You're probably working too hard. Perhaps it is just a matter of
trying to learn the technology, in which case, by all means, feel
free to experiment. If you main goal was to just to get mail
delivered, with reasonable best-effort security, then the default
settings are the way to go.
> If by 'subtle' you mean 'easily confused by', sign me up!
>
> Eventually I'll have to make this server mandatory TLS for in & outbound,
> and limit it to non-"Broken or Scary" ciphers. And to always prefer EC,
> strongest options first.
Why? Are you aiming to receive email or look cool with the shiniest
new crypto? :-) (It not turn out to be more secure, though it does
look promising).
> Figuring out what to 'tweak' in those options to get there and NOT shoot off
> my own foot should be fun.
By all means, have fun.
--
Viktor.
