Re: recommend TLS settings
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 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 Description: S/MIME Cryptographic Signature
Re: recommend TLS settings
> On Dec 4, 2017, at 8:22 AM, Jonathan Sélea 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.
Re: recommend TLS settings
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
Re: recommend TLS settings
> On Dec 4, 2017, at 9:46 AM, Bastian Blank > 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.
Question regarding smtp_per_record_deadlne parameter
Hello, I currently have a server that is configured as a mail forwarding domain [1]. Using example.com as an example: /etc/postfix/main.cf virtual_alias_domains = example.com virtual_alias_maps = hash:/etc/postfix/virtual /etc/postfix/virtual u...@example.com users-gmail-addr...@gmail.com As such, the SMTP client is used to forward the messages to each user’s existing Gmail addresses. I was reading more about the smtp client parameters and read about smtp_per_record_deadline. In postconf(5) it states that the time limits are changed and that this “...limits the impact from hostile peers that trickle data one byte at a time” Since my peer for the smtp client is always Gmail, this isn’t an issue for me, but I was wondering - why does this default to “no” ? I note the warning in postconf(5) that states for slow network connections this can cause problems with TLS, but I am assuming that this doesn’t apply to most configurations. Why wouldn’t I want this normally enabled ? Thanks, - J Sources [1] www.postfix.org/VIRTUAL_README.html
Re: Question regarding smtp_per_record_deadlne parameter
On 12/4/2017 3:35 PM, J Doe wrote: > Hello, > > I currently have a server that is configured as a mail forwarding domain [1]. > Using example.com as an example: > > /etc/postfix/main.cf > virtual_alias_domains = example.com > virtual_alias_maps = hash:/etc/postfix/virtual > > /etc/postfix/virtual > u...@example.com users-gmail-addr...@gmail.com > > As such, the SMTP client is used to forward the messages to each user’s > existing Gmail addresses. > > I was reading more about the smtp client parameters and read about > smtp_per_record_deadline. In postconf(5) it states that the time limits are > changed and that this “...limits the impact from hostile peers that trickle > data one byte at a time” > > Since my peer for the smtp client is always Gmail, this isn’t an issue for > me, but I was wondering - why does this default to “no” ? I note the warning > in postconf(5) that states for slow network connections this can cause > problems with TLS, but I am assuming that this doesn’t apply to most > configurations. > > Why wouldn’t I want this normally enabled ? > > Thanks, > > - J > > Sources > [1] www.postfix.org/VIRTUAL_README.html > This messes with timeouts in a non-obvious manner, and can cause legit slow-but-working connections to fail, especially if they use TLS. Don't enable this unless you are actively experiencing a slow-connection denial of service, which are pretty rare. -- Noel Jones
Re: Question regarding smtp_per_record_deadlne parameter
Noel Jones: > On 12/4/2017 3:35 PM, J Doe wrote: > > Hello, > > > > I currently have a server that is configured as a mail forwarding domain > > [1]. Using example.com as an example: > > > > /etc/postfix/main.cf > > virtual_alias_domains = example.com > > virtual_alias_maps = hash:/etc/postfix/virtual > > > > /etc/postfix/virtual > > u...@example.com users-gmail-addr...@gmail.com > > > > As such, the SMTP client is used to forward the messages to each user?s > > existing Gmail addresses. > > > > I was reading more about the smtp client parameters and read about > > smtp_per_record_deadline. In postconf(5) it states that the time limits > > are changed and that this ?...limits the impact from hostile peers that > > trickle data one byte at a time? > > > > Since my peer for the smtp client is always Gmail, this isn?t an issue for > > me, but I was wondering - why does this default to ?no? ? I note the > > warning in postconf(5) that states for slow network connections this can > > cause problems with TLS, but I am assuming that this doesn?t apply to most > > configurations. > > > > Why wouldn?t I want this normally enabled ? It's not safe to make this the Postfix default, but you're welcome to override that if you are sure that connections will never be slow. Wietse
Re: Postfix TLS crash on MacOS 10.13 (High Sierra)
Hi, Thanks for the guidance Viktor. I wanted to share what worked for me. I was able to get Postfix compiling and working on High Sierra with the following command: make -f Makefile.init makefiles \ CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DDEF_COMMAND_DIR=\"/usr/local/sbin\" -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" -DUSE_TLS -DHAS_PCRE -I/usr/local/include -DHAS_SSL -I/usr/local/include/openssl -DHAS_MYSQL -I/usr/local/mysql/include' \ AUXLIBS='-L/usr/local/lib -lssl -lcrypto -L/usr/local/mysql/lib -lmysqlclient -lz -lm' \ AUXLIBS_PCRE='-L/usr/local/lib -lpcre’ This configuration includes PCRE, MySQL, and OpenSSL for SASL and TLS. I found that I had to be very careful with the line continuations. Either bash on High Sierra is very picky or my formatting was poor but I had to play with running the command until I was sure all of my options were being read correctly. Hopefully this helps someone else. I’d love to hear if someone figured out to get logging on MacOS back to normal. It’s something I might investigate further. On Nov 20, 2017, at 9:28 PM, Viktor Dukhovni wrote: > On Nov 20, 2017, at 10:46 PM, AnotherGuyFromAlberta > wrote: > > I recently upgraded a Mac server to 10.13 (High Sierra). This server > has been running for about 5 years and hosts Postfix. After upgrading the > OS I upgraded: > 1. dovecot to 2.2.33.2 > 2. openssl to 1.1.0g > 3. pcre to 8.41 > 4. postfix to 3.2.4 > > Everything appears to compile and work except TLS on Postfix. It crashes > with the same error > every few minutes. Here's a snippet of the crash: > > Assertion failed: (ctx->pctx == NULL || ctx->pctx_ops != NULL), function > EVP_MD_CTX_cleanup, file > /BuildRoot/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-109.20.5/crypto/digest/digest.c, > line 98. The "BoringSSL" library is derived from and conflicts with OpenSSL. With some care in the compiler options you may be able to build a version of Postfix that is using OpenSSL and not Boring SSL. I have (my own build of) OpenSSL 1.1.0 installed in /opt/openssl/1.1.0 and after configuration makedefs.out has: CCARGS=-I/opt/openssl/1.1.0/include -DUSE_TLS -DHAS_PCRE -DHAS_CDB -I/usr/local/include AUXLIBS=-L/opt/openssl/1.1.0/lib -lssl -lcrypto -L/usr/local/lib -ldb AUXLIBS_PCRE=-L/usr/local/lib -lpcre AUXLIBS_CDB=-L/usr/local/lib -lcdb shared=yes dynamicmaps=yes This appears to produce a working Postfix with TLS. $ otool -L .../libexec/smtpd .../libexec/smtpd: @rpath/libpostfix-master.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libpostfix-tls.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libpostfix-dns.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libpostfix-global.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libpostfix-util.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/openssl/1.1.0/lib/libssl-opt.1.1.dylib (compatibility version 1.1.0, current version 1.1.0) /opt/openssl/1.1.0/lib/libcrypto-opt.1.1.dylib (compatibility version 1.1.0, current version 1.1.0) /usr/local/opt/berkeley-db/lib/libdb-6.2.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/opt/icu4c/lib/libicui18n.59.dylib (compatibility version 59.0.0, current version 59.1.0) /usr/local/opt/icu4c/lib/libicuuc.59.dylib (compatibility version 59.0.0, current version 59.1.0) /usr/local/opt/icu4c/lib/libicudata.59.1.dylib (compatibility version 59.0.0, current version 59.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0) The "posttls-finger" command works, and connecting to a loopback server yields: $ posttls-finger -c -l may "[127.0.0.1]" posttls-finger: Anonymous TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) posttls-finger: Server is anonymous That said, it has become increasingly difficult to support Postfix on Apple's most recent operating systems. I think you should either run the Postfix supplied by Apple, or choose a different O/S (a BSD or Linux) for your mail server. -- Viktor.
Re: recommend TLS settings
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 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 Description: S/MIME Cryptographic Signature
