smtp client cipher selection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp client cipher selection

İhsan Doğan
Hi,

For me, it's not 100% clear, how the Postfix smtp client chooses the TLS
cipher. In a setup, where a Postfix server connects to mail.dogan.ch,
I've experienced this behaviour:

1. smtp_tls_security_level = verify

Feb 24 18:51:28 bender postfix/smtp[26237]: [ID 197553 mail.info]
Verified TLS connection established to mail.dogan.ch[77.109.151.89]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

2. smtp_tls_security_level = may

Feb 24 19:16:51 bender postfix/smtp[26830]: [ID 197553 mail.info]
Untrusted TLS connection established to mail.dogan.ch[77.109.151.89]:25:
TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

smtp_tls_CAfile: In both cases the CA file is loaded.

I guess the Postfix smtp client chooses the cipher
ECDHE-RSA-AES256-GCM-SHA384 only when smtp_tls_security_level is set to
verify, because the TLS connection is untrusted.

What makes me wonder is, why the TLS connection is trusted, if
smtp_tls_security_level is set to verify, but it's untrusted if
smtp_tls_security_level is set to may. What is the logic behind?



Ihsan


--
[hidden email]        http://blog.dogan.ch/
Reply | Threaded
Open this post in threaded view
|

Re: smtp client cipher selection

Viktor Dukhovni
On Tue, Feb 24, 2015 at 07:35:18PM +0100, ?hsan?Do?an wrote:

> For me, it's not 100% clear, how the Postfix smtp client chooses the TLS
> cipher. In a setup, where a Postfix server connects to mail.dogan.ch,
> I've experienced this behaviour:
>
> 1. smtp_tls_security_level = verify
>
> Feb 24 18:51:28 bender postfix/smtp[26237]: [ID 197553 mail.info]
> Verified TLS connection established to mail.dogan.ch[77.109.151.89]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

[ Note "verify" is not recommended, use "secure" instead. However,
  these coincide when the [nexthop] is not subject to MX lookups. ]

This ciphersuite involves use of an RSA key to sign the server's
ephemeral ECDH key agreement parameters, thereby authenticating the
server to the client.

> 2. smtp_tls_security_level = may
>
> Feb 24 19:16:51 bender postfix/smtp[26830]: [ID 197553 mail.info]
> Untrusted TLS connection established to mail.dogan.ch[77.109.151.89]:25:
> TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

[ Note, sufficiently recent Postfix versions correctly report this
  as "Anonymous" rather than "Untrusted". ]

Here, since no authentication is performed, an anonymous ciphersuite
is used, saving the server pointless cycles signing the ECDH
parameters.

> I guess the Postfix smtp client chooses the cipher
> ECDHE-RSA-AES256-GCM-SHA384 only when smtp_tls_security_level is set to
> verify, because the TLS connection is untrusted.

No, with "verify" the client removes anon-(EC)DH ciphers from its
cipherlist, because these would prevent the desired server
authentication.

> What makes me wonder is, why the TLS connection is trusted, if
> smtp_tls_security_level is set to verify, but it's untrusted if
> smtp_tls_security_level is set to may. What is the logic behind?

    http://www.postfix.org/TLS_README.html#client_tls_limits
    http://www.postfix.org/TLS_README.html#client_tls_levels
    http://www.postfix.org/TLS_README.html#client_tls_secure
    http://www.postfix.org/TLS_README.html#client_tls_may

With "may" there is no protection against active attacks, so no
CPU cycles are wasted going through the motions of certificate
checks whose results are ignored.

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

Re: smtp client cipher selection

Wietse Venema
Viktor Dukhovni:
> With "may" there is no protection against active attacks, so no
> CPU cycles are wasted going through the motions of certificate
> checks whose results are ignored.

We may want to provide an option to make the motions anyway. Even
if the outcome has no direct effect on whether mail will be delivered,
it can be useful for change-detection purposes.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: smtp client cipher selection

Viktor Dukhovni
On Tue, Feb 24, 2015 at 02:06:43PM -0500, Wietse Venema wrote:

> Viktor Dukhovni:
> > With "may" there is no protection against active attacks, so no
> > CPU cycles are wasted going through the motions of certificate
> > checks whose results are ignored.
>
> We may want to provide an option to make the motions anyway. Even
> if the outcome has no direct effect on whether mail will be delivered,
> it can be useful for change-detection purposes.

