Disabling Anonymous Diffie Hellman

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

Disabling Anonymous Diffie Hellman

Colin Fowler
ADH is susceptible to MITM attacks, but I can't seem to turn it off.

I've tried various permutations of

tls_preempt_cipherlist = yes
tls_high_cipherlist  (with !DH and !ADH)
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high

I'm running 2.9.6 on Debian Wheezy.

Any help appreciated. Thanks :)
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

lists@rhsoft.net

Am 20.05.2014 13:03, schrieb Colin Fowler:

> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
>
> I've tried various permutations of
>
> tls_preempt_cipherlist = yes
> tls_high_cipherlist  (with !DH and !ADH)
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtpd_tls_mandatory_ciphers = high
>
> I'm running 2.9.6 on Debian Wheezy.
>
> Any help appreciated. Thanks :)

don't do that on a public MX
don't do that if you have clients with Outlook in WinXP (supported or not is out of scope)

a few days ago we had a genius with troubles caused by !SSLv3
because the delivering server did not support TLS1, so what
you achieve at the end of the day is failing connections or
fallback to plaintext and so you hardly make anything better

if it is *not* a public MX
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, MD5, IDEA, KRB5, RC2, SEED, SRP

if it *is* a public MX maybe reconsider that in general
in any case !SSLv3 will break your setup

Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Colin Fowler
On 20-05-2014 12:16, [hidden email] wrote:

> Am 20.05.2014 13:03, schrieb Colin Fowler:
>> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
>>
>> I've tried various permutations of
>>
>> tls_preempt_cipherlist = yes
>> tls_high_cipherlist  (with !DH and !ADH)
>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
>> smtpd_tls_mandatory_ciphers = high
>>
>> I'm running 2.9.6 on Debian Wheezy.
>>
>> Any help appreciated. Thanks :)
>
> don't do that on a public MX
> don't do that if you have clients with Outlook in WinXP (supported or
> not is out of scope)
>
> a few days ago we had a genius with troubles caused by !SSLv3
> because the delivering server did not support TLS1, so what
> you achieve at the end of the day is failing connections or
> fallback to plaintext and so you hardly make anything better
>
> if it is *not* a public MX
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, MD5, IDEA, KRB5, RC2,
> SEED, SRP
>
> if it *is* a public MX maybe reconsider that in general
> in any case !SSLv3 will break your setup


Thanks for the reply. Just to be clear, My setup now allows the
following protocols: SSLv3, TLSv1, TLSv1.1 TLSv1.2. SSLv2 is now
disabled.
I have enabled smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, MD5,
IDEA, KRB5, RC2 as suggested.
See below for output of  sslyze --regular --starttls=auto <myip>:25

Two questions

1) Is this setup bad for WinXP outlook clients as it stands now?
2) Is disabling 56 bit DES a good idea? If so, how would I go about
that?

Thanks again,
         Colin











*********************************************************************

  sslyze --regular --starttls=auto <myip>:25



   * Session Resumption:
       With Session IDs:                  Supported (5 successful, 0
failed, 0 errors, 5 total attempts).
       With TLS Session Tickets:          Not Supported - TLS ticket
assigned but not accepted.

   * SSLV2 Cipher Suites:
       Server rejected all cipher suites.

   * TLSV1_2 Cipher Suites:
       Preferred:
                  ECDHE-RSA-AES256-GCM-SHA384   256 bits      250 2.0.0
Ok
       Accepted:
                  EDH-RSA-DES-CBC-SHA           56 bits       250 2.0.0
Ok
                  DES-CBC-SHA                   56 bits       250 2.0.0
Ok
                  ECDHE-RSA-AES256-SHA384       256 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES256-GCM-SHA384   256 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA256-SHA       256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-SHA256         256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-SHA            256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-GCM-SHA384     256 bits      250 2.0.0
Ok
                  CAMELLIA256-SHA               256 bits      250 2.0.0
Ok
                  AES256-SHA256                 256 bits      250 2.0.0
Ok
                  AES256-SHA                    256 bits      250 2.0.0
Ok
                  AES256-GCM-SHA384             256 bits      250 2.0.0
Ok
                  EDH-RSA-DES-CBC3-SHA          168 bits      250 2.0.0
Ok
                  ECDHE-RSA-DES-CBC3-SHA        168 bits      250 2.0.0
Ok
                  DES-CBC3-SHA                  168 bits      250 2.0.0
Ok
                  RC4-SHA                       128 bits      250 2.0.0
Ok
                  ECDHE-RSA-RC4-SHA             128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-SHA256       128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-SHA          128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-GCM-SHA256   128 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA128-SHA       128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-SHA256         128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-SHA            128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-GCM-SHA256     128 bits      250 2.0.0
Ok
                  CAMELLIA128-SHA               128 bits      250 2.0.0
Ok
                  AES128-SHA256                 128 bits      250 2.0.0
Ok
                  AES128-SHA                    128 bits      250 2.0.0
