still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
I'm reading about ciphers.

Here

"why use "aNULL:!aNULL:" in Postfix default cipherlists?"
 http://postfix.1071664.n5.nabble.com/why-use-quot-aNULL-aNULL-quot-in-Postfix-default-cipherlists-td83301.html

It talks about using anonymous ciphers when TLS policy is opportunistic == may.

I get that.

If instead you use MANDATORY tls policy, == encrypt, do you need to redefine the cipherlist to REMOVE that "aNull:-aNull"?

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni

> On Jul 31, 2017, at 4:55 PM, [hidden email] wrote:
>
> "why use "aNULL:-aNULL:" in Postfix default cipherlists?"

(Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:...").

This ensures that anon-DHE/anon-ECDHE ciphers are actually used when
mutually enabled and authentication is off at the client.

   https://tools.ietf.org/html/rfc7672#section-8.2

Sadly, this will no longer be possible once (a decade or two from now)
TLS 1.3 is the dominant protocol version, as TLS 1.3 drops support for
the anon ciphersuites.

> I get that.
>
> If instead you use MANDATORY tls policy, == encrypt, do you need to redefine the cipherlist to REMOVE that "aNull:-aNull"?

The "encrypt" security level is still unauthenticated.  Don't
confuse data confidentiality with channel integrity.  Postfix
will automatically suppress anon ciphers when configured to
authenticate the remote server.  The security levels where that
happens are:

        * dane
        * dane-only
        * fingerprint
        * secure
        * verify

The Postfix TLS interface is designed for people who have better things to do than having to tinker with obscure low-level crypto interfaces.  You're not expected to need to know about or tweak the cipherlists.

Just go with (default in current supported versions of Postfix):

        smtp_tls_ciphers = medium
        smtp_tls_mandatory_ciphers = high    (if supported by all destinations in question)

        smtp_tls_protocols = !SSLv2, !SSLv3
        smtp_tls_mandatory_protocols = !SSLv2, !SSLv3

Further fine-tuning is available for experts and generally not required.

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 = ...

Few users understand this subtle interface, and I see examples of nonsensical
variants from time to time.  The defaults are sufficiently secure and further
tuning belongs in OpenSSL not Postfix (OpenSSL 1.1.0 drops RC4 ciphers at
compile time for example, and IIRC re-classifies 3DES as "MEDIUM", it used
to be "HIGH").

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
Viktor

On Mon, Jul 31, 2017, at 02:11 PM, Viktor Dukhovni 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.

> This ensures that anon-DHE/anon-ECDHE ciphers are actually used when
> mutually enabled and authentication is off at the client.

> 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.

Unless I set the cipherlist manually to include the cipher, eg testing

        "aNULL:-aNULL:ECDHE-ECDSA-CHACHA20-POLY1305:HIGH:MEDIUM:@STRENGTH"
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

then it just uses other EC ciphers.  With it in there it works, mail to/from gmail uses the CHACHA20-POLY1305 cipher,

        Jul 29 14:31:28 maryland postfix/mailout/smtp[6707]: gmail-smtp-in.l.google.com[74.125.28.26]:25: TLS cipher list "aNULL:-aNULL:ECDHE-ECDSA-CHACHA20-POLY1305:HIGH:MEDIUM:@STRENGTH"
        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)

> Sadly, this will no longer be possible once (a decade or two from now)
> TLS 1.3 is the dominant protocol version, as TLS 1.3 drops support for
> the anon ciphersuites.

v1.3 is completely on mmy back burner for now.  Trying not to even LOOK at it until at least Openssl 111 is release.

> The "encrypt" security level is still unauthenticated.

Yeah

> Don't confuse data confidentiality with channel integrity.

Trying not to.

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.

> will automatically suppress anon ciphers when configured to
> authenticate the remote server.

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?

> 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

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.

Figuring out what to 'tweak' in those options to get there and NOT shoot off my own foot should be fun.

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Tobi
In reply to this post by robgane
Even with level encrypt the certificates are **NOT** verified which
means anyonymous chiphers are still used.

