explicit cipher list

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

explicit cipher list

lists@rhsoft.net
Hi

http://www.postfix.org/TLS_README.html#server_tls

am i overlooking something or is it not possible to list explcit
offered ciphers and their order like dovecot/httpd fro smtpd?

i am speaking here about non-MX servers only for submission
what i most appreciate in this way of configuration is
openssl ciphers -v '{cipherlist}' to verify it
_______________________________________________________________

dovecot:

ssl_prefer_server_ciphers = yes
ssl_cipher_list =
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:!3DES:!ADH:!aNULL:!DES:!DSS:!eNULL:!EXP:!KRB5:!LOW:!MD5:!PSK:!RC2:!SEED:!SRP:!SSLv2
_______________________________________________________________

httpd:

SSLProtocol All -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:!3DES:!ADH:!aNULL:!DES:!DSS:!eNULL:!EXP:!KRB5:!LOW:!MD5:!PSK:!RC2:!SEED:!SRP
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Thu, Nov 07, 2013 at 11:31:03PM +0100, [hidden email] wrote:

> http://www.postfix.org/TLS_README.html#server_tls
>
> Am I overlooking something or is it not possible to list explicit
> offered ciphers and their order like dovecot/httpd for smtpd?

Postfix provides a more natural user interface in terms of cipher
grades (null, export, low, medium, high).  These have sensibly easy
to reason about security properties.

I've seen many subtle and not so-subtle errors when mere mortals
(including myself) have tried to use the raw OpenSSL cipherlist
syntax.  Making that be the Postfix interface would be a disservice
to Postfix users.

> I am speaking here about non-MX servers only for submission
> what I most appreciate in this way of configuration is
> openssl ciphers -v '{cipherlist}' to verify it

    $ postfix_ciphers() {
        grade="$1"
        openssl ciphers -v "$(postconf -xh tls_${grade}_cipherlist)"
      }

    $ postfix_ciphers null
    ECDHE-RSA-NULL-SHA      SSLv3 Kx=ECDH     Au=RSA  Enc=None      Mac=SHA1
    ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1
    ECDH-RSA-NULL-SHA       SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None      Mac=SHA1
    ECDH-ECDSA-NULL-SHA     SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None      Mac=SHA1
    NULL-SHA256             TLSv1.2 Kx=RSA      Au=RSA  Enc=None      Mac=SHA256
    NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
    NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5

    ...

The above requires a Postfix recent enough to support "postconf
-x", otherwise, drop the "x" and it'll probably still work, provided
there are no ${variable} macros in your main.cf overrides of these
parameters.

If you MUST muck around with raw OpenSSL cipherlists, the underlying

        tls_<grade>_cipherlist

parameters are present and documented, along with appropriate
warnings to not go there.

Note that Postfix will still apply implicit and configured exclusions
to these based on context (!aNULL when verifying peer certificates).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

lists@rhsoft.net
thank you for your feedback

Am 07.11.2013 23:45, schrieb Viktor Dukhovni:
> Postfix provides a more natural user interface in terms of cipher
> grades (null, export, low, medium, high).  These have sensibly easy
> to reason about security properties.
>
> I've seen many subtle and not so-subtle errors when mere mortals
> (including myself) have tried to use the raw OpenSSL cipherlist
> syntax.  

that's clear, but on the other hand having exactly the same configuration on
SMTP/POP3/IMAP makes it unlikely that a client behaves different and may
fail for the one and not for the other

> Making that be the Postfix interface would be a disservice
> to Postfix users.

in my current case where i played round over weeks with the Apache
configuration and https://www.ssllabs.com/ssltest/ the opposite
is true

>> I am speaking here about non-MX servers only for submission
>> what I most appreciate in this way of configuration is
>> openssl ciphers -v '{cipherlist}' to verify it
>
>     $ postfix_ciphers() {
> grade="$1"
> openssl ciphers -v "$(postconf -xh tls_${grade}_cipherlist)"
>       }
>
>     $ postfix_ciphers null
>     ECDHE-RSA-NULL-SHA      SSLv3 Kx=ECDH     Au=RSA  Enc=None      Mac=SHA1
>     ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1
>     ECDH-RSA-NULL-SHA       SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None      Mac=SHA1
>     ECDH-ECDSA-NULL-SHA     SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None      Mac=SHA1
>     NULL-SHA256             TLSv1.2 Kx=RSA      Au=RSA  Enc=None      Mac=SHA256
>     NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
>     NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5
>
> The above requires a Postfix recent enough to support "postconf
> -x", otherwise, drop the "x" and it'll probably still work, provided
> there are no ${variable} macros in your main.cf overrides of these
> parameters.

