recommend TLS settings

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

recommend TLS settings

Maarten
Hello,

I setup my postfix mailserver a while ago with tls settings from:

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

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

I don't know much about TLS settings so I used the settings which seemed
be important in the documentation.

When scanning my server with: https://www.hardenize.com I got some
results that need improvement:

- Server doesn't enforce cipher suite preferences: Servers that don't
enforce cipher suite preferences select the first cipher suite they
support from the list provided by clients. This approach doesn't
guarantee that best-possible cipher suite is negotiated.

-  Weak key exchange detected: his server uses key exchange parameters
that are weak. When using the ephemeral Diffie-Hellman key exchange
(DHE), parameters below 2048 bits are considered insecure. For
sufficient security, use 2048-bit parameters. It is generally not
advisable to use stronger key exchange because there is a measurable
performance penalty and there is no meaningful increase in security. A
well-configured TLS server should generally prefer the faster ECDHE key
exchange anyway.

- Reconfigure server to use forward secrecy and authenticated
encryption: Even though this server supports TLS 1.2, the cipher suite
configuration is suboptimal. We recommend that you reconfigure the
server so that the cipher suites providing forward secrecy (ECDHE or DHE
in the name, in this order of preference) and authenticated encryption
(GCM or CHACHA20 in the name) are at the top. The server must also be
configured to select the best-available suite.

So I was wondering what are the recommended TLS settings for a postfix
mailserver now days? And what settings do I need to improve these points
pointed out by this scan?


Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Viktor Dukhovni


> On Dec 2, 2017, at 12:08 PM, Maarten <[hidden email]> wrote:
>
> I setup my postfix mailserver a while ago with tls settings from:
>
> http://www.postfix.org/TLS_README.html
>
> http://www.postfix.org/FORWARD_SECRECY_README.html
>
> I don't know much about TLS settings so I used the settings which seemed be important in the documentation.
>
> When scanning my server with: https://www.hardenize.com 

Such caution is appropriate, some similar scanners are created by crypto
zealots who don't understand opportunistic TLS, and give frankly useless
or stupid recommendations.  See:

    https://tools.ietf.org/html/rfc7435

for a more pragmatic and generally more effective mindset.

> I got some results that need improvement:
>
> - Server doesn't enforce cipher suite preferences: Servers that don't enforce cipher suite preferences select the first cipher suite they support from the list provided by clients. This approach doesn't guarantee that best-possible cipher suite is negotiated.

This makes little difference.  And who's to say the server knows better than the
client.  Both are MTAs.

> -  Weak key exchange detected: his server uses key exchange parameters that are
> weak.  When using the ephemeral Diffie-Hellman key exchange (DHE), parameters
> below 2048 bits are considered insecure. For sufficient security, use 2048-bit
> parameters. It is generally not advisable to use stronger key exchange because
> there is a measurable performance penalty and there is no meaningful increase
> in security. A well-configured TLS server should generally prefer the faster
> ECDHE key exchange anyway.

The FORWARD_SECRECY_README tutorial also recommends 2048-bit DHE parameters.
See there for details.


> - Reconfigure server to use forward secrecy and authenticated encryption:

This is wrong, what this site calls "authenticated encryption" (actually
AEAD) is actually rather more fragile than CBC with HMAC, relying on
non-reuse of "nonces" that can be difficult to achieve.  The various
attacks on CBC are browser-specific and have been addressed via the
"encrypt-then-mac" extension in modern TLS 1.2 stacks.  If both sides
support TLS 1.2 with encrypt-then-mac, you're likely safer than with
the more fashionable AEAD.

> Even though this server supports TLS 1.2, the cipher suite configuration is
> suboptimal. We recommend that you reconfigure the server so that the cipher
> suites providing forward secrecy (ECDHE or DHE in the name, in this order of
> preference) and authenticated encryption (GCM or CHACHA20 in the name) are
> at the top. The server must also be configured to select the best-available
> suite.