To verfiy peer certificates see:
http://www.postfix.org/TLS_README.html#client_tls_verify.
Or configure postfix smtp server to enforce clients to present a cert:
http://www.postfix.org/postconf.5.html#smtpd_tls_req_ccert

But to use "encrypt" on a public smtp server or enforce clients to
present certificates on such systems will lead to the fact that you
won't be receiving mails from servers which do not support TLS or do not
use a matching chipher


Am 31.07.2017 um 22:55 schrieb [hidden email]:

> I'm reading about ciphers.
>
> Here
>
> "why use "aNULL:!aNULL:" in Postfix default cipherlists?"
>  http://postfix.1071664.n5.nabble.com/why-use-quot-aNULL-aNULL-quot-in-Postfix-default-cipherlists-td83301.html
>
> It talks about using anonymous ciphers when TLS policy is opportunistic == may.
>
> I get that.
>
> If instead you use MANDATORY tls policy, == encrypt, do you need to redefine the cipherlist to REMOVE that "aNull:-aNull"?
>
> Rob
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
In reply to this post by robgane
On Mon, Jul 31, 2017 at 03:19:29PM -0700, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
On Tue, Aug 01, 2017 at 11:50:48AM -0700, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
> 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.

That's what I it took.  I was thinking of it in a literal order, not necessarily a pop'd/push'd stack

Thanks.

> I am assuming you are now wiser

You know what they say about assumptions.

But, I hope so!

> how much you don't yet know about cipherlists... :-)

It LOOKS simple when you first look at in the docs.

> > So how DO you make sure that a specific cipher is ALWAYS used if it's available?
>
> You list the preferred category first.

Which now makes more sense in stack-think.

> I strongly recommend against
> listing individual explicit cipher names.  Later there will be
> better key exchange algorithms, better hashes, ...

Yeah I noticed you used just 'CHACHA20', which I guess is the group name?  Or is that still just an abbreviated, explicit cipher name?

I've been using the full/explicit cipher name so far because I havent found the right doc that lists the group name (CHACHA20) that includes it.

> The best way to future-proof a non-default cipherlist is to use
> preferences for particular features

I do that already between internal machines.  

> 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.

Yep.   There's a bunch of clients in the customer chain.  They all agreed on project standards long before I got invovled.  We've got enough problems with the meat of the project without stirring their pot at this point on "just mail".

> > > 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".

> I recommend an empty setting here.  Tastes great, less filling.

Ok.  So if the docs say

        Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use ONLY the system-supplied default Certification Authority certificates.

        Specify "tls_append_default_CA = no" to prevent Postfix from appending the system-supplied default CAs and trusting third-party certificates.

and I set

                smtp_tls_CApath =
                tls_append_default_CA = no

Then it

        won't ONLY use sys default CA certs
        will PREVENT appending sys default CA certs
        won't TRUST (and/or use?) 3rd party certs

So what exactly IS it gonna do?




 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
On Tue, Aug 01, 2017 at 01:59:54PM -0700, [hidden email] wrote:

> > I strongly recommend against
> > listing individual explicit cipher names.  Later there will be
> > better key exchange algorithms, better hashes, ...
>
> Yeah I noticed you used just 'CHACHA20', which I guess is the group name?
> Or is that still just an abbreviated, explicit cipher name?

The name "CHACHA20" matches any ciphersuite that uses that stream
cipher for the bulk crypto:

    $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20
              0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xAE - RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xAD - DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xAC - ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
              0xCC,0xAB - PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD

The four PSK variants can't be used by most TLS applications
(including Postfix), so in practice CHACHA20 means just the first
three.

> I've been using the full/explicit cipher name so far because I havent
> found the right doc that lists the group name (CHACHA20) that includes
> it.

    https://www.openssl.org/docs/man1.1.0/apps/ciphers.html