cool, yes always the latest stable release in use

> If you MUST muck around with raw OpenSSL cipherlists, the underlying
>
> tls_<grade>_cipherlist
> parameters are present and documented, along with appropriate
> warnings to not go there.
>
> Note that Postfix will still apply implicit and configured exclusions
> to these based on context (!aNULL when verifying peer certificates)

that does not work with "smtpd_tls_security_level = may" and "smtpd_tls_security_level = encrypt"
is impossible without breaking historical client setups nobody knows how to explain them all
to enable encryption on different devices
_______________________________

"smtpd_tls_exclude_ciphers" seems not to work as expected because DES ciphers are still enabled

[root@testserver:~]$ postconf -n | grep smtpd_tls_exclude_ciphers
smtpd_tls_exclude_ciphers = 3DES, ADH, aNULL, DES, DSS, eNULL, EXP, KRB5, MD5, PSK, RC2, SEED, SRP

[root@testserver:~]$ postconf -xh tls_high_cipherlist
aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

[root@testserver:~]$ openssl ciphers -v 'aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH'
AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5
PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
KRB5-DES-CBC3-SHA       SSLv3 Kx=KRB5     Au=KRB5 Enc=3DES(168) Mac=SHA1
KRB5-DES-CBC3-MD5       SSLv3 Kx=KRB5     Au=KRB5 Enc=3DES(168) Mac=MD5
AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Fri, Nov 08, 2013 at 12:27:13AM +0100, [hidden email] wrote:

> > If you MUST muck around with raw OpenSSL cipherlists, the underlying
> >
> > tls_<grade>_cipherlist
> >
> > parameters are present and documented, along with appropriate
> > warnings to not go there.
> >
> > Note that Postfix will still apply implicit and configured exclusions
> > to these based on context (!aNULL when verifying peer certificates)

READ THE ABOVE "Note" carefully.  The exclusions are applied on
top of the cipher grade at run time.  They don't modify the underlying
cipher list that defines the base ciphers for the grade.

> that does not work with "smtpd_tls_security_level = may" and
> "smtpd_tls_security_level = encrypt"

Pilot error.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

lists@rhsoft.net
Am 08.11.2013 00:50, schrieb Viktor Dukhovni:

> On Fri, Nov 08, 2013 at 12:27:13AM +0100, [hidden email] wrote:
>
>>> If you MUST muck around with raw OpenSSL cipherlists, the underlying
>>>
>>> tls_<grade>_cipherlist
>>>
>>> parameters are present and documented, along with appropriate
>>> warnings to not go there.
>>>
>>> Note that Postfix will still apply implicit and configured exclusions
>>> to these based on context (!aNULL when verifying peer certificates)
>
> READ THE ABOVE "Note" carefully.  The exclusions are applied on
> top of the cipher grade at run time.  They don't modify the underlying
> cipher list that defines the base ciphers for the grade.

i read it carefully but i still do not find away to get SMTP
configured with exactly the same ciphers in the same order
nor see a way to get the effective list

the intention is that i see clients with broken TLS handshakes on
SMTP while they work pretty fine on dovecot with the hardcoded
cipherlist and it's hard to impossible debug this with endusers

since they successful log into POP3/IMAP with TLS i assume the
same client would happily do the same with identical cipherlists
on SMTP while i even do not know which sort of device or if
it is more than one device behind a NAT

>> that does not work with "smtpd_tls_security_level = may" and
>> "smtpd_tls_security_level = encrypt"
>
> Pilot error

how is it a pilot error that i can't turn back time 10 years and configure
hundrets of client devices to not break them with set to "encrypt" where
especially smartphones tend to not give out any error messages to the user