The Postfix cipher order is just fine.

> So I was wondering what are the recommended TLS settings for a postfix mailserver
> now days? And what settings do I need to improve these points pointed out by this
> scan?

Use the Postfix defaults, but configure 2048-bit DHE if your Postfix is older
than 3.1.  Starting with 3.1 the default built-in DHE parameters use a 2048-bit
prime.  You can of course still generate your own, for a bit of extra diversity
even with Postfix >= 3.1.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Maarten
Hello Viktor,

Thanks for your feedback and for the link ! Will configure 2048-bit DHE
since I'm using a version older than 3.1.

Maarten



On 2017-12-02 20:13, Viktor Dukhovni wrote:

>> On Dec 2, 2017, at 12:08 PM, Maarten <[hidden email]>
>> wrote:
>>
>> I setup my postfix mailserver a while ago with tls settings from:
>>
>> http://www.postfix.org/TLS_README.html
>>
>> http://www.postfix.org/FORWARD_SECRECY_README.html
>>
>> I don't know much about TLS settings so I used the settings which
>> seemed be important in the documentation.
>>
>> When scanning my server with: https://www.hardenize.com
>
> Such caution is appropriate, some similar scanners are created by
> crypto
> zealots who don't understand opportunistic TLS, and give frankly
> useless
> or stupid recommendations.  See:
>
>     https://tools.ietf.org/html/rfc7435
>
> for a more pragmatic and generally more effective mindset.
>
>> I got some results that need improvement:
>>
>> - Server doesn't enforce cipher suite preferences: Servers that don't
>> enforce cipher suite preferences select the first cipher suite they
>> support from the list provided by clients. This approach doesn't
>> guarantee that best-possible cipher suite is negotiated.
>
> This makes little difference.  And who's to say the server knows better
> than the
> client.  Both are MTAs.
>
>> -  Weak key exchange detected: his server uses key exchange parameters
>> that are
>> weak.  When using the ephemeral Diffie-Hellman key exchange (DHE),
>> parameters
>> below 2048 bits are considered insecure. For sufficient security, use
>> 2048-bit
>> parameters. It is generally not advisable to use stronger key exchange
>> because
>> there is a measurable performance penalty and there is no meaningful
>> increase
>> in security. A well-configured TLS server should generally prefer the
>> faster
>> ECDHE key exchange anyway.
>
> The FORWARD_SECRECY_README tutorial also recommends 2048-bit DHE
> parameters.
> See there for details.
>
>
>> - Reconfigure server to use forward secrecy and authenticated
>> encryption:
>
> This is wrong, what this site calls "authenticated encryption"
> (actually
> AEAD) is actually rather more fragile than CBC with HMAC, relying on
> non-reuse of "nonces" that can be difficult to achieve.  The various
> attacks on CBC are browser-specific and have been addressed via the
> "encrypt-then-mac" extension in modern TLS 1.2 stacks.  If both sides
> support TLS 1.2 with encrypt-then-mac, you're likely safer than with
> the more fashionable AEAD.
>
>> Even though this server supports TLS 1.2, the cipher suite
>> configuration is
>> suboptimal. We recommend that you reconfigure the server so that the
>> cipher
>> suites providing forward secrecy (ECDHE or DHE in the name, in this
>> order of
>> preference) and authenticated encryption (GCM or CHACHA20 in the name)
>> are
>> at the top. The server must also be configured to select the
>> best-available
>> suite.
>
> The Postfix cipher order is just fine.
>
>> So I was wondering what are the recommended TLS settings for a postfix
>> mailserver
>> now days? And what settings do I need to improve these points pointed
>> out by this
>> scan?
>
> Use the Postfix defaults, but configure 2048-bit DHE if your Postfix is
> older
> than 3.1.  Starting with 3.1 the default built-in DHE parameters use a
> 2048-bit
> prime.  You can of course still generate your own, for a bit of extra
> diversity
> even with Postfix >= 3.1.
Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Jonathan Sélea
Hi,