Yes, that's on the agenda for 3.1.  Perhaps we'll get started on
that with the Spring thaw (whenever that might be).

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

Re: smtp client cipher selection

İhsan Doğan
In reply to this post by Viktor Dukhovni
Hi Viktor,

Thanks for the quick reply.

Am 24.02.2015 um 19:48 schrieb Viktor Dukhovni:

>> For me, it's not 100% clear, how the Postfix smtp client chooses the TLS
>> cipher. In a setup, where a Postfix server connects to mail.dogan.ch,
>> I've experienced this behaviour:
>>
>> 1. smtp_tls_security_level = verify
>>
>> Feb 24 18:51:28 bender postfix/smtp[26237]: [ID 197553 mail.info]
>> Verified TLS connection established to mail.dogan.ch[77.109.151.89]:25:
>> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
> [ Note "verify" is not recommended, use "secure" instead. However,
>   these coincide when the [nexthop] is not subject to MX lookups. ]
>
> This ciphersuite involves use of an RSA key to sign the server's
> ephemeral ECDH key agreement parameters, thereby authenticating the
> server to the client.
>
>> 2. smtp_tls_security_level = may
>>
>> Feb 24 19:16:51 bender postfix/smtp[26830]: [ID 197553 mail.info]
>> Untrusted TLS connection established to mail.dogan.ch[77.109.151.89]:25:
>> TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
>
> [ Note, sufficiently recent Postfix versions correctly report this
>   as "Anonymous" rather than "Untrusted". ]
>
> Here, since no authentication is performed, an anonymous ciphersuite
> is used, saving the server pointless cycles signing the ECDH
> parameters.

It's still not clear to me, why in this case there was no authentication
performed. With the same configuration, an SMTP connection Gmail is
authenticated:

Feb 24 20:09:36 bender postfix/smtp[27726]: [ID 197553 mail.info]
Trusted TLS connection established to
gmail-smtp-in.l.google.com[74.125.136.26]:25: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

For me still the question remains, why one connection is authenticated
and one not. Is there any criteria that needs to be met?


Ihsan

--
[hidden email]        http://blog.dogan.ch/
Reply | Threaded
Open this post in threaded view
|

Re: smtp client cipher selection

Viktor Dukhovni
On Tue, Feb 24, 2015 at 08:16:32PM +0100, ?hsan?Do?an wrote:

> >> 2. smtp_tls_security_level = may
> >>
> >> Feb 24 19:16:51 bender postfix/smtp[26830]: [ID 197553 mail.info]
> >> Untrusted TLS connection established to mail.dogan.ch[77.109.151.89]:25:
> >> TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

This is likely a Postfix server that supports anon-DH ciphersuites.

> It's still not clear to me, why in this case there was no authentication
> performed. With the same configuration, an SMTP connection Gmail is
> authenticated:
>
> Feb 24 20:09:36 bender postfix/smtp[27726]: [ID 197553 mail.info]
> Trusted TLS connection established to
> gmail-smtp-in.l.google.com[74.125.136.26]:25: TLSv1.2 with cipher
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
>
> For me still the question remains, why one connection is authenticated
> and one not. Is there any criteria that needs to be met?

This is a Google server that does not support anon-DH ciphersuites.

It is *not* authenticated.  It has a certificate from *some* trusted
CA, binding the public key to *some* name, not necessarily related
to the intended destination.  If it were authenticated the connection
would be "Verified" not "Trusted".

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

Re: smtp client cipher selection

İhsan Doğan
Hi Viktor,

Am 24.02.2015 um 20:57 schrieb Viktor Dukhovni:

>> It's still not clear to me, why in this case there was no authentication
>> performed. With the same configuration, an SMTP connection Gmail is
>> authenticated:
>>
>> Feb 24 20:09:36 bender postfix/smtp[27726]: [ID 197553 mail.info]
>> Trusted TLS connection established to
>> gmail-smtp-in.l.google.com[74.125.136.26]:25: TLSv1.2 with cipher
>> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
>>
>> For me still the question remains, why one connection is authenticated
>> and one not. Is there any criteria that needs to be met?
>
> This is a Google server that does not support anon-DH ciphersuites.
>
> It is *not* authenticated.  It has a certificate from *some* trusted
> CA, binding the public key to *some* name, not necessarily related
> to the intended destination.  If it were authenticated the connection
> would be "Verified" not "Trusted".

I see. Thanks a lot for the explanation.



Ihsan

--
[hidden email]        http://blog.dogan.ch/