there is a existing userbase from long before my time :-(
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Fri, Nov 08, 2013 at 01:05:33AM +0100, [hidden email] wrote:

> >>> Note that Postfix will still apply implicit and configured exclusions
> >>> to these based on context (!aNULL when verifying peer certificates)
> >
> > READ THE ABOVE "Note" carefully.  The exclusions are applied on
> > top of the cipher grade at run time.  They don't modify the underlying
> > cipher list that defines the base ciphers for the grade.
>
> I read it carefully, but I still do not find a way to get SMTP
> configured with exactly the same ciphers in the same order
> nor see a way to get the effective list

The effective list is the ${tls_<grade>_cipherlist} plus any
exclusions.  The grade is determined via ${smtpd_tls_ciphers} (for
smtpd_tls_security_level = may) and ${smtpd_tls_mandatory_ciphers}
(for smtpd_tls_security_level = encrypt).

The Postfix default cipher-suites are chosen to avoid freezing-in
any particular OpenSSL's version's cipher choices.  Instead of
explicit choices of discrete ciphers, cipher properties are used
to sort the lists, and make appropriate exclusions.

If you don't like the default value of:

        tls_medium_cipherlist
        tls_export_cipherlist

and for your site you prefer a different setting (generally
interoperability suffers when everyone goes their own way)
you can change this to whatever you want.

> The intention is that I see clients with broken TLS handshakes on
> SMTP while they work pretty fine on dovecot with the hardcoded
> cipherlist and it's hard to impossible debug this with endusers

tcpdump + wireshark always tell the whole story.

> > Pilot error
>
> How is it a pilot error ...

You're expecting tls_medium_cipherlist, ... to reflect cipher
exclusions.  They don't.  Cipher exclusions are applied *after*
these parameters are read.  Setting "smtpd_tls_loglevel = 2"
(on a non-default port) and connecting to that port with
"openssl s_client -starttls smtp" (or similar) will log
the actual cipherlist used by smtpd(8).

Bottom line:

    - Postfix has cipher grades, they make life easier for most users.

    - Postfix has configurable OpenSSL cipherlists for each grade.  Tweak
      these if you must.

    - Postfix appends dynamic exclusions to the ciphergrade lists as
      documented.  The combined list (with exclusions appended) is not
      directly visible via postconf.

With smtpd(8) there are no implicit exclusions so you can build the
full list yourself if you want.  For example with opportunistic TLS
(may):

    $ server_ciphers() {
        local use skip ciphers exclude e
        case $1 in
        may)
            use="tls_export_cipherlist"
            skip="smtpd_tls_exclude_ciphers";;
        encrypt)
            use="tls_medium_cipherlist"
            skip="smtpd_tls_mandatory_exclude_ciphers";;
        esac
        ciphers="$(postconf -xh $use)"
        exclude="$(postconf -xh $skip)"
        if [ -n "${exclude}" ]; then
            OIFS="$IFS"; IFS=":,$OFS"
            set -- $exclude
            IFS="$OIFS"
            for e; do ciphers="$ciphers:"'!'"$e"; done
        fi
        openssl ciphers -v "$ciphers"
    }

    $ server_ciphers encrypt

Server cipherlists don't matter much (the more the merrier), since
all the server has to do is accept one element from the client's
list.  So tuning server cipher lists is not that useful.  For
submission, you just want to exclude "EXPORT" and "LOW".  Leaving
out ciphers can just cause interoperability problems.

If the server is configured to pre-empt the client preference list,
it may be able to choose better than the client, but the client
should not offer ciphers it can't do, so this should not impact
interoperability significantly.

Finally, if you build your own Postfix server, it may be using a
more recent OpenSSL toolkit, and that can make a big difference.
Most interoperability issues are due to many new features in TLSv1.2,
instead of messing around with ciphers you could try disabling TLSv1.2,
and report whether this helps:

    smtpd_tls_protocols = !SSLv2, !TLSv1.2

Good luck!  This should be everything you need to know.  If you
find any particular combinations of settings that cause or resolve
common client interoperability issues, please report the details.

I have little interest in encouraging cipherlist tinkering, if
everyone chooses a different subset of supported ciphers interoperability
goes down.  The low level interface supports carefully targetted
work-arounds for well-defined problems.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

lists@rhsoft.net
thank you very much for all that informations

i will add this message to my documentation archive and have a look
how hard it is really needed to tweak here - also saw consumer grade
routers breaking TLS until restart them

somehow i do not expect that Outllok 2010 on Windows 8 has more problems
than on WinXP which was recently the problem with no time to debug
this deeper

Am 08.11.2013 02:17, schrieb Viktor Dukhovni:

> On Fri, Nov 08, 2013 at 01:05:33AM +0100, [hidden email] wrote:
>
>>>>> Note that Postfix will still apply implicit and configured exclusions
>>>>> to these based on context (!aNULL when verifying peer certificates)
>>>
>>> READ THE ABOVE "Note" carefully.  The exclusions are applied on
>>> top of the cipher grade at run time.  They don't modify the underlying
>>> cipher list that defines the base ciphers for the grade.
>>
>> I read it carefully, but I still do not find a way to get SMTP
>> configured with exactly the same ciphers in the same order
>> nor see a way to get the effective list
>
> The effective list is the ${tls_<grade>_cipherlist} plus any
> exclusions.  The grade is determined via ${smtpd_tls_ciphers} (for
> smtpd_tls_security_level = may) and ${smtpd_tls_mandatory_ciphers}
> (for smtpd_tls_security_level = encrypt).
>
> The Postfix default cipher-suites are chosen to avoid freezing-in
> any particular OpenSSL's version's cipher choices.  Instead of
> explicit choices of discrete ciphers, cipher properties are used
> to sort the lists, and make appropriate exclusions.
>
> If you don't like the default value of:
>
> tls_medium_cipherlist
> tls_export_cipherlist
>
> and for your site you prefer a different setting (generally
> interoperability suffers when everyone goes their own way)
> you can change this to whatever you want.
>
>> The intention is that I see clients with broken TLS handshakes on
>> SMTP while they work pretty fine on dovecot with the hardcoded
>> cipherlist and it's hard to impossible debug this with endusers
>
> tcpdump + wireshark always tell the whole story.
>
>>> Pilot error
>>
>> How is it a pilot error ...
>
> You're expecting tls_medium_cipherlist, ... to reflect cipher
> exclusions.  They don't.  Cipher exclusions are applied *after*
> these parameters are read.  Setting "smtpd_tls_loglevel = 2"
> (on a non-default port) and connecting to that port with
> "openssl s_client -starttls smtp" (or similar) will log
> the actual cipherlist used by smtpd(8).
>
> Bottom line:
>
>     - Postfix has cipher grades, they make life easier for most users.
>
>     - Postfix has configurable OpenSSL cipherlists for each grade.  Tweak
>       these if you must.
>
>     - Postfix appends dynamic exclusions to the ciphergrade lists as
>       documented.  The combined list (with exclusions appended) is not
>       directly visible via postconf.
>
> With smtpd(8) there are no implicit exclusions so you can build the
> full list yourself if you want.  For example with opportunistic TLS
> (may):
>
>     $ server_ciphers() {
> local use skip ciphers exclude e
> case $1 in
> may)
>    use="tls_export_cipherlist"
>    skip="smtpd_tls_exclude_ciphers";;
> encrypt)
>    use="tls_medium_cipherlist"
>    skip="smtpd_tls_mandatory_exclude_ciphers";;
> esac
> ciphers="$(postconf -xh $use)"
> exclude="$(postconf -xh $skip)"
> if [ -n "${exclude}" ]; then
>    OIFS="$IFS"; IFS=":,$OFS"
>    set -- $exclude
>    IFS="$OIFS"
>    for e; do ciphers="$ciphers:"'!'"$e"; done
> fi
> openssl ciphers -v "$ciphers"
>     }
>
>     $ server_ciphers encrypt
>
> Server cipherlists don't matter much (the more the merrier), since
> all the server has to do is accept one element from the client's
> list.  So tuning server cipher lists is not that useful.  For
> submission, you just want to exclude "EXPORT" and "LOW".  Leaving
> out ciphers can just cause interoperability problems.
>
> If the server is configured to pre-empt the client preference list,
> it may be able to choose better than the client, but the client
> should not offer ciphers it can't do, so this should not impact
> interoperability significantly.
>
> Finally, if you build your own Postfix server, it may be using a
> more recent OpenSSL toolkit, and that can make a big difference.
> Most interoperability issues are due to many new features in TLSv1.2,
> instead of messing around with ciphers you could try disabling TLSv1.2,
> and report whether this helps:
>
>     smtpd_tls_protocols = !SSLv2, !TLSv1.2
>
> Good luck!  This should be everything you need to know.  If you
> find any particular combinations of settings that cause or resolve
> common client interoperability issues, please report the details.
>
> I have little interest in encouraging cipherlist tinkering, if
> everyone chooses a different subset of supported ciphers interoperability
> goes down.  The low level interface supports carefully targetted
> work-arounds for well-defined problems.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
On Fri, Nov 08, 2013 at 01:17:54AM +0000, Viktor Dukhovni wrote:

> With smtpd(8) there are no implicit exclusions so you can build the
> full list yourself if you want.  For example with opportunistic TLS
> (may):