I recently stumbled upon hardinze too, and came up with this config that
makes the checks "all green".

smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_protocols = !SSLv2 !SSLv3
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
lmtp_tls_protocols = !SSLv2 !SSLv3
lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA,
CAMELLIA, SEED, 3DES, AES128-GCM-SHA256, AES256-GCM-SHA384,
AES128-SHA256, AES256-SHA256, AES256-SHA, AES128-SHA
smtpd_tls_eecdh_grade=ultra
tls_preempt_cipherlist = yes
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
smtpd_tls_dh512_param_file = /etc/ssl/dh512_param.pem
smtpd_tls_dh1024_param_file = /etc/ssl/dh2048_param.pem
tls_random_source = dev:/dev/urandom

If anyone has some oppinion about this, feel free to criticize me :)

/ J

On 12/04/2017 08:37 AM, Maarten wrote:

> Hello Viktor,
>
> Thanks for your feedback and for the link ! Will configure 2048-bit
> DHE since I'm using a version older than 3.1.
>
> Maarten
>
>
>
> On 2017-12-02 20:13, Viktor Dukhovni wrote:
>>> On Dec 2, 2017, at 12:08 PM, Maarten <[hidden email]>
>>> wrote:
>>>
>>> I setup my postfix mailserver a while ago with tls settings from:
>>>
>>> http://www.postfix.org/TLS_README.html
>>>
>>> http://www.postfix.org/FORWARD_SECRECY_README.html
>>>
>>> I don't know much about TLS settings so I used the settings which
>>> seemed be important in the documentation.
>>>
>>> When scanning my server with: https://www.hardenize.com
>>
>> Such caution is appropriate, some similar scanners are created by crypto
>> zealots who don't understand opportunistic TLS, and give frankly useless
>> or stupid recommendations.  See:
>>
>>     https://tools.ietf.org/html/rfc7435
>>
>> for a more pragmatic and generally more effective mindset.
>>
>>> I got some results that need improvement:
>>>
>>> - Server doesn't enforce cipher suite preferences: Servers that
>>> don't enforce cipher suite preferences select the first cipher suite
>>> they support from the list provided by clients. This approach
>>> doesn't guarantee that best-possible cipher suite is negotiated.
>>
>> This makes little difference.  And who's to say the server knows
>> better than the
>> client.  Both are MTAs.
>>
>>> -  Weak key exchange detected: his server uses key exchange
>>> parameters that are
>>> weak.  When using the ephemeral Diffie-Hellman key exchange (DHE),
>>> parameters
>>> below 2048 bits are considered insecure. For sufficient security,
>>> use 2048-bit
>>> parameters. It is generally not advisable to use stronger key
>>> exchange because
>>> there is a measurable performance penalty and there is no meaningful
>>> increase
>>> in security. A well-configured TLS server should generally prefer
>>> the faster
>>> ECDHE key exchange anyway.
>>
>> The FORWARD_SECRECY_README tutorial also recommends 2048-bit DHE
>> parameters.
>> See there for details.
>>
>>
>>> - Reconfigure server to use forward secrecy and authenticated
>>> encryption:
>>
>> This is wrong, what this site calls "authenticated encryption" (actually
>> AEAD) is actually rather more fragile than CBC with HMAC, relying on
>> non-reuse of "nonces" that can be difficult to achieve.  The various
>> attacks on CBC are browser-specific and have been addressed via the
>> "encrypt-then-mac" extension in modern TLS 1.2 stacks.  If both sides
>> support TLS 1.2 with encrypt-then-mac, you're likely safer than with
>> the more fashionable AEAD.
>>
>>> Even though this server supports TLS 1.2, the cipher suite
>>> configuration is
>>> suboptimal. We recommend that you reconfigure the server so that the
>>> cipher
>>> suites providing forward secrecy (ECDHE or DHE in the name, in this
>>> order of
>>> preference) and authenticated encryption (GCM or CHACHA20 in the
>>> name) are
>>> at the top. The server must also be configured to select the
>>> best-available
>>> suite.
>>
>> The Postfix cipher order is just fine.
>>
>>> So I was wondering what are the recommended TLS settings for a
>>> postfix mailserver
>>> now days? And what settings do I need to improve these points
>>> pointed out by this
>>> scan?
>>
>> Use the Postfix defaults, but configure 2048-bit DHE if your Postfix
>> is older
>> than 3.1.  Starting with 3.1 the default built-in DHE parameters use
>> a 2048-bit
>> prime.  You can of course still generate your own, for a bit of extra
>> diversity
>> even with Postfix >= 3.1.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Viktor Dukhovni