> > I recommend an empty setting here.  Tastes great, less filling.
>
> Ok.  So if the docs say
>
> Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use
> ONLY the system-supplied default Certification Authority
> certificates.

If that's what you want.

>
> Specify "tls_append_default_CA = no" to prevent Postfix from
> appending the system-supplied default CAs and trusting third-party
> certificates.

If that's what you want.

> and I set
>
> smtp_tls_CApath =
> tls_append_default_CA = no
>
> Then it
>
> won't ONLY use sys default CA certs

No, it will trust no CAs at all.  A pox on all their houses.  As
for "tls_append_default_CA = no". These have been the default
setting for ages.

    $ postconf -d smtp_tls_CApath tls_append_default_CA
    smtp_tls_CApath =
    tls_append_default_CA = no

> So what exactly IS it gonna do?

Not trust any CAs.  When you want to authenticate some peer, use
the "tafile" feature of the policy table to specify a sensible list
of trust-anchors for that peer.

Enabling the system-default cert store will only make sense in the
context of SMTP STS, if/when Postfix has support for that.  Sadly,
the large providers (Google, Yahoo, Microsoft, ...) have difficulties
combining DNSSEC with their load-balancing infrastructure, so they
are pushing STS, with all its flaws, but arguably better than
nothing...

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
> The name "CHACHA20" matches any ciphersuite that uses that stream
> cipher for the bulk crypto:

Sounds like a group.

>     $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20

Ok so 'documented' by openssl directly, nothing Postfix specific.

>      0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
>      0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
>      0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
...
> The four PSK variants can't be used by most TLS applications
> (including Postfix), so in practice CHACHA20 means just the first
> three.

And subgroups?  If for any group of ciphers to be used in Postfix I want to only ever use EC ciphers, so eg "in practice" here, only the 1st two?  Some shorthand for "EC only"?

I never really checked.  Is crypto for Postfix always/only provided by OpenSSL?  So naming for cipherlists, and related shorthand, is OpenSSL-specific and so we look to OpenSSL for the docs?  Or is that set at a standards level and naming is consistent across Postfix, Openssl and all other crypto?

> > Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use
> > ONLY the system-supplied default Certification Authority
> > certificates.
...
> > Then it
> >
> > won't ONLY use sys default CA certs
>
> No, it will trust no CAs at all.  A pox on all their houses.

Ok. That makes more sense.

That's not what I got from reading that section.  It read to me like if you don't specify it it doesn't ONLY use ...

>  As for "tls_append_default_CA = no". These have been the default
> setting for ages.

Sure.  I don't actually set it explicitly on my setup.  Like you say it's the default.

>     $ postconf -d smtp_tls_CApath tls_append_default_CA
>     smtp_tls_CApath =
>     tls_append_default_CA = no
>
> > So what exactly IS it gonna do?
>
> Not trust any CAs.  When you want to authenticate some peer, use
> the "tafile" feature of the policy table to specify a sensible list
> of trust-anchors for that peer.

Ok.

> Enabling the system-default cert store will only make sense in the
> context of SMTP STS, if/when Postfix has support for that.  Sadly,
> the large providers (Google, Yahoo, Microsoft, ...) have difficulties
> combining DNSSEC with their load-balancing infrastructure, so they
> are pushing STS, with all its flaws, but arguably better than
> nothing...

SMTP STS hadn't even heard of yet.  DNSSEC is on my todo list.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
On Tue, Aug 01, 2017 at 02:59:35PM -0700, [hidden email] wrote:

> > The name "CHACHA20" matches any ciphersuite that uses that stream
> > cipher for the bulk crypto:
>
> Sounds like a group.

It names a set of related ciphersuites.

> >     $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20
>
> Ok so 'documented' by openssl directly, nothing Postfix specific.

Correct.

> And subgroups?  If for any group of ciphers to be used in Postfix I want
> to only ever use EC ciphers, so eg "in practice" here, only the 1st two?

Define "EC ciphers"!  Do you want ECDHE key agreement, ECDSA
certificates or both?

