DevHeads.net

possible to reach hardenize's requirements?

The site <a href="https://hardenize.com" title="https://hardenize.com">https://hardenize.com</a> provides relatively decent Email reports,
along with other reports. It checks a number of things including certs,
MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all
good checks and recommendations, with the exception of the TLS one, I do
not see how its possible to meet their standards, and provide an email
server on the internet. However, I could be wrong, so I'm interested to
know if I am.

1. TLS versions: They don't like that TLS v1.1 and v1.0 are possible. If
you turn this off, then those clients that only support v1.2 will fall
back to clear-text, this is not optimal. I don't see a way around this
one.

2. Server suite preferences: they break down each preferred cipher
selection for each TLS verison, and are unhappy about the cipher suite
configuration being suboptimal, specifically that the forward secrecy
ciphers (ECDHE or DHE) and authenticated encryption (GCM or CHACHA20)
are not 'at the top' of the cipher preferences.

I know its possible to set `tls_preempt_cipher_list=yes` and risk
Windows 2003 Microsoft Exchange clients having an issue[0]. But, to get
the preferences to order the forward secrecy and auth encryption ciphers
first, I'd have to specify a custom cipherlist with
tls_medium_cipherlist, which would be ugly[0]. It is also unclear how
this would work with tls1.2, vs. tls1.1 vs. tls1.0 (for example tls1.2
has TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 and if I set that as the
first cipher in tls_medium_cipherlist, what happens with tls1.1 and
tls1.0, which does not support that cipher?).

I know that 'hardening postfix' threads have been posted here a number
of times, I've read them and I understand the recommendations if you
want to continue delivering and accepting email from the internet. What
I'm trying to find out if there is a way to thread the needle: favor
"better" ciphers, while limiting the impact to ancient software. I say
'limit' because I realize that even just turning on
`tls_preempt_cipher_list=yes` will already cause problems with Windows
2000 Microsoft Exchange, but I feel that may be an acceptable trade-off
at this point.

micah

0. <a href="http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist" title="http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist">http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist</a>

1. not even sure this would be the right format, but this would be the order:

tls_medium_cipherlist=TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_RSA_WITH_SEED_CBC_SHA:TLS_DHE_RSA_WITH_SEED_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_128_CCM:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_256_CCM:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_CCM:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_256_CCM:TLS_RSA_WITH_AES_128_CCM_8:TLS_RSA_WITH_AES_256_CCM_8:TLS_DHE_RSA_WITH_AES_128_CCM_8:TLS_DHE_RSA_WITH_AES_256_CCM_8:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

Comments

Re: possible to reach hardenize's requirements?

By Ralph Seichter at 04/12/2019 - 17:57

Hm. Hardenize tells me "Email TLS ... not implemented or disabled",
which I don't quite understand, given the following settings:

smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_dh512_param_file = /etc/ssl/private/dh512.pem
smtpd_tls_dh1024_param_file = /etc/ssl/private/dh2048.pem
smtpd_tls_CApath = ...
smtpd_tls_cert_file = ...
smtpd_tls_key_file = ...
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may

So, who is confused, me or Hardenize?

-Ralph

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/12/2019 - 18:11

Naturally the latter, but over IPv6 your SMTP server does have a
rather noticeable pre-greet delay, perhaps Hardenize defaults to
IPv6 and is unwilling to wait that long. The ipv4 service is
more responsive.

$ posttls-finger -aipv4 -L summary monksofcool.net
posttls-finger: Connected to ra.horus-it.com[94.130.34.199]:25
posttls-finger: < 220 ra.horus-it.com ESMTP
posttls-finger: > EHLO amnesiac.invalid
posttls-finger: < 250-ra.horus-it.com
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 31457280
posttls-finger: < 250-VRFY
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-DSN
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: Verified TLS connection established to ra.horus-it.com[94.130.34.199]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO amnesiac.invalid
posttls-finger: < 250-ra.horus-it.com
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 31457280
posttls-finger: < 250-VRFY
posttls-finger: < 250-ETRN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-DSN
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

Re: possible to reach hardenize's requirements?

By Ralph Seichter at 04/13/2019 - 09:47

* Viktor Dukhovni:

Thanks for checking. While the server is moving north of 80 Mbyte/s of
network traffic (evenly spread between in- and outbound) over thousands
of connections, I don't know if that might be a possible reason for the
delay you observed?

-Ralph

Re: possible to reach hardenize's requirements?

By LuKreme at 04/12/2019 - 11:47

On 12 Apr 2019, at 08:46, micah anderson < ... at riseup dot net> wrote:
I'm not impressed. It complains that STARTTLS is not available on my server. It is true it is not available on port 25, ut is available on port 587 where it should be.

Re: possible to reach hardenize's requirements?

By Bill Cole at 04/12/2019 - 12:55

Are you confusing STARTTLS and AUTH???

There's no need for AUTH on 25 if you have a working 587 or 465 service
for submission.

It is a good idea to enable STARTTLS on port 25 if you don't want
inbound SMTP to be sniffable on the wire.

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/12/2019 - 12:07

Frankly, best practice nowadays is to also have STARTTLS on port 25.
Perhaps none of your users expect or desire protection from passive
traffic monitoring, but it is not unreasonable to expect it as a
standard feature.

Re: possible to reach hardenize's requirements?

By Wietse Venema at 04/12/2019 - 12:58

Viktor Dukhovni:
I see it more like best practice nowadays is to check boxes until
the red goes away.

Wietse

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/12/2019 - 13:31

Yes, that's another way of looking at it... :-)

Re: possible to reach hardenize's requirements?

By Micah Anderson at 04/12/2019 - 12:42

"@lbutlr" < ... at kreme dot com> writes:

Since they are not testing submission, this seems correct.

You have disabled STARTTLS on port 25 and only accept unencrypted
connections there?

Re: possible to reach hardenize's requirements?

By LuKreme at 04/12/2019 - 14:36

It is not correct to classy this as a warning.

Actually, no. STARTTLS is on port 25 for servers, but hardenize reports it's not available, which for some reason this morning I thought was an indication it was testing it as a login feature. I do not allow logins on port 25.

I've since closed the window on hardenize, so I can't easily check what the specific warning text was.

Re: possible to reach hardenize's requirements?

By Dominic Raferd at 04/13/2019 - 02:57

On 12/04/2019 19:36, @lbutlr wrote:
I too find that hardenize complains about my STARTTLS without any
details as to why. Like @lbutlr (and most of us) I offer STARTTLS on
port 25 but not AUTH. However I see this message in my log after the
test ran, I think hardenize is hitting my server too hard and maybe that
is why it is (wrongly) saying there is a problem with the server:

2019-04-13 07:36:23 streamingbats postfix/smtpd[19724]: warning:
Connection rate limit exceeded: 31 from
outbound.hardenize.com[18.233.176.231] for service smtp

Re: possible to reach hardenize's requirements?

By Ralph Seichter at 04/13/2019 - 09:39

* Dominic Raferd:

Hardenize's first test run caused my fail2ban setup to silently ban the
IPs where the probing originated. Still, even with fail2ban disabled,
TLS is mistakenly reported as "not implemented".

-Ralph

Re: possible to reach hardenize's requirements?

By LuKreme at 04/13/2019 - 03:09

On 13 Apr 2019, at 00:57, Dominic Raferd < ... at timedicer dot co.uk> wrote:
Checking my logs:

postfix/smtpd[45229]: connect from outbound.hardenize.com[18.233.176.231]
postfix/smtpd[45229]: SSL_accept error from outbound.hardenize.com[18.233.176.231]: -1
postfix/smtpd[45229]: lost connection after STARTTLS from outbound.hardenize.com[18.233.176.231]
postfix/smtpd[45229]: disconnect from outbound.hardenize.com[18.233.176.231] ehlo=1 starttls=0/1 commands=½

Re: possible to reach hardenize's requirements?

By Wietse Venema at 04/13/2019 - 10:23

Same here. Speculation: they require PKI certificate verification.

Wietse

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/13/2019 - 10:46

One might also speculate that they try various ciphers and protocols, some of which
don't pan out. The only way to determine which ciphers a server supports is to
try lots of connections, servers don't send their complete cipherlist to clients,
they only send the one cipher they accepted. Ditto with protocol versions.

So one would expect a failed handshake any time an unsupported cipher or protocol
is tested.

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/12/2019 - 11:36

Any reasonably recent version of OpenSSL will by default favour stronger
ciphers, including listing ciphers that do forward-secrecy above the rest.
For example, with OpenSSL 1.0.2 I get:

$ openssl ciphers -v 'HIGH+AES:!eNULL:!PSK:!SRP:!aDSS:!kDH:!kECDH:!aNULL'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

The 'HIGH+AES:!eNULL:!PSK:!SRP:!aDSS:!kDH:!kECDH:!aNULL' is not intended as a
recommended configuration, rather it cuts down on some of the noise, showing
the overall cipher order for just AES. The top nine ciphers all offer
forward-secrecy.

That said, I would recommend reducing the attack surface by dropping some
ciphers nobody is using that would not be a good idea to use:

smtpd_tls_exclude_ciphers = aDSS, kDH, kECDH, SEED, IDEA

you could add RC4 and 3DES to the list if Exchange 2003 is no longer on your
radar.

Re: possible to reach hardenize's requirements?

By Micah Anderson at 04/12/2019 - 12:34

Viktor Dukhovni <postfix- ... at dukhovni dot org> writes:

Indeed, you are right, if I simply set `tls_preempt_cipher_list=yes`,
then this will work that way.

what about aNULL, MD5 and DES? They seem relatively safe to disable as well