> On Dec 4, 2017, at 8:22 AM, Jonathan Sélea <[hidden email]> wrote:
>
> I recently stumbled upon hardinze too, and came up with this config that makes the checks "all green".

Green per some poorly designed checklist is not necessarily better.

> smtpd_tls_protocols = !SSLv2 !SSLv3
> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
> smtp_tls_protocols = !SSLv2 !SSLv3
> smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
> lmtp_tls_protocols = !SSLv2 !SSLv3
> lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3

These are fine and default in all supported Postfix versions.

> smtpd_tls_mandatory_ciphers=high

This may be counter-productive.  You're forcing peers that
only do RC4 to send in the clear instead.  Probably not a
win, and with peers that can do HIGH ciphers, you get HIGH
anyway.  On the other hand support for only RC4 or 3DES
(now medium in some newer OpenSSL versions) is rare, most
peers will support AES, and yet "medium" is still a better
choice for opportunistic TLS.

> tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Don't hand-order your ciphers.  Why CAMELLIA above AES for example?
And what happens when newer ciphers show up?

> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA, CAMELLIA, SEED, 3DES, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128-SHA256, AES256-SHA256, AES256-SHA, AES128-SHA

Excluding aNULL on a port 25 server is mostly counter-productive:

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

ditto with DES3 and RC4, just put them at the end.  Funny you put
CAMELLIA first on your cipher list, and then exclude it!  And
then exclude a bunch of strong AES ciphers.  This clearly makes the
point that such guides and efforts to get to "green" are a bad idea.

> smtpd_tls_eecdh_grade=ultra

Actually "auto" is a much better setting in Postfix versions that
support it.

> tls_preempt_cipherlist = yes