One minor correction, with either of:

        smtpd_tls_ask_ccert = yes
        smtpd_tls_req_ccert = yes

the Postfix SMTP server automatically excludes aNULL ciphers
(otherwise the client can't present its own cert).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

A. Schulze
In reply to this post by Viktor Dukhovni

Zitat von Viktor Dukhovni <[hidden email]>:


> With smtpd(8) there are no implicit exclusions so you can build the
> full list yourself if you want.  For example with opportunistic TLS
> (may):
>
>     $ server_ciphers() {
> local use skip ciphers exclude e
> case $1 in
> may)
>    use="tls_export_cipherlist"
>    skip="smtpd_tls_exclude_ciphers";;
> encrypt)
>    use="tls_medium_cipherlist"
>    skip="smtpd_tls_mandatory_exclude_ciphers";;
> esac
> ciphers="$(postconf -xh $use)"
> exclude="$(postconf -xh $skip)"
> if [ -n "${exclude}" ]; then
>    OIFS="$IFS"; IFS=":,$OFS"
>    set -- $exclude
>    IFS="$OIFS"
>    for e; do ciphers="$ciphers:"'!'"$e"; done
> fi
> openssl ciphers -v "$ciphers"
>     }
>
>     $ server_ciphers encrypt

Viktor,

thanks for the script. it helped me to _really_ unserstand how postfix  
uses tls.

But when I disable RC4 in smtpd_tls_exclude_ciphers (I assume) it's  
also not used
when I enforce encrypt mode !? This script don't say so.

Also the script don't handle situations where smtpd_tls_ciphers set to  
'high' for example.
I replaced the selected cipherlist based on smtpd_tls_ciphers /  
smtpd_tls_mandatory_ciphers.

So here is my update (without any optimization !)

server_ciphers() {
         local use skip ciphers exclude e
         case $1 in
         may)
             grade="$(postconf -xh smtpd_tls_ciphers)"
             use="tls_${grade}_cipherlist"
             skip1="smtpd_tls_exclude_ciphers"
             skip2="";;
         encrypt)
             grade="$(postconf -xh smtpd_tls_mandatory_ciphers)"
             use="tls_${grade}_cipherlist"
             skip1="smtpd_tls_exclude_ciphers"
             skip2="smtpd_tls_mandatory_exclude_ciphers";;
         esac
         ciphers="$(postconf -xh $use)"
         exclude1="$(postconf -xh $skip1)"
         if [ -n "${exclude1}" ]; then
             OIFS="$IFS"; IFS=":,$OFS"
             set -- $exclude1
             IFS="$OIFS"
             for e; do ciphers="$ciphers:"'!'"$e"; done
         fi
         if [ -n "${skip2}" ]; then
             exclude2="$(postconf -xh $skip2)"
             if [ -n "${exclude2}" ]; then
                 OIFS="$IFS"; IFS=":,$OFS"
                 set -- $exclude2
                 IFS="$OIFS"
                 for e; do ciphers="$ciphers:"'!'"$e"; done
             fi
         fi
         openssl ciphers -v "$ciphers"
}

correct?

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Sat, Nov 23, 2013 at 10:40:05PM +0100, Andreas Schulze wrote:

> But when I disable RC4 in smtpd_tls_exclude_ciphers (I assume) it's
> also not used when I enforce encrypt mode !? This script don't say so.

Yes, you're right, the script did not cover that case accurately,
the code from smtpd(8) reads:

        cipher_exclusions = vstring_alloc(10);
        ADD_EXCLUDE(cipher_exclusions, var_smtpd_tls_excl_ciph);
        if (var_smtpd_enforce_tls)
            ADD_EXCLUDE(cipher_exclusions, var_smtpd_tls_mand_excl);
        if (ask_client_cert)
            ADD_EXCLUDE(cipher_exclusions, "aNULL");

> Also the script don't handle situations where smtpd_tls_ciphers set
> to 'high' for example.

Yes, though that setting is substantially likely to have interoperability
issues.  Your weakest link is unlikely to be any of the medium ciphers.

> So here is my update (without any optimization !)