Ok
                  AES128-GCM-SHA256             128 bits      250 2.0.0
Ok

   * TLSV1_1 Cipher Suites:
       Preferred:
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
       Accepted:
                  EDH-RSA-DES-CBC-SHA           56 bits       250 2.0.0
Ok
                  DES-CBC-SHA                   56 bits       250 2.0.0
Ok
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA256-SHA       256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-SHA            256 bits      250 2.0.0
Ok
                  CAMELLIA256-SHA               256 bits      250 2.0.0
Ok
                  AES256-SHA                    256 bits      250 2.0.0
Ok
                  EDH-RSA-DES-CBC3-SHA          168 bits      250 2.0.0
Ok
                  ECDHE-RSA-DES-CBC3-SHA        168 bits      250 2.0.0
Ok
                  DES-CBC3-SHA                  168 bits      250 2.0.0
Ok
                  RC4-SHA                       128 bits      250 2.0.0
Ok
                  ECDHE-RSA-RC4-SHA             128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-SHA          128 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA128-SHA       128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-SHA            128 bits      250 2.0.0
Ok
                  CAMELLIA128-SHA               128 bits      250 2.0.0
Ok
                  AES128-SHA                    128 bits      250 2.0.0
Ok

   * TLSV1 Cipher Suites:
       Preferred:
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
       Accepted:
                  EDH-RSA-DES-CBC-SHA           56 bits       250 2.0.0
Ok
                  DES-CBC-SHA                   56 bits       250 2.0.0
Ok
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA256-SHA       256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-SHA            256 bits      250 2.0.0
Ok
                  CAMELLIA256-SHA               256 bits      250 2.0.0
Ok
                  AES256-SHA                    256 bits      250 2.0.0
Ok
                  EDH-RSA-DES-CBC3-SHA          168 bits      250 2.0.0
Ok
                  ECDHE-RSA-DES-CBC3-SHA        168 bits      250 2.0.0
Ok
                  DES-CBC3-SHA                  168 bits      250 2.0.0
Ok
                  RC4-SHA                       128 bits      250 2.0.0
Ok
                  ECDHE-RSA-RC4-SHA             128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-SHA          128 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA128-SHA       128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-SHA            128 bits      250 2.0.0
Ok
                  CAMELLIA128-SHA               128 bits      250 2.0.0
Ok
                  AES128-SHA                    128 bits      250 2.0.0
Ok

   * SSLV3 Cipher Suites:
       Preferred:
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
       Accepted:
                  EDH-RSA-DES-CBC-SHA           56 bits       250 2.0.0
Ok
                  DES-CBC-SHA                   56 bits       250 2.0.0
Ok
                  ECDHE-RSA-AES256-SHA          256 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA256-SHA       256 bits      250 2.0.0
Ok
                  DHE-RSA-AES256-SHA            256 bits      250 2.0.0
Ok
                  CAMELLIA256-SHA               256 bits      250 2.0.0
Ok
                  AES256-SHA                    256 bits      250 2.0.0
Ok
                  EDH-RSA-DES-CBC3-SHA          168 bits      250 2.0.0
Ok
                  ECDHE-RSA-DES-CBC3-SHA        168 bits      250 2.0.0
Ok
                  DES-CBC3-SHA                  168 bits      250 2.0.0
Ok
                  RC4-SHA                       128 bits      250 2.0.0
Ok
                  ECDHE-RSA-RC4-SHA             128 bits      250 2.0.0
Ok
                  ECDHE-RSA-AES128-SHA          128 bits      250 2.0.0
Ok
                  DHE-RSA-CAMELLIA128-SHA       128 bits      250 2.0.0
Ok
                  DHE-RSA-AES128-SHA            128 bits      250 2.0.0
Ok
                  CAMELLIA128-SHA               128 bits      250 2.0.0
Ok
                  AES128-SHA                    128 bits      250 2.0.0
Ok
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
In reply to this post by Colin Fowler
On Tue, May 20, 2014 at 12:03:29PM +0100, Colin Fowler wrote:

> ADH is susceptible to MITM attacks, but I can't seem to turn it off.

Opportunistic TLS, which is all that is possible for SMTP without
DANE (DNSSEC with TLSA records for SMTP) is vulnerable to multiple
MiTM attacks, and turning off NULL authentication cipher-suites
does not change this, it just sweeps the problem (that clients
don't and can't authenticate your server) under the rug.  See:

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-1.3

> I've tried various permutations of

Your attempts are misguided.  It is best to leave aNULL cipher-suites
enabled.  See:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-8.2

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

Re: Disabling Anonymous Diffie Hellman

Thomas Leuxner
In reply to this post by lists@rhsoft.net
* [hidden email] <[hidden email]> 2014.05.20 13:16:

> a few days ago we had a genius with troubles caused by !SSLv3

Nice one. Not really sure your slander is the result of your language skills or you actually gain something from calling other people names. In any case you miserably failed to elaborate how to mitigate the issue other than stating 'revert the change'. Hardly any useful detail in that.