This is typically OK, though in your case, the client's settings
might be more sensible. :-(

> tls_eecdh_strong_curve = prime256v1
> tls_eecdh_ultra_curve = secp384r1

These are defaults.

> smtpd_tls_dh512_param_file = /etc/ssl/dh512_param.pem
> smtpd_tls_dh1024_param_file = /etc/ssl/dh2048_param.pem

This is fine, provided the names match the content.  Note that
with EXPORT ciphers disabled the 512-bit parameters will never
be used.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Bastian Blank-3
On Mon, Dec 04, 2017 at 09:24:48AM -0500, Viktor Dukhovni wrote:
> > smtpd_tls_mandatory_ciphers=high
> This may be counter-productive.  You're forcing peers that
> only do RC4 to send in the clear instead.  Probably not a
> win, and with peers that can do HIGH ciphers, you get HIGH
> anyway.  On the other hand support for only RC4 or 3DES
> (now medium in some newer OpenSSL versions) is rare, most
> peers will support AES, and yet "medium" is still a better
> choice for opportunistic TLS.

How would the peer send anything unencrypted if the policy defines that
TLS is mandatory?  And for smtpd you can not have mandatory TLS for port
25 anyway.

Bastian

--
A princess should not be afraid -- not with a brave knight to protect her.
                -- McCoy, "Shore Leave", stardate 3025.3
Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Viktor Dukhovni


> On Dec 4, 2017, at 9:46 AM, Bastian Blank <bastian+postfix-users=[hidden email]> wrote:
>
>>> smtpd_tls_mandatory_ciphers=high
>> This may be counter-productive.  You're forcing peers that
>> only do RC4 to send in the clear instead.  Probably not a
>> win, and with peers that can do HIGH ciphers, you get HIGH
>> anyway.  On the other hand support for only RC4 or 3DES
>> (now medium in some newer OpenSSL versions) is rare, most
>> peers will support AES, and yet "medium" is still a better
>> choice for opportunistic TLS.
>
> How would the peer send anything unencrypted if the policy defines that
> TLS is mandatory?

Sorry, it is fine to set "smtpd_tls_mandatory_ciphers=high", that's
intended for port 587 where one would also set (in master.cf):

        smtpd_tls_security_level=encrypt

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: recommend TLS settings

Jonathan Sélea
In reply to this post by Viktor Dukhovni
Thanks for very good information and some good criticism!
I have taken those into consideration and adjusted it accordingly.

Regarding "smtpd_tls_mandatory_ciphers=high", I use port 587 alot. I
dont know if that makes any diffrence.

Otherwhise, I do agree with you that tools like "hardenize" is made by
"encryption zealots" (I like that name btw) that "does not understand
who don't understand opportunistic TLS".

Thanks again Viktor



On 12/04/2017 03:24 PM, Viktor Dukhovni wrote:

>
>> On Dec 4, 2017, at 8:22 AM, Jonathan Sélea <[hidden email]> wrote:
>>
>> I recently stumbled upon hardinze too, and came up with this config that makes the checks "all green".
> Green per some poorly designed checklist is not necessarily better.
>
>> smtpd_tls_protocols = !SSLv2 !SSLv3
>> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
>> smtp_tls_protocols = !SSLv2 !SSLv3
>> smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
>> lmtp_tls_protocols = !SSLv2 !SSLv3
>> lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3
> These are fine and default in all supported Postfix versions.
>
>> smtpd_tls_mandatory_ciphers=high
> This may be counter-productive.  You're forcing peers that
> only do RC4 to send in the clear instead.  Probably not a
> win, and with peers that can do HIGH ciphers, you get HIGH
> anyway.  On the other hand support for only RC4 or 3DES
> (now medium in some newer OpenSSL versions) is rare, most
> peers will support AES, and yet "medium" is still a better
> choice for opportunistic TLS.
>
>> tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
> Don't hand-order your ciphers.  Why CAMELLIA above AES for example?
> And what happens when newer ciphers show up?
>
>> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA, CAMELLIA, SEED, 3DES, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128-SHA256, AES256-SHA256, AES256-SHA, AES128-SHA
> Excluding aNULL on a port 25 server is mostly counter-productive:
>
>     https://tools.ietf.org/html/rfc7672#section-8.2
>
> ditto with DES3 and RC4, just put them at the end.  Funny you put
> CAMELLIA first on your cipher list, and then exclude it!  And
> then exclude a bunch of strong AES ciphers.  This clearly makes the
> point that such guides and efforts to get to "green" are a bad idea.
>
>> smtpd_tls_eecdh_grade=ultra
> Actually "auto" is a much better setting in Postfix versions that
> support it.
>
>> tls_preempt_cipherlist = yes
> This is typically OK, though in your case, the client's settings
> might be more sensible. :-(
>
>> tls_eecdh_strong_curve = prime256v1
>> tls_eecdh_ultra_curve = secp384r1
> These are defaults.
>
>> smtpd_tls_dh512_param_file = /etc/ssl/dh512_param.pem
>> smtpd_tls_dh1024_param_file = /etc/ssl/dh2048_param.pem
> This is fine, provided the names match the content.  Note that
> with EXPORT ciphers disabled the 512-bit parameters will never
> be used.
>


smime.p7s (5K) Download Attachment