On Tue, Aug 01, 2017 at 11:50:48AM -0700, robg...@nospammail.net wrote: > > 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.
No, because the effect of "spec" is to pop all the ciphers matching "spec" (in their relative order) off the stack of enabled, but not selected ciphers and append them (maintaining relative order) to the list of selected ciphers. Then the effect of "-spec" is to pop all the ciphers matching "spec" (in their relative order) off stack of of selected ciphers and prepend them (in their relative order) to the stack of enabled ciphers. Therefore, after "CHACHA20:-CHACHA20" the CHACHA20 ciphers are at the top of the enabled+unselected cipher stack. And then after "aNULL:-aNULL" the "aNULL" ciphers are at the top of the stack. If there were aNULL+CHACHA20A ciphers, then those would be ahead of any non-CHACHA20 aNULL ciphers. But, since there are none at present, the effect is aNULL first, and CHACHA20 second and AES, CAMELLIA after. Within each group there is still a preference for kECDHE over kDHE over kRSA, and of course the whole lot later gets resorted by cipher bit strength, while maintaining relative order for ciphers of equal strength. I am assuming you are now wiser, in that you are now more aware of how much you don't yet know about cipherlists... :-) > So how DO you make sure that a specific cipher is ALWAYS used if it's > available? You list the preferred category first. I strongly recommend against listing individual explicit cipher names. Later there will be better key exchange algorithms, better hashes, ... The best way to future-proof a non-default cipherlist is to use preferences for particular features, and not hardcode specific individual ciphers. Even better, let the library maintainers construct a sensible cipherlist, and avoid being a crypto fashionista. :-) Of course with paying cliets, they get what they ask and pay for if they are not interested in advice on what to do. > > 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. I recommend an empty setting here. Tastes great, less filling. -- Viktor.