BR
Thoams

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

lists@rhsoft.net


Am 20.05.2014 14:25, schrieb Thomas Leuxner:
> * [hidden email] <[hidden email]> 2014.05.20 13:16:
>
>> a few days ago we had a genius with troubles caused by !SSLv3
>
> Nice one. Not really sure your slander is the result of your language
> skills or you actually gain something from calling other people names

that was the nice version of "why do you want change settings you
obviously don't understand" and the only reason why you are pissed
is that you where the one stating "A quick test with SSL3 enabled
allows a TLS connection from this particular server" in a thread
start instead just revert the change to !SSLv3 you made before

> In any case you miserably failed to elaborate how to mitigate the issue
> other than stating 'revert the change'. Hardly any useful detail in that.

which useful detail did you miss?

* i explained that !SSLv3 will break several clients
* i explained even how to achieve the subject
* i explained even why it is mostly a bad idea to do so in case of a MX
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
In reply to this post by Thomas Leuxner
On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:

> In any case you miserably failed to elaborate how to mitigate
> the issue other than stating 'revert the change'.

Without defending the tone of that advice, I'd like to affirm its
technical content.  Receiving MTAs should not disable SSLv3, they
gain nothing by doing so, all that happens is that clients that
are only capable of SSLv3 are forced to send in the clear.

Even sending MTAs should not disable SSLv3, since it is possible
and normal to send all relevant TLSv1 and later extensions in SSLv3
HELLO messages (provided the client also offers to negotiate
TLSv1 or greater), they just get ignored by SSLv3-only servers.

Opportunistic TLS is sometimes counter-intuitive, attempting to
make it stronger by removing weaker features actually makes it
weaker.  Don't give in to the urge to tweak TLS settings, they
are largely fine as they are.

In an upcoming Postfix 2.12 snapshot, I will change the definition
of tls_export_cipherlist to by default exclude "EXPORT" and "LOW"
ciphers, you can achieve the same effect now by setting:

    smtp_tls_exclude_ciphers = EXPORT, LOW
    smtpd_tls_exclude_ciphers = EXPORT, LOW

The reason this is safe, is that fortunately there are no longer
any systems that are not capable of using one of the stronger
ciphersuites, at least RC4-128 or 3DES.

Most other "hardening" configuration changes are likely to reduce,
rather than improve SMTP transport security.

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

Re: Disabling Anonymous Diffie Hellman

Thomas Leuxner
* Viktor Dukhovni <[hidden email]> 2014.05.20 14:44:

> Most other "hardening" configuration changes are likely to reduce,
> rather than improve SMTP transport security.

Thank you for your detailed explanation Viktor!

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Colin Fowler
In reply to this post by Viktor Dukhovni
Thank you Viktor for your reply!

On 20-05-2014 13:44, Viktor Dukhovni wrote:

> On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
>
>> In any case you miserably failed to elaborate how to mitigate
>> the issue other than stating 'revert the change'.
>
> Without defending the tone of that advice, I'd like to affirm its
> technical content.  Receiving MTAs should not disable SSLv3, they
> gain nothing by doing so, all that happens is that clients that
> are only capable of SSLv3 are forced to send in the clear.
>
> Even sending MTAs should not disable SSLv3, since it is possible
> and normal to send all relevant TLSv1 and later extensions in SSLv3
> HELLO messages (provided the client also offers to negotiate
> TLSv1 or greater), they just get ignored by SSLv3-only servers.
>
> Opportunistic TLS is sometimes counter-intuitive, attempting to
> make it stronger by removing weaker features actually makes it
> weaker.  Don't give in to the urge to tweak TLS settings, they
> are largely fine as they are.
>

Is it not true though that allowing weak features merely gives the
illusion of security?
It could be argued that a weak method is technically no better than no
encryption so removing the weak method just removes the illusion (which
some would say was a gain).



> In an upcoming Postfix 2.12 snapshot, I will change the definition
> of tls_export_cipherlist to by default exclude "EXPORT" and "LOW"
> ciphers, you can achieve the same effect now by setting:
>
>     smtp_tls_exclude_ciphers = EXPORT, LOW
>     smtpd_tls_exclude_ciphers = EXPORT, LOW
>
> The reason this is safe, is that fortunately there are no longer
> any systems that are not capable of using one of the stronger
> ciphersuites, at least RC4-128 or 3DES.
>
> Most other "hardening" configuration changes are likely to reduce,
> rather than improve SMTP transport security.

I've heard anecdotes of clients not using the best mutually supported
encryption and instead just using whatever's first in the list of
methods accepted by the server. I don't have anything to back this up
though. Ever heard of this? If this was true, then disabling weak
methods might be beneficial.


thanks again,
         Colin
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Jonas Wielicki
On 20.05.2014 15:11, Colin Fowler wrote:

> Thank you Viktor for your reply!
>
> On 20-05-2014 13:44, Viktor Dukhovni wrote:
>> On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
>>
>>> In any case you miserably failed to elaborate how to mitigate
>>> the issue other than stating 'revert the change'.
>>
>> Without defending the tone of that advice, I'd like to affirm its
>> technical content.  Receiving MTAs should not disable SSLv3, they
>> gain nothing by doing so, all that happens is that clients that
>> are only capable of SSLv3 are forced to send in the clear.
>>
>> Even sending MTAs should not disable SSLv3, since it is possible
>> and normal to send all relevant TLSv1 and later extensions in SSLv3
>> HELLO messages (provided the client also offers to negotiate
>> TLSv1 or greater), they just get ignored by SSLv3-only servers.
>>
>> Opportunistic TLS is sometimes counter-intuitive, attempting to
>> make it stronger by removing weaker features actually makes it
>> weaker.  Don't give in to the urge to tweak TLS settings, they
>> are largely fine as they are.
>>
>
> Is it not true though that allowing weak features merely gives the
> illusion of security?
> It could be argued that a weak method is technically no better than no
> encryption so removing the weak method just removes the illusion (which
> some would say was a gain).

Opportunistic Encryption as performed by SMTP is merely a band-aid. It
doesn’t claim to be actually secure, but it claims to do its best -- and
sometimes the best you can get is to do anonymous DH, which at least
protects you against a passive eavesdropper (although an active attacker
will be able to spoof the connection). Disabling ADH would make that
connection drop back to plaintext, which is worse because it cannot even
protect against a passive eavesdropper.

As said elsewhere, without DANE+DNSSEC, this is the best we can get
right now.

regards,
Jonas
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

lists@rhsoft.net
In reply to this post by Colin Fowler


Am 20.05.2014 15:11, schrieb Colin Fowler:
> Is it not true though that allowing weak features merely
> gives the illusion of security? It could be argued that a
> weak method is technically no better than no encryption

not in reality

with no encryption at all any boy sharing the same
WLAN is able to read your unencrypted passwords and
content with *any* sniffer

in case of weak encrypted content at least it needs
a minimum of technical knowledge and real interest

the difference between "real interest" and "i got
served the content for free" may make the difference

> so removing the weak method just removes the illusion
> (which some would say was a gain)

which illusion?

if you disable any weak encryption and the delivering
server falls back to plaintext you gained nothing nor
will any enduser ever know about it

>> In an upcoming Postfix 2.12 snapshot, I will change the definition
>> of tls_export_cipherlist to by default exclude "EXPORT" and "LOW"
>> ciphers, you can achieve the same effect now by setting:
>>
>>     smtp_tls_exclude_ciphers = EXPORT, LOW
>>     smtpd_tls_exclude_ciphers = EXPORT, LOW
>>
>> The reason this is safe, is that fortunately there are no longer
>> any systems that are not capable of using one of the stronger
>> ciphersuites, at least RC4-128 or 3DES.
>>
>> Most other "hardening" configuration changes are likely to reduce,
>> rather than improve SMTP transport security.
>
> I've heard anecdotes of clients not using the best mutually supported encryption and instead just using whatever's
> first in the list of methods accepted by the server. I don't have anything to back this up though. Ever heard of
> this? If this was true, then disabling weak methods might be beneficial.

depends on the client

if the client is postfix devliver a message a remote postfix it looks completly
different, the selected encryption below is from one postfix supporting SSL3 to
another one supporting SSL3 and it selected the currently best available one

TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
In reply to this post by Colin Fowler
On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:

> >Opportunistic TLS is sometimes counter-intuitive, attempting to
> >make it stronger by removing weaker features actually makes it
> >weaker.  Don't give in to the urge to tweak TLS settings, they
> >are largely fine as they are.
> >
>
> Is it not true though that allowing weak features merely gives the illusion
> of security?

Opportunistic TLS, is only secure against passive attacks.  Against
passive attackers, any encryption, even weak is better than no
encryption.  This applies even more strongly to authentication or
lack thereof.  Authentication adds no protection against passive
attacks, once you've negotiated ephemeral keys (ideally with PFS,
see http://www.postfix.org/FORWARD_SECRECY_README.html) you're set.

> It could be argued that a weak method is technically no better than no
> encryption so removing the weak method just removes the illusion (which some
> would say was a gain).

All kinds of misguided points of view could be argued. :-)

> >Most other "hardening" configuration changes are likely to reduce,
> >rather than improve SMTP transport security.
>
> I've heard anecdotes of clients not using the best mutually supported
> encryption and instead just using whatever's first in the list of methods
> accepted by the server. I don't have anything to back this up though. Ever
> heard of this? If this was true, then disabling weak methods might be
> beneficial.

This is not how TLS works, the client sends a list of cipher-suites,
and the server chooses exactly one of these.  Depending on server
configuration, this is either the client's most preferred cipher
also supported by the server or else the server's most preferred
cipher supported by the client.