> Some shorthand for "EC only"?

    For ECDSA (really not RSA or DSA) certificates with CHACHA20 preferred
    over AES, ...

        smtp_tls_high_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
        smtp_tls_medium_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

    For ECDHE (really not kRSA or kDHE) key exchange with CHACHA20
    preferred over AES, ...

        smtp_tls_high_cipherlist = !kRSA:!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
        smtp_tls_medium_cipherlist = !kRSA:!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

    For ECDHE with ECDSA combine both sets of exclusions:

        smtp_tls_high_cipherlist = !kRSA:!kDHE:!aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
        smtp_tls_medium_cipherlist = !kRSA:!kDHE:!aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

This work by exclusion of stuff you don't want (RSA, DSS, DHE and
RSA key exchange) and don't lock out future improvements by freezing
in today's recommended settings for perpetuity.

> I never really checked.  Is crypto for Postfix always/only provided by
> OpenSSL?

Yes.

> So naming for cipherlists, and related shorthand, is OpenSSL-specific and
> so we look to OpenSSL for the docs?  Or is that set at a standards level
> and naming is consistent across Postfix, Openssl and all other crypto?

The underlying cipher names are from OpenSSL and documented there.

> > Enabling the system-default cert store will only make sense in the
> > context of SMTP STS, if/when Postfix has support for that.  Sadly,
> > the large providers (Google, Yahoo, Microsoft, ...) have difficulties
> > combining DNSSEC with their load-balancing infrastructure, so they
> > are pushing STS, with all its flaws, but arguably better than
> > nothing...
>
> SMTP STS hadn't even heard of yet.  DNSSEC is on my todo list.

The SMTP STS draft proposed standard is not yet out of working
group last call...

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane


On Tue, Aug 1, 2017, at 03:27 PM, Viktor Dukhovni wrote:
> smtp_tls_high_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
> smtp_tls_medium_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

smtp_tls_*

or just

tls_*


I'm finding the 2nd in the docs, but not the first.

Typo?  Or bad search by me?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni

> On Aug 1, 2017, at 6:59 PM, [hidden email] wrote:
>
>> smtp_tls_high_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
>> smtp_tls_medium_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
>
> smtp_tls_*
>
> or just
>
> tls_*
>
>
> I'm finding the 2nd in the docs, but not the first.
>
> Typo?  Or bad search by me?

My typo.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane
For any given cipherlist in Postfix e.g.

  tls_medium_cipherlist = !kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

Is there a postfix command to display an order list, by preference, of all the actually presented ciphers etc, *including* all the built-in Postfix exclusions?

I know I can do

openssl ciphers -V CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

