On Tue, Aug 1, 2017, at 10:55 AM, Viktor Dukhovni wrote: > listed first, pending any other directives that change the order.
Ok, that 'pending others' part was what I wasn't getting. > > 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. :-) > https://xkcd.com/538/ > Frankly, I am surprised you feel compelled to prefer the still Tbh, I'm not sure why the 'frank surprise' etc. It's a client requirement for the project this is involved in. They audit, they specify, they pay. > OpenSSL 1.1.0 I assume, there's no CHACHA20 in OpenSSL 1.0.x IIRC yes > 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. I am having a time of it trying to wrap my head around that. I would interpret that order to mean CHACHA cipher first, BEFORE aNULL cipher. So how DO you make sure that a specific cipher is ALWAYS used if it's available? > > 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". Yeah, here I have postconf smtp_tls_CApath smtp_tls_CApath = /etc/ssl/certs/ > These are largely pointless unless you're actually doing WebPKI > authentication. I set that because the docs say http://www.postfix.org/postconf.5.html#smtp_tls_CApath Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use ONLY the system-supplied default Certification Authority certificates. which sounds like good sense to me. > > > 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. More head-wrapping needed :-( > You're probably working too hard. Don't hear THAT often. > 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. Nah. Just getting mail delivered, using defaults, was really straightfoward. Well it was once I sat down and read a big enough chunk of the docs and stopped paying attention to random online posts. > > 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? Because it's a real requirement. See above. > Are you aiming to receive email or look cool with the shiniest new crypto? :-) You have an interesting sense of humor. > (It not turn out to be more secure, though it does look promising). Sure. Thanks for the help. Rob