Grossly misconfigured clients or servers might choose weak
cipher-suites, but I've never seen this happen in practice.

If you disable EXPORT and LOW, the rest are substantially better
than cleartext even with the recent statistical anomalies in the
first 256 bytes of RC4 output.  Forcing the client to use cleartext
is not a better option.  However, one might want to use the server's
cipher preferences on the submission port:

    submission inet ... smtpd
      -o tls_preempt_cipherlist=yes
      ...

where it is unlikely to run into friction with remote Exchange 2003
servers (unless you're hosting remote Exchange MTAs as submission
clients).

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

Re: Disabling Anonymous Diffie Hellman

Colin Fowler
Thank you Viktor (and other commenters)

One of the primary reasons I use {ostfix is because of its great track
record in security (its stability, performance and feature set are also
great too). It would be foolish of me to disregard the devs who have
achieved helped give Postfix its recommendation. I'll stick with
excluding EXPORT and LOW as you mentioned earlier.

BTW, this whole thing came about from me testing using
https://starttls.info/ which scored what I thought was a well secured
server quite badly. I see now that the testing site is itself the
problem, not my original config.

thanks again,
          Colin










On 20-05-2014 14:25, Viktor Dukhovni wrote:

> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>
>> >Opportunistic TLS is sometimes counter-intuitive, attempting to
>> >make it stronger by removing weaker features actually makes it
>> >weaker.  Don't give in to the urge to tweak TLS settings, they
>> >are largely fine as they are.
>> >
>>
>> Is it not true though that allowing weak features merely gives the
>> illusion
>> of security?
>
> Opportunistic TLS, is only secure against passive attacks.  Against
> passive attackers, any encryption, even weak is better than no
> encryption.  This applies even more strongly to authentication or
> lack thereof.  Authentication adds no protection against passive
> attacks, once you've negotiated ephemeral keys (ideally with PFS,
> see http://www.postfix.org/FORWARD_SECRECY_README.html) you're set.
>
>> It could be argued that a weak method is technically no better than
>> no
>> encryption so removing the weak method just removes the illusion
>> (which some
>> would say was a gain).
>
> All kinds of misguided points of view could be argued. :-)
>
>> >Most other "hardening" configuration changes are likely to reduce,
>> >rather than improve SMTP transport security.
>>
>> I've heard anecdotes of clients not using the best mutually
>> supported
>> encryption and instead just using whatever's first in the list of
>> methods
>> accepted by the server. I don't have anything to back this up
>> though. Ever
>> heard of this? If this was true, then disabling weak methods might
>> be
>> beneficial.
>
> This is not how TLS works, the client sends a list of cipher-suites,
> and the server chooses exactly one of these.  Depending on server
> configuration, this is either the client's most preferred cipher
> also supported by the server or else the server's most preferred
> cipher supported by the client.
>
> Grossly misconfigured clients or servers might choose weak
> cipher-suites, but I've never seen this happen in practice.
>
> If you disable EXPORT and LOW, the rest are substantially better
> than cleartext even with the recent statistical anomalies in the
> first 256 bytes of RC4 output.  Forcing the client to use cleartext
> is not a better option.  However, one might want to use the server's
> cipher preferences on the submission port:
>
>     submission inet ... smtpd
>       -o tls_preempt_cipherlist=yes
>       ...
>
> where it is unlikely to run into friction with remote Exchange 2003
> servers (unless you're hosting remote Exchange MTAs as submission
> clients).

Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
On Tue, May 20, 2014 at 02:35:04PM +0100, Colin Fowler wrote:

> BTW, this whole thing came about from me testing using
> https://starttls.info/ which scored what I thought was a well secured server
> quite badly. I see now that the testing site is itself the problem, not my
> original config.

Yep, the site is clueless.  My DNSSEC + DANE validated domain scores a "D":

    mx1.dukhovni.org: Grade: D (43.5%)

    Certificate:

      * The certificate is not valid for the server's hostname.
      * There is a self-signed certificate in the trust chain. It may be a
        configuration problem.
      * There are one or more fatal problems which causes the
        certificate not to be trusted.

    There are validity issues for the certificate. Certificates
    are seldom verified for SMTP servers, so this doesn't mean that
    STARTTLS won't be used.

[ Actually, I have one of the few SMTP domains whose certificate can be
  used for MiTM-resistant authentication. ]

    Generally speaking it's a bad practice not to have a valid
    certificate, and an even worse practice not to verify them.
    Any attempted encrypted communication is left all but wide open
    to Man-in-the-Middle attacks.

[ Except that not authenticating certificates is exactly what one
  needs to do with SMTP. ]

    Protocol:

      * Supports SSLV3.
      * Supports TLSV1.
      * Supports TLSV1.1.

    Key exchange:

      * Anonymous Diffie-Hellman is accepted. This is suspectible to
        Man-in-the-Middle attacks.