> server_ciphers() {
>         local use skip ciphers exclude e
>         case $1 in
>         may)
>             grade="$(postconf -xh smtpd_tls_ciphers)"
>             use="tls_${grade}_cipherlist"
>             skip1="smtpd_tls_exclude_ciphers"
>             skip2="";;
>         encrypt)
>             grade="$(postconf -xh smtpd_tls_mandatory_ciphers)"
>             use="tls_${grade}_cipherlist"
>             skip1="smtpd_tls_exclude_ciphers"
>             skip2="smtpd_tls_mandatory_exclude_ciphers";;
>         esac
>         ciphers="$(postconf -xh $use)"
>         exclude1="$(postconf -xh $skip1)"
>         if [ -n "${exclude1}" ]; then
>             OIFS="$IFS"; IFS=":,$OFS"
>             set -- $exclude1
>             IFS="$OIFS"
>             for e; do ciphers="$ciphers:"'!'"$e"; done
>         fi
>         if [ -n "${skip2}" ]; then
>             exclude2="$(postconf -xh $skip2)"
>             if [ -n "${exclude2}" ]; then
>                 OIFS="$IFS"; IFS=":,$OFS"
>                 set -- $exclude2
>                 IFS="$OIFS"
>                 for e; do ciphers="$ciphers:"'!'"$e"; done
>             fi
>         fi
>         openssl ciphers -v "$ciphers"
> }
>
> correct?

Yes, but your local variable list no longer matches exactly the
variables used in the code (grade, skip1, skip2 are not covered,
while skip is no longer used).  The "local" built-in is I should
note not POSIX.  Some shells may not support it.

For bonus points, you could look at "smtpd_tls_askccert" and
"smtpd_tls_req_ccert".  If either is set to "yes", append ':!aNULL'
to the raw openssl cipher list.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

A. Schulze

Zitat von Viktor Dukhovni <[hidden email]>:

> For bonus points, you could look at "smtpd_tls_askccert" and
> "smtpd_tls_req_ccert".  If either is set to "yes", append ':!aNULL'
> to the raw openssl cipher list.

could you please tell more about that?

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Sat, Nov 23, 2013 at 11:08:56PM +0100, Andreas Schulze wrote:

> >For bonus points, you could look at "smtpd_tls_askccert" and
> >"smtpd_tls_req_ccert".  If either is set to "yes", append ':!aNULL'
> >to the raw openssl cipher list.
>
> could you please tell more about that?

Not much more to tell, anonymous ciphers are disabled when the
server wants to request client certs.  The TLS protocol does not
make it possible for client certs to be requested during the initial
handshake in when the server is anonymous.

A little knowledge is a dangerous thing.  Just because I've explained
the Postfix cipherlists in more detail, does not mean that it is
now a good idea to tweak them.  Most changes are likely to be
counter-productive.

To defend against PRISM, ... defend the endpoints, the crypto is
not the weakest link.

--
        Viktor.

server_cipherlist() {
    local level grade use skip ciphers exclude e
    level=$(postconf -xh smtpd_tls_security_level)
    case $level in
    none)       return 0;;
    may)        grade="$(postconf -xh smtpd_tls_ciphers)"
                use="tls_${grade}_cipherlist"
                skip="smtpd_tls_exclude_ciphers";;
    encrypt)    grade="$(postconf -xh smtpd_tls_mandatory_ciphers)"
                use="tls_${grade}_cipherlist"
                skip="smtpd_tls_exclude_ciphers"
                skip="$skip smtpd_tls_mandatory_exclude_ciphers";;
    *)          echo "Invalid security level: ${level}" >&2; return 1;;
    esac
    ciphers="$(postconf -xh $use)"
    for askcc in smtpd_ask_ccert smtpd_req_ccert
    do
        case "$(postconf -xh "${askcc}")" in
        [Yy][Ee][Ss]) ciphers="$ciphers:"'!aNULL'; break;;
        esac
    done
    exclude="$(postconf -xh $skip)"
    if [ -n "${exclude}" ]
    then
        OIFS="$IFS"; IFS=":,$OFS" set -- $exclude; IFS="$OIFS"
        for e; do ciphers="$ciphers:"'!'"$e"; done
    fi
    echo "$ciphers"
}

clist=$(server_cipherlist)
if [ $? -eq 0 -a -n "$clist" ]; then openssl ciphers -v "$clist"; fi
Reply | Threaded
Open this post in threaded view
|

Re: explicit cipher list

Viktor Dukhovni
On Sat, Nov 23, 2013 at 10:42:23PM +0000, Viktor Dukhovni wrote:

>     for askcc in smtpd_ask_ccert smtpd_req_ccert

Make that:

      for askcc in smtpd_tls_ask_ccert smtpd_tls_req_ccert

--
        Viktor.