(can't figure out how to get the "!kDHE" in there)

but that lists the Openssl result obvioiusly.  Including the SSL3 ciphers it looks like.

IIUC those are excluded in Postfix by

 smtp_tls_protocols               = !SSLv2, !SSLv3
 smtpd_tls_protocols              = !SSLv2, !SSLv3

in main.cf.

Is there a way to get the Postfic-actual cipherlist, so MINUS the SSLv2, SSLv3, and anything else Postfix auto-excludes?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
On Tue, Aug 01, 2017 at 04:11:45PM -0700, [hidden email] wrote:

> For any given cipherlist in Postfix e.g.
>
>   tls_medium_cipherlist = !kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
>
> Is there a postfix command to display an order list, by preference, of
> all the actually presented ciphers etc, *including* all the built-in
> Postfix exclusions?

No, you use OpenSSL for that.

> I know I can do
>
> openssl ciphers -V CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
>
> (can't figure out how to get the "!kDHE" in there)

Just put the cipherlist in single quotes, otherwise "bash" history
substitution gets in the way:

    openssl ciphers -V '!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH'

> but that lists the Openssl result obvioiusly.  Including the SSL3 ciphers it looks like.

DO NOT confuse ciphers with protocol versions.  The SSLv3 ciphers
are also TLS 1.x ciphers, and are needed for interoperability with
many TLS 1.0, TLS 1.1 and TLS 1.2 sites.  TLS 1.2 uses many ciphers
that date back to SSLv3, some that date back to TLS 1.0, and some
that are new with TLS 1.2 (TLS 1.1 added no new ciphers).

> IIUC those are excluded in Postfix by
>
>  smtp_tls_protocols               = !SSLv2, !SSLv3
>  smtpd_tls_protocols              = !SSLv2, !SSLv3

No, these are protocol version exclusions, not cipher exclusions.
The configured cipherlist is dynamically filtered for compatibility
with the negotiated TLS version.  The input cipherlist is the one
you see from the "ciphers -V" command.

To see what you'd get for a particular protocol version:

    $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
    $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_1 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
    $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_2 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
              0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

Which shows that if you want CHACHA20 without RSA or DSA certs you
lose with TLS 1.0 and TLS 1.1, but scrape by with one compatible
cipher with TLS 1.2.

> Is there a way to get the Postfic-actual cipherlist, so MINUS the SSLv2,
> SSLv3, and anything else Postfix auto-excludes?

The low-level cipherlist interface is an OpenSSL interface, and
you ask OpenSSL not Postfix to interpret the configuration.  Postfix
just passes the cipherlists to OpenSSL after appending any exclusions
(automatic exclusions of eNULL and/or aNULL as appropriate plus
the various explicit mumble_exclude_ciphers parameters).

It is unfortunate that you're forced to scale this particular
learning curve.  The vast majority of users can stay blissfully
unaware, and are better off for that.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane


On Tue, Aug 1, 2017, at 04:41 PM, Viktor Dukhovni wrote:
> Just put the cipherlist in single quotes, otherwise "bash" history substitution gets in the way:

Grrr. Ok.

> DO NOT confuse ciphers with protocol versions.
> No, these are protocol version exclusions, not cipher exclusions.

Yep. That's exactly what I was doing.
Clear now.
Thanks.

> The low-level cipherlist interface is an OpenSSL interface, and
> you ask OpenSSL not Postfix to interpret the configuration.

Ok.

> It is unfortunate that you're forced to scale this particular
> learning curve.  The vast majority of users can stay blissfully
> unaware, and are better off for that.

I'm not going to complain about it.

I've got a decent start on the details of how to set TLS up in Postfix, how to tear it down, why I'd want to do either and how to check what I ended up with.

So I guess, a little wiser.

Thanks alot for the guidance!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
On Tue, Aug 01, 2017 at 11:41:42PM +0000, Viktor Dukhovni wrote:

> To see what you'd get for a particular protocol version:
>
>     $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
>     $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_1 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
>     $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_2 -V 'CHACHA20:!aRSA:!aDSA:!PSK'
>      0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

For the record, that "!aDSA" should have been "!aDSS", though it
makes little difference in this example as no DSA (aka DSS) CHACHA
algorithms exist and none are likely to ever be added.

You can check with "openssl ciphers -v aDSS" vs. "openssl ciphers -v aDSA".

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane


On Wed, Aug 2, 2017, at 12:26 AM, Viktor Dukhovni wrote:
> For the record, that "!aDSA" should have been "!aDSS", though it
> makes little difference in this example as no DSA (aka DSS) CHACHA
> algorithms exist and none are likely to ever be added.
>
> You can check with "openssl ciphers -v aDSS" vs. "openssl ciphers -v aDSA".

Thanks.

In my 'Phase 1', before turning up the TLS requirements I'll need,  I'm just paying attention an existing server's TLS usage,

  22888  ECDHE-RSA-AES256-GCM-SHA384
  11050  ADH-AES256-GCM-SHA384
   3786  DHE-RSA-AES256-SHA
   2312  ECDHE-RSA-AES256-SHA384
   2304  AECDH-AES256-SHA
   2296  ECDHE-RSA-CHACHA20-POLY1305
   2265  ECDHE-RSA-AES256-SHA
   1120  ADH-AES256-SHA
    885  DHE-RSA-AES256-GCM-SHA384
    679  ECDHE-RSA-AES128-GCM-SHA256
    340  ECDHE-ECDSA-AES256-GCM-SHA384
    216  AES256-SHA
    112  ECDHE-ECDSA-CHACHA20-POLY1305
     72  DHE-RSA-AES256-SHA256
     40  ECDHE-RSA-AES128-SHA256
     27  AES256-GCM-SHA384
     13  ECDHE-ECDSA-AES256-SHA
      5  AES128-GCM-SHA256

Looks like I probably wouldn't have noticed -aDSS or -DSS. For a bit anyway.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

Viktor Dukhovni
On Wed, Aug 02, 2017 at 06:33:50AM -0700, [hidden email] wrote:

> > For the record, that "!aDSA" should have been "!aDSS", though it
> > makes little difference in this example as no DSA (aka DSS) CHACHA
> > algorithms exist and none are likely to ever be added.
> >
> > You can check with "openssl ciphers -v aDSS" vs. "openssl ciphers -v aDSA".
>
> Thanks.
>
> In my 'Phase 1', before turning up the TLS requirements I'll need,  I'm just paying attention an existing server's TLS usage,
>
>   22888  ECDHE-RSA-AES256-GCM-SHA384
>   11050  ADH-AES256-GCM-SHA384
>    3786  DHE-RSA-AES256-SHA
>    2312  ECDHE-RSA-AES256-SHA384
>    2304  AECDH-AES256-SHA
>    2296  ECDHE-RSA-CHACHA20-POLY1305
>    2265  ECDHE-RSA-AES256-SHA
>    1120  ADH-AES256-SHA
>     885  DHE-RSA-AES256-GCM-SHA384
>     679  ECDHE-RSA-AES128-GCM-SHA256
>     340  ECDHE-ECDSA-AES256-GCM-SHA384
>     216  AES256-SHA
>     112  ECDHE-ECDSA-CHACHA20-POLY1305
>      72  DHE-RSA-AES256-SHA256
>      40  ECDHE-RSA-AES128-SHA256
>      27  AES256-GCM-SHA384
>      13  ECDHE-ECDSA-AES256-SHA
>       5  AES128-GCM-SHA256
>
> Looks like I probably wouldn't have noticed -aDSS or -DSS. For a bit anyway.

"Nobody" on the public Internet is using DSA/DSS these days, there
may still be legacy internal uses within the US goverment...

So at this time DSA/DSS is largely needless attack surface.  It
can be safely disabled, though leaving it enabled is likely harmless.

Perhaps for the next release we should adjust Postfix defaults:

    tls_high_cipherlist = !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:@STRENGTH
    tls_medium_cipherlist = !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

The additional excluded ciphersuites are rarely if ever used and
either obsolete or unwise or both.  Excluding them reduces the
client TLS HELLO message size, improves interoperability with some
very old Microsoft systems (now rare) with no expected downgrades
to cleartext.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

robgane


On Wed, Aug 2, 2017, at 11:35 AM, Viktor Dukhovni wrote:
>     tls_high_cipherlist = !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:@STRENGTH
>     tls_medium_cipherlist = !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
>
> The additional excluded ciphersuites are rarely if ever used and
> either obsolete or unwise or both.  Excluding them reduces the
> client TLS HELLO message size, improves interoperability with some
> very old Microsoft systems (now rare) with no expected downgrades
> to cleartext.

Afaict, none of that would've done any harm in my contexts.

I guess RC4 is already gone.  I do see some Au=SRP.  No clue yet what those are.  And even though it's enabled I have never seen a CAMELLIA cipher'd message; at least not in my logs.

From the other thread, I also checked *who* was still sending to me with Mac=SHA1.  Virtually all were garbage I can live without.  Especially 4 from my annoying cousin ;-)   So considering !SHA1 (for a few seconds anyway)
12
Loading...