[ But DANE clients won't offer this.  And server support of aNULL ciphers
  is always harmless, and makes it easier to determine which clients are
  not authenticating the server.  Pretending client offers of aNULL ciphers
  did not happen does not improve security. ]


      * Key size is 1024 bits; that's somewhat insecure.

[ Fine, will be changed when the server is upgraded... ]

    Cipher:

      * Weakest accepted cipher: 0.
      * Strongest accepted cipher: 256.

[ Scoring aNULL as "0" is simply wrong. ]


This site is useless.

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

Re: Disabling Anonymous Diffie Hellman

Per Thorsheim
In reply to this post by Colin Fowler
As the initiator of https://starttls.info/ (developed and run by Einar
Otto Stangvik), let me just say that I've e-mailed this list earlier on
this topic.

While Viktor shows very clearly why starttls by itself is insufficient
through his IETF draft, I still personally vote for disabling SSLv2 and
ANON ciphers used with STARTTLS as we do today. My reasoning is simple:
if we continue to support old & insecure ciphers etc, there is less
incentive for moving forward to safer solutions. We did discuss and
change the scoring soon after the service launched, while originally
being based on the scoring system from Ivan Ristic @ Qualys at
ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
creating our own scoring system.

On May 13 Facebook published "The Current State of SMTP STARTTLS Deployment"
https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223

Allow me to quote them:
"The majority of encrypted email is sent with the ECDHE-RSA-RC4-SHA or
DHE-RSA-AES256-SHA cipher suite. This is likely due to those being the
preferred cipher suites of the major providers. DHE-RSA-AES128-SHA,
however, is the preferred cipher suite for the largest percentage of
deployments. AES128-SHA is the next most prevalent, which is concerning
because it does not provide Perfect Forward Secrecy."

Facebook are concerned over the lack of PFS. Right. Well, we started out
by saying we were concerned over SSLv2, ANON suites and expired
certificates.

One of our goals with starttls.info was to aid in the global deployment
of STARTTLS, another goal was to improve the minimum level used by
anyone deploying STARTTLS. That is until Viktors IETF proposal, or
anything similar, reaches broad adoption on the Internet.

Best regards,
Per Thorsheim



Den 20.05.2014 15:35, skrev Colin Fowler:

> Thank you Viktor (and other commenters)
>
> One of the primary reasons I use {ostfix is because of its great
> track record in security (its stability, performance and feature set
> are also great too). It would be foolish of me to disregard the devs
> who have achieved helped give Postfix its recommendation. I'll stick
> with excluding EXPORT and LOW as you mentioned earlier.
>
> BTW, this whole thing came about from me testing using
> https://starttls.info/ which scored what I thought was a well secured
> server quite badly. I see now that the testing site is itself the
> problem, not my original config.
>
> thanks again, Colin
>
>
>
> On 20-05-2014 14:25, Viktor Dukhovni wrote:
>> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>>
>>>> Opportunistic TLS is sometimes counter-intuitive, attempting
>>>> to make it stronger by removing weaker features actually makes
>>>> it weaker.  Don't give in to the urge to tweak TLS settings,
>>>> they are largely fine as they are.
>>>>
>>>
>>> Is it not true though that allowing weak features merely gives
>>> the illusion of security?
>>
>> Opportunistic TLS, is only secure against passive attacks.
>> Against passive attackers, any encryption, even weak is better than
>> no encryption.  This applies even more strongly to authentication
>> or lack thereof.  Authentication adds no protection against
>> passive attacks, once you've negotiated ephemeral keys (ideally
>> with PFS, see http://www.postfix.org/FORWARD_SECRECY_README.html)
>> you're set.
>>
>>> It could be argued that a weak method is technically no better
>>> than no encryption so removing the weak method just removes the
>>> illusion (which some would say was a gain).
>>
>> All kinds of misguided points of view could be argued. :-)
>>
>>>> Most other "hardening" configuration changes are likely to
>>>> reduce, rather than improve SMTP transport security.
>>>
>>> I've heard anecdotes of clients not using the best mutually
>>> supported encryption and instead just using whatever's first in
>>> the list of methods accepted by the server. I don't have anything
>>> to back this up though. Ever heard of this? If this was true,
>>> then disabling weak methods might be beneficial.
>>
>> This is not how TLS works, the client sends a list of
>> cipher-suites, and the server chooses exactly one of these.
>> Depending on server configuration, this is either the client's most
>> preferred cipher also supported by the server or else the server's
>> most preferred cipher supported by the client.
>>
>> Grossly misconfigured clients or servers might choose weak
>> cipher-suites, but I've never seen this happen in practice.
>>
>> If you disable EXPORT and LOW, the rest are substantially better
>> than cleartext even with the recent statistical anomalies in the
>> first 256 bytes of RC4 output.  Forcing the client to use
>> cleartext is not a better option.  However, one might want to use
>> the server's cipher preferences on the submission port:
>>
>> submission inet ... smtpd -o tls_preempt_cipherlist=yes ...
>>
>> where it is unlikely to run into friction with remote Exchange
>> 2003 servers (unless you're hosting remote Exchange MTAs as
>> submission clients).
>


Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

DTNX Postmaster
In reply to this post by Viktor Dukhovni
On 20 May 2014, at 15:25, Viktor Dukhovni <[hidden email]> wrote:

> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>
>> I've heard anecdotes of clients not using the best mutually supported
>> encryption and instead just using whatever's first in the list of methods
>> accepted by the server. I don't have anything to back this up though. Ever
>> heard of this? If this was true, then disabling weak methods might be
>> beneficial.
>
> This is not how TLS works, the client sends a list of cipher-suites,
> and the server chooses exactly one of these.  Depending on server
> configuration, this is either the client's most preferred cipher
> also supported by the server or else the server's most preferred
> cipher supported by the client.
>
> Grossly misconfigured clients or servers might choose weak
> cipher-suites, but I've never seen this happen in practice.

In our experience, the reverse is actually true; over time, we are
seeing a slow but steady upgrade in the TLS version and ciphers used in
both incoming and outgoing connections. SSLv3 connections are now in
the single digits for us, and TLSv1.2 has gained a lot of ground over
the past six months or so.

If you want to monitor this, you can set 'smtp_tls_loglevel' and
'smtpd_tls_loglevel' to 1, and then check your logs for the relevant
entries.

Outgoing (client) grep pattern;

'postfix/smtp\[.* connection established to .* with cipher'

Incoming (server) grep pattern;

'postfix/smtpd\[.* connection established from .* with cipher'

Then pipe it through the following to get a reverse sorted list, most
used at the top;

sed 's/^.* connection established from .*\]: //' | sort \
        | uniq -c | sort -r -n

We run this daily, on the logs from the day before. It keeps my need to
'optimize' the default settings in check ;-)

This is for our relay servers, by the way. Our mailbox servers, that
also do submission, use stricter settings, no longer accept SSLv3 or
medium ciphers etc.

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Per Thorsheim
In reply to this post by Viktor Dukhovni
"Useless" and "Clueless" is rather harsh Viktor, and you most certainly
don't us what we're trying to accomplish.

Fact is we've achieved quite a lot by launching this service, several
ISPs have implemented STARTTLS, same goes for large companies and
government organisations after launch and media coverage of them not
having STARTTLS at all. Several others have added certs from CA's,
renewed expired certs, renewed certs because of Heartbleed (...) and
more. While I cannot prove they did these things because of this useless
and clueless service, sometimes I like to believe for myself that it
just might made a positive difference to some. It will continue to
operate, and I hope we'll be able to expand it to do additional checks
of configurations such as those proposed by you.

Best regards,
Per Thorsheim



Den 20.05.2014 15:56, skrev Viktor Dukhovni:

> On Tue, May 20, 2014 at 02:35:04PM +0100, Colin Fowler wrote:
>
>> BTW, this whole thing came about from me testing using
>> https://starttls.info/ which scored what I thought was a well secured server
>> quite badly. I see now that the testing site is itself the problem, not my
>> original config.
> Yep, the site is clueless.  My DNSSEC + DANE validated domain scores a "D":
>
>     mx1.dukhovni.org: Grade: D (43.5%)
>
>     Certificate:
>
>       * The certificate is not valid for the server's hostname.
>       * There is a self-signed certificate in the trust chain. It may be a
>         configuration problem.
>       * There are one or more fatal problems which causes the
> certificate not to be trusted.
>
>     There are validity issues for the certificate. Certificates
>     are seldom verified for SMTP servers, so this doesn't mean that
>     STARTTLS won't be used.
>
> [ Actually, I have one of the few SMTP domains whose certificate can be
>   used for MiTM-resistant authentication. ]
>
>     Generally speaking it's a bad practice not to have a valid
>     certificate, and an even worse practice not to verify them.
>     Any attempted encrypted communication is left all but wide open
>     to Man-in-the-Middle attacks.
>
> [ Except that not authenticating certificates is exactly what one
>   needs to do with SMTP. ]
>
>     Protocol:
>
>       * Supports SSLV3.
>       * Supports TLSV1.
>       * Supports TLSV1.1.
>
>     Key exchange:
>
>       * Anonymous Diffie-Hellman is accepted. This is suspectible to
> Man-in-the-Middle attacks.
>
> [ But DANE clients won't offer this.  And server support of aNULL ciphers
>   is always harmless, and makes it easier to determine which clients are
>   not authenticating the server.  Pretending client offers of aNULL ciphers
>   did not happen does not improve security. ]
>
>
>       * Key size is 1024 bits; that's somewhat insecure.
>
> [ Fine, will be changed when the server is upgraded... ]
>
>     Cipher:
>
>       * Weakest accepted cipher: 0.
>       * Strongest accepted cipher: 256.
>
> [ Scoring aNULL as "0" is simply wrong. ]
>
>
> This site is useless.
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
In reply to this post by Per Thorsheim
On Tue, May 20, 2014 at 03:58:22PM +0200, Per Thorsheim wrote:

> I still personally vote for disabling SSLv2

Which is the default in Postfix.

> and ANON ciphers used with STARTTLS as we do today. My reasoning is simple:

And simply wrong:

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-8.2

> if we continue to support old & insecure ciphers etc, there is less
> incentive for moving forward to safer solutions.

Except that ANON ciphers are *not* insecure in the SMTP opportunistic
TLS threat model.  Postfix SMTP *clients* turn off ANON ciphers when
connecting to servers with a TLS policy that requires authentication
("dane" with TLSA records present or "fingerprint", "secure", ...).

> We did discuss and
> change the scoring soon after the service launched, while originally
> being based on the scoring system from Ivan Ristic @ Qualys at
> ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
> creating our own scoring system.

Opportunistic TLS in SMTP is nothing like mandatory TLS in HTTPS.
Yes, it uses the same protocol engine, but the threat model is
completely different.  The sooner people stop carrying over flawed
reasoning from HTTPS to SMTP+STARTTLS the better.

Please change your site to reflect the correct risk model (opportunistic
TLS).  You should also add support for DANE, so that DANE-capable
MTAs are not mis-identified as insecure (for example DANE-EE(3)
certificate usage obviates the need for the hostname to match).


> On May 13 Facebook published "The Current State of SMTP STARTTLS Deployment"
> https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223

Facebook made the same mistakes you did:

    http://www.metzdowd.com/pipermail/cryptography/2014-May/021344.html

> Facebook are concerned over the lack of PFS. Right. Well, we started out
> by saying we were concerned over SSLv2, ANON suites and expired
> certificates.

PFS is always on for the anonymous ciphers, there are no long-term
secrets to compromise.  I too encourage PFS, and wrote the initial
draft of:

    http://www.postfix.org/FORWARD_SECRECY_README.html

which Wietse helpfully whipped into shape.

> One of our goals with starttls.info was to aid in the global deployment
> of STARTTLS, another goal was to improve the minimum level used by
> anyone deploying STARTTLS. That is until Viktors IETF proposal, or
> anything similar, reaches broad adoption on the Internet.

I'm all for metrics, but misleading metrics can be worse than no
metrics.  Don't misdirect users to waste time solving non-problems.

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

Re: Disabling Anonymous Diffie Hellman

Viktor Dukhovni
On Tue, May 20, 2014 at 02:21:22PM +0000, Viktor Dukhovni wrote:

> Please change your site to reflect the correct risk model (opportunistic
> TLS).  You should also add support for DANE, so that DANE-capable
> MTAs are not mis-identified as insecure (for example DANE-EE(3)
> certificate usage obviates the need for the hostname to match).

I can help you with the DANE implementation if you are interested.
[ I provided the DANE verification library for the NIST site that
does DANE verification of HTTPS sites. ]

Please do not assign negative scores to server support for ADH and
AECDH ciphersuites, even HTTPS servers should support these (to
discover clients that do, and perhaps offer them reduced access to
sensitive content).  It is a common mistake to equate aNULL use in
servers with aNULL use in clients.  As you might have discerned,
I am not a fan of sloppy analysis by "analogy", and not shy about
refuting it.

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

Re: Disabling Anonymous Diffie Hellman

Alexander Hoogerhuis
In reply to this post by Viktor Dukhovni
On 20.05.2014 16:21, Viktor Dukhovni wrote:

>> We did discuss and
>> change the scoring soon after the service launched, while originally
>> being based on the scoring system from Ivan Ristic @ Qualys at
>> ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
>> creating our own scoring system.
>
> Opportunistic TLS in SMTP is nothing like mandatory TLS in HTTPS.
> Yes, it uses the same protocol engine, but the threat model is
> completely different.  The sooner people stop carrying over flawed
> reasoning from HTTPS to SMTP+STARTTLS the better.
>
> Please change your site to reflect the correct risk model (opportunistic
> TLS).  You should also add support for DANE, so that DANE-capable
> MTAs are not mis-identified as insecure (for example DANE-EE(3)
> certificate usage obviates the need for the hostname to match).
>

I second this. I have been using the site since it became public and
have discussed the same with the designers ad nauseum, and there seems
to be little interest in wanting to understand that TLS in context of
HTTP and SMTP are two very different worlds in terms of starting
problems and possible archievements.

I run what I consider to be fairly well configured MXes for customers,
and this site generally tends to cap my score at 68% given the support
for weaker protocols.

Not only is it misleading for people trying to configure their own
servers, but it has drawn attention from customers which not always have
the understanding of why this site hands out these scores it does.

So basically, untill the site can relfect the real world, it seem to be
of limited use.

mvh,
A
--
Alexander Hoogerhuis | http://no.linkedin.com/in/alexh
Boxed Solutions AS   | +47 908 21 485 - [hidden email]
"Given enough eyeballs, all bugs are shallow." -Eric S. Raymond
12