Re: possible to reach hardenize's requirements?

By Viktor Dukhovni at 04/12/2019 - 13:26

Yes, I think this is by now unlikely to cause any issues.

* You don't need to explicitly disable (single) DES, it is already
taken care of by setting the cipher grade to medium (or high).
Perhaps you meant 3DES, yes, you can add that to the list.

I have (ditt for the client settings):

smtpd_tls_exclude_ciphers =
#
# Disable MD5, DSA, SRP and PSK, and the "exotic" fixed DH cipher suites.
#
MD5, SRP, PSK, aDSS, kECDH, kDH,
#
# Also disable the largely unused SEED, IDEA, RC2, RC5, ...
# leaving just AES, CAMELLIA, RC4 and 3DES.
#
SEED, IDEA, RC2, RC5

I don't actually end up with 3DES or RC4, (along with RC2 or RC5)
they're by default disabled at compile time in OpenSSL 1.1.1:

$ openssl ciphers -ciphersuites "" -v 3DES:RC4:IDEA:SEED:RC2:RC5
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1

* If your cipher grade is medium, you should probably disable MD5, which
eliminates at most two ciphers:

$ OpenSSL_1_0_2/bin/openssl ciphers -v 'MEDIUM+MD5'
ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5

* As for aNULL, it is no longer available when TLS 1.3 is negotiated. :-(
Recent IETF consensus is to drop ballast and batten down the
hatches. If your use-case is not mainstream enough, out it goes.

That said, see <a href="https://tools.ietf.org/html/rfc7672#section-8.2" title="https://tools.ietf.org/html/rfc7672#section-8.2">https://tools.ietf.org/html/rfc7672#section-8.2</a>

Re: possible to reach hardenize's requirements?

By Scott Kitterman at 04/12/2019 - 11:09

On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:
If I followed their DMARC recommendation, that would translate into 90% of the
mail I send getting spam foldered or rejected. At a glance, I'm not convinced
this is any more than "let's make a list of all the things". For the parts I
looked at, I don't thinks it's all well thought through.

Scott K

Re: possible to reach hardenize's requirements?

By Micah Anderson at 04/12/2019 - 12:41

Scott Kitterman < ... at kitterman dot com> writes:

Technically, their DMARC test does not give you a warning or a failure,
it just says "Feature is not implemented or disabled" and it colors it
'grey' -- this is their way of saying that this is not something they
are currently recommending, one way or the other.

They have this text:

Although syntactically valid, your DMARC policy is effectively
disabled. An effective policy must set the value of the 'p' directive
to either 'quarantine' or 'reject'. In addition, if the 'pct' directive
is present, it must be set to a value other than zero. (The default is
100, which means to apply policy to all emails.)

I think they are being fair here, it is true my policy is effectively
disabled, and it is true that an effective policy has to do that. They
don't give me any penalty for having a policy that p=none.

However, I do think that it might be more 'clear' if they said something
like "if you set p=reject, you are likely to have 90% of the mail you
send getting spam foldered or rejected".

Re: possible to reach hardenize's requirements?

By Ralph Seichter at 04/12/2019 - 17:49

* micah anderson:

I use dedicated domains without DMARC policies for mailing lists. For my
other domains, I use p=quarantine and pct=90. This seems to work fine
for me.

-Ralph

Re: possible to reach hardenize's requirements?

By Per Thorsheim at 04/12/2019 - 11:19

Den 12/04/2019 17:09, skrev Scott Kitterman:
I've been a betatester on Hardenize for quite some time, and the service
is being developed by Ivan Ristic (SSLLabs). I'll leave it to him to
explain and defend the considerations made, but afaik recommendations
are based on reading the RFCs and TLS recommendations overall. Yes, some
attacks are not realistic because smtp != https. For what's its worth,
the service is very helpful in showing people in shirt & tie how things
are, and how they preferably should be. Likewise with the tests at
internet.nl, or MECSA <a href="https://mecsa.jrc.ec.europa.eu" title="https://mecsa.jrc.ec.europa.eu">https://mecsa.jrc.ec.europa.eu</a>
<https://mecsa.jrc.ec.europa.eu/>

.per

Re: possible to reach hardenize's requirements?

By Micah Anderson at 04/12/2019 - 11:02

micah anderson < ... at riseup dot net> writes:

I'll note that gmail.com[0] does manage to reach this requirement, they
prefer ciphers for each tls version, and only seem to present 10 ciphers
for tls1.2, and 5 for tls1.1 and tls1.0.

I feel like if gmail is limiting their ciphers to those few, it must be
relatively safe for others to do so as well.

0. <a href="https://www.hardenize.com/report/gmail.com/1554931211#email_tls" title="https://www.hardenize.com/report/gmail.com/1554931211#email_tls">https://www.hardenize.com/report/gmail.com/1554931211#email_tls</a>