possible to reach hardenize's requirements?

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

possible to reach hardenize's requirements?

Micah Anderson-2

The site https://hardenize.com 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. http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist

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
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Micah Anderson-2
micah anderson <[hidden email]> writes:

> 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.

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. https://www.hardenize.com/report/gmail.com/1554931211#email_tls
--
        micah
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Scott Kitterman-4
In reply to this post by Micah Anderson-2
On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:
> The site https://hardenize.com 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Per Thorsheim
Den 12/04/2019 17:09, skrev Scott Kitterman:
On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:
The site https://hardenize.com 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.
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

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 https://mecsa.jrc.ec.europa.eu

.per


Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Viktor Dukhovni
In reply to this post by Micah Anderson-2
> On Apr 12, 2019, at 10:46 AM, micah anderson <[hidden email]> wrote:
>
> 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.

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.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

@lbutlr
In reply to this post by Micah Anderson-2
On 12 Apr 2019, at 08:46, micah anderson <[hidden email]> wrote:
> he site https://hardenize.com 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.

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.


--
What was it they said about gods? They wouldn't exist if there weren't
people to believe in them? And that applied to everything. Reality was
what went on inside people's heads. --Moving Pictures


Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Viktor Dukhovni
> On Apr 12, 2019, at 11:47 AM, @lbutlr <[hidden email]> 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.

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.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Micah Anderson-2
In reply to this post by Viktor Dukhovni
Viktor Dukhovni <[hidden email]> writes:

>> On Apr 12, 2019, at 10:46 AM, micah anderson <[hidden email]> wrote:
>>
>> 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.
>
> 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:

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

> 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

what about aNULL, MD5 and DES? They seem relatively safe to disable as well
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Micah Anderson-2
In reply to this post by Scott Kitterman-4
Scott Kitterman <[hidden email]> writes:

> On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:
>> The site https://hardenize.com 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.
>
> 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.

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".

--
        micah
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Micah Anderson-2
In reply to this post by @lbutlr
"@lbutlr" <[hidden email]> writes:

> On 12 Apr 2019, at 08:46, micah anderson <[hidden email]> wrote:
>> he site https://hardenize.com 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.
>
> 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.

Since they are not testing submission, this seems correct.

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

--
        micah
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Bill Cole-3
In reply to this post by @lbutlr
On 12 Apr 2019, at 11:47, @lbutlr wrote:

> On 12 Apr 2019, at 08:46, micah anderson <[hidden email]> wrote:
>> he site https://hardenize.com 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.
>
> 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.

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.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:
> > On Apr 12, 2019, at 11:47 AM, @lbutlr <[hidden email]> 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.
>
> 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.

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

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Viktor Dukhovni
In reply to this post by Micah Anderson-2
On Fri, Apr 12, 2019 at 12:34:16PM -0400, micah anderson wrote:

> > 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:
>
> Indeed, you are right, if I simply set `tls_preempt_cipher_list=yes`,
> then this will work that way.

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

> > 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
>
> what about aNULL, MD5 and DES? They seem relatively safe to disable as well

* 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 https://tools.ietf.org/html/rfc7672#section-8.2

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

Re: possible to reach hardenize's requirements?

Viktor Dukhovni
In reply to this post by Wietse Venema
On Fri, Apr 12, 2019 at 12:58:48PM -0400, Wietse Venema wrote:

> Viktor Dukhovni:
> > > On Apr 12, 2019, at 11:47 AM, @lbutlr <[hidden email]> 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.
> >
> > 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.
>
> I see it more like best practice nowadays is to check boxes until
> the red goes away.

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

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

Re: possible to reach hardenize's requirements?

@lbutlr
In reply to this post by Micah Anderson-2


> On 12 Apr 2019, at 10:42, micah anderson <[hidden email]> wrote:
>
> "@lbutlr" <[hidden email]> writes:
>
>> On 12 Apr 2019, at 08:46, micah anderson <[hidden email]> wrote:
>>> he site https://hardenize.com 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.
>>
>> 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.
>
> Since they are not testing submission, this seems correct.

It is not correct to classy this as a warning.

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

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.


--
Reality is not a matter of opinion.


Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Ralph Seichter-2
In reply to this post by Micah Anderson-2
* micah anderson:

> 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".

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
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Ralph Seichter-2
In reply to this post by Micah Anderson-2
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
Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

Viktor Dukhovni
On Fri, Apr 12, 2019 at 11:57:09PM +0200, Ralph Seichter wrote:

> 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?

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

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

Re: possible to reach hardenize's requirements?

Dominic Raferd
In reply to this post by @lbutlr
On 12/04/2019 19:36, @lbutlr wrote:

>
>> On 12 Apr 2019, at 10:42, micah anderson <[hidden email]> wrote:
>>
>> "@lbutlr" <[hidden email]> writes:
>>
>>> On 12 Apr 2019, at 08:46, micah anderson <[hidden email]> wrote:
>>>> he site https://hardenize.com 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.
>>> 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.
>> Since they are not testing submission, this seems correct.
> It is not correct to classy this as a warning.
>
>> You have disabled STARTTLS on port 25 and only accept unencrypted
>> connections there?
> 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 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

Reply | Threaded
Open this post in threaded view
|

Re: possible to reach hardenize's requirements?

@lbutlr
On 13 Apr 2019, at 00:57, Dominic Raferd <[hidden email]> 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

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=½


--
It's better to burn out than it is to rust -- Neil Young as quoted be
Kurt Cobain


12