Disabling TLSv1

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

Disabling TLSv1

ratatouille-2
Hello!

Don't know why TLSv1 is still offered on our servers running

mail_version = 2.11.3
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1

but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.

I am not sure what's wrong. What do I miss?

Other parameters I set:
smtpd_tls_CApath = /var/lib/ca-certificates/pem
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1, ECDHE-RSA-DES-CBC3-SHA
smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_tls_session_cache_timeout = 3600s

Regards

  Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Viktor Dukhovni
On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote:

> Don't know why TLSv1 is still offered on our servers running

Probably because you're not changing the configuration in the right
place.  Double-check that you're configuring the correct Postfix
instance (if using multiple instances) and that there are no
master.cf overrides that trump the main.cf settings.

> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1

It is not yet a good idea to disable TLSv1 in SMTP.  But if you must
degrade[1] your SMTP security for some clients to make sure that all the
check boxes come out green, then the above should be enough, provided it
is set in the right place.  I can confirm that bitclusive.de still
supports TLSv1:

    $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de
    posttls-finger: Verified TLS connection established to smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

    $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1 bitclusive.de
    posttls-finger: Verified TLS connection established to smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Other than test TLS connections, do you still legitimate inbound email
in your logs (looking over a week or more of logs) delivered with TLSv1?

If not, then perhaps disabling TLSv1 will be harmless, but if you do,
perhaps prod the senders to upgrade first, before you prevent them
from establishing TLS connections to your MTA.

--
    Viktor.

[1] Some clients forced to send in clear text, because they don't do
TLSv1.2.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Daniel Ryšlink
In reply to this post by ratatouille-2
Hello,

I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at the
beginning of the year (since there were advisories that anything older
than 1.2 is considered weak and broken), and it did not end well, there
were numerous complaints from what turned out to be still supported LTS
version of Windows 8 that is supported till 2023 whose Outlooks still
uses the obsolete versions of TLS and their handshakes will fail.

--
S pozdravem,
Daniel Ryšlink

On 05-Mar-20 21:08, ratatouille wrote:

> Hello!
>
> Don't know why TLSv1 is still offered on our servers running
>
> mail_version = 2.11.3
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
>
> but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
>
> I am not sure what's wrong. What do I miss?
>
> Other parameters I set:
> smtpd_tls_CApath = /var/lib/ca-certificates/pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
> smtpd_tls_ciphers = high
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1, ECDHE-RSA-DES-CBC3-SHA
> smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
> smtpd_tls_session_cache_timeout = 3600s
>
> Regards
>
>    Andreas
>
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

ratatouille-2
In reply to this post by Viktor Dukhovni
Viktor Dukhovni <[hidden email]> schrieb am 05.03.20 um 16:44:14 Uhr:

> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote:
>
> > Don't know why TLSv1 is still offered on our servers running  
>
> Probably because you're not changing the configuration in the right
> place.  Double-check that you're configuring the correct Postfix
> instance (if using multiple instances) and that there are no
> master.cf overrides that trump the main.cf settings.
>
> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1  

Found out if I want to disable TLSv1.1 too I just have to do so.
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
and suddenly it works ;)

> It is not yet a good idea to disable TLSv1 in SMTP.  But if you must
> degrade[1] your SMTP security for some clients to make sure that all the
> check boxes come out green, then the above should be enough, provided it
> is set in the right place.  I can confirm that bitclusive.de still
> supports TLSv1:
>
>     $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de
>     posttls-finger: Verified TLS connection established to smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>
>     $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1 bitclusive.de
>     posttls-finger: Verified TLS connection established to smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>
> Other than test TLS connections, do you still legitimate inbound email
> in your logs (looking over a week or more of logs) delivered with TLSv1?

I have just too TLSv1 connections this month:
...
11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
  9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
  9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
  9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
  8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
  8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
  8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
  7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
  7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
  7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
  7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
  7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
  4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
  2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
  1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
  1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

> If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> perhaps prod the senders to upgrade first, before you prevent them
> from establishing TLS connections to your MTA.

internet.nl says TLS 1.1 should be phased out and criticises this.

It also critcises the key exchange paramert DH-4096 as insufficient
I just created that key and made it available with
smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem

Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
for now.

--
Regards

  Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Viktor Dukhovni
On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:

> I have just too TLSv1 connections this month:
> ...
> 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
>   9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
>   9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
>   9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
>   8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
>   8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
>   8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
>   7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
>   7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
>   7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
>   7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
>   7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
>   4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
>   2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
>   1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>   1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

That's two out of not very many total, are these actual message
deliveries, or just probes (tests)?

> > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > perhaps prod the senders to upgrade first, before you prevent them
> > from establishing TLS connections to your MTA.
>
> internet.nl says TLS 1.1 should be phased out and criticises this.

Just because they say it, doesn't mean it is actually the wise thing to do.

> It also critcises the key exchange paramert DH-4096 as insufficient

See above.

> I just created that key and made it available with
> smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem

Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
supported in some client stacks.

> Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> for now.

You can keep an eye on your logs and decide when it is time to drop
support.  The most important thing is supporting stronger options that
most clients will negotiate.  Removing weaker options is less of a
priority except when they enable a downgrade attack.

In the case of TLSv1 there's no known (to me anyway) downgrade attack
from TLSv1.2.  SMTP MTAs don't do TLS version fallback, like browsers
used to do.  There's no urgent need to drop support TLSv1 inbound.

Just make sure that you support at least TLSv1.2, and ignore the
checklists that try to shame you for leaving TLSv1 enabled.

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

Re: Disabling TLSv1

wa6vvv
In reply to this post by ratatouille-2

> On 5 March 2020, at 15:26, ratatouille <[hidden email]> wrote:
>
> Viktor Dukhovni <[hidden email]> schrieb am 05.03.20 um 16:44:14 Uhr:
>
>> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote:
>>
>>> Don't know why TLSv1 is still offered on our servers running  
>>
>> Probably because you're not changing the configuration in the right
>> place.  Double-check that you're configuring the correct Postfix
>> instance (if using multiple instances) and that there are no
>> master.cf overrides that trump the main.cf settings.
>>
>>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
>>> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1  
>
> Found out if I want to disable TLSv1.1 too I just have to do so.
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
> and suddenly it works ;)
>
>> Other than test TLS connections, do you still legitimate inbound email
>> in your logs (looking over a week or more of logs) delivered with TLSv1?
>
> I have just too TLSv1 connections this month:
> ...
> 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
>  9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
>  9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
>  9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
>  8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
>  8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
>  8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
>  7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
>  7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
>  7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
>  7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
>  7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
>  4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
>  2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
>  1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>  1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

Small mail server with 3 weeks of logs:

   1761 TLSv1
     18 TLSv1.1
  20414 TLSv1.2
   6343 TLSv1.3
      0 SSL

That's not what I expected.  I thought v1 and v1.1 would be reversed.  There is a complete spectrum of ciphers being used with v1 including some of the most recent.  I am using the defaults for the protocols and ciphers.

-- Doug
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Viktor Dukhovni
On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote:

> Small mail server with 3 weeks of logs:
>
>    1761 TLSv1
>      18 TLSv1.1
>   20414 TLSv1.2
>    6343 TLSv1.3
>
> That's not what I expected.  I thought v1 and v1.1 would be reversed.
> There is a complete spectrum of ciphers being used with v1 including
> some of the most recent.  I am using the defaults for the protocols
> and ciphers.

The reversal is expected, the most widely used TLS implementations that
support TLSv1.1 also support TLSv1.2, and so you see very little use of
TLSv1.1.  The ancient stacks that haven't yet adopted TLS1.2, mostly
never got to TLSv1.1 either.

An interesting question in your case is what fraction of the TLSv1
connections are non-spam.  Perhaps you're able to correlate the TLSv1
connections with legitimate vs. junk email.

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

Re: Disabling TLSv1

allenc
In reply to this post by ratatouille-2
Virtually all my TLSv1 connections come from this mailing list...

Would there be any mileage in disabling OUTBOUND TLSv1 connections while
accepting inbound for a little while longer?

Allen C

On 05/03/2020 20:08, ratatouille wrote:

> Hello!
>
> Don't know why TLSv1 is still offered on our servers running
>
> mail_version = 2.11.3
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
>
> but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
>
> I am not sure what's wrong. What do I miss?
>
> Other parameters I set:
> smtpd_tls_CApath = /var/lib/ca-certificates/pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
> smtpd_tls_ciphers = high
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1, ECDHE-RSA-DES-CBC3-SHA
> smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
> smtpd_tls_session_cache_timeout = 3600s
>
> Regards
>
>   Andreas
>
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Viktor Dukhovni
On Fri, Mar 06, 2020 at 02:16:42AM +0000, Allen Coates wrote:

> Virtually all my TLSv1 connections come from this mailing list...
>
> Would there be any mileage in disabling OUTBOUND TLSv1 connections while
> accepting inbound for a little while longer?

You can certainly configure each direction as appropriate.  In the
outbound direction you also have the choice of per-destination policy.

So yes, it is not unreasonable (though not that compelling, or worth
much effort) to disable TLSv1 by default, and then perhaps enable it
for just any sites where TLS handshakes start to fail.

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

Re: Disabling TLSv1

wa6vvv
In reply to this post by Viktor Dukhovni
> On 5 March 2020, at 17:15, Viktor Dukhovni <[hidden email]> wrote:
>
> On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote:
>
>> Small mail server with 3 weeks of logs:
>>
>>   1761 TLSv1
>>     18 TLSv1.1
>>  20414 TLSv1.2
>>   6343 TLSv1.3
>>
>> That's not what I expected.  I thought v1 and v1.1 would be reversed.
>> There is a complete spectrum of ciphers being used with v1 including
>> some of the most recent.  I am using the defaults for the protocols
>> and ciphers.
>
> The reversal is expected, the most widely used TLS implementations that
> support TLSv1.1 also support TLSv1.2, and so you see very little use of
> TLSv1.1.  The ancient stacks that haven't yet adopted TLS1.2, mostly
> never got to TLSv1.1 either.
>
> An interesting question in your case is what fraction of the TLSv1
> connections are non-spam.  Perhaps you're able to correlate the TLSv1
> connections with legitimate vs. junk email.

The code to scan the logs is a bit convoluted.  I have it running, but there are 44K connections to check so it will undoubtly run all night.  It has completed 1200 so far in about 11 minutes.  So it will take over 6.5 hours to complete.

-- Doug

Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

ratatouille-2
In reply to this post by Viktor Dukhovni
Hello!

Viktor Dukhovni <[hidden email]> schrieb am 05.03.20 um 18:52:55 Uhr:

> On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:
>
> > I have just too TLSv1 connections this month:
> > ...
> > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
> >   9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
> >   9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
> >   9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> >   8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> >   8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
> >   8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
> >   7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
> >   7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
> >   7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> >   7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
> >   7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
> >   4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
> >   2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
> >   1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
> >   1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)  
>
> That's two out of not very many total, are these actual message
> deliveries, or just probes (tests)?

That were two probes without deliveries.

On another machine I use for communicating with this maillingist I
have 25 TLSv1-connections, 23 from and 2 to connections, all with this
mailinglist.

> > > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > > perhaps prod the senders to upgrade first, before you prevent them
> > > from establishing TLS connections to your MTA.  
> >
> > internet.nl says TLS 1.1 should be phased out and criticises this.  
>
> Just because they say it, doesn't mean it is actually the wise thing to do.
>
> > It also critcises the key exchange paramert DH-4096 as insufficient  
>
> See above.
>
> > I just created that key and made it available with
> > smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem  
>
> Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
> supported in some client stacks.

Went back to DH-2048.

> > Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> > for now.  
>
> You can keep an eye on your logs and decide when it is time to drop
> support.  The most important thing is supporting stronger options that
> most clients will negotiate.  Removing weaker options is less of a
> priority except when they enable a downgrade attack.
>
> In the case of TLSv1 there's no known (to me anyway) downgrade attack
> from TLSv1.2.  SMTP MTAs don't do TLS version fallback, like browsers
> used to do.  There's no urgent need to drop support TLSv1 inbound.

Would it to any harm if I drop TLSv1 outbound? Will this cut off the handshake
with this mailinglist for example?
 
> Just make sure that you support at least TLSv1.2, and ignore the
> checklists that try to shame you for leaving TLSv1 enabled.
 
yes, ok.

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

Re: Disabling TLSv1

Matus UHLAR - fantomas
In reply to this post by Daniel Ryšlink
On 06.03.20 00:11, Daniel Ryšlink wrote:
>I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at
>the beginning of the year (since there were advisories that anything
>older than 1.2 is considered weak and broken), and it did not end
>well, there were numerous complaints from what turned out to be still
>supported LTS version of Windows 8 that is supported till 2023 whose
>Outlooks still uses the obsolete versions of TLS and their handshakes
>will fail.

note that there's difference between disabling tls1.0 and tls1.1 on ports
with mandatory encryption (smtps/465 and submission/587) and different on
port 25 where mail servers will connect to.

enabling older TLS versions might be better for old servers as low
encryption may be better than no encryption on port 25, where fallback when
TLS can't be established is common - you do want to receive mail from the
internet, don't you?

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

wa6vvv
In reply to this post by Viktor Dukhovni
> On 5 March 2020, at 17:15, Viktor Dukhovni <[hidden email]> wrote:
>
> On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote:
>
>> Small mail server with 3 weeks of logs:
>>
>>   1761 TLSv1
>>     18 TLSv1.1
>>  20414 TLSv1.2
>>   6343 TLSv1.3
>>
>> That's not what I expected.  I thought v1 and v1.1 would be reversed.
>> There is a complete spectrum of ciphers being used with v1 including
>> some of the most recent.  I am using the defaults for the protocols
>> and ciphers.
>
> The reversal is expected, the most widely used TLS implementations that
> support TLSv1.1 also support TLSv1.2, and so you see very little use of
> TLSv1.1.  The ancient stacks that haven't yet adopted TLS1.2, mostly
> never got to TLSv1.1 either.
>
> An interesting question in your case is what fraction of the TLSv1
> connections are non-spam.  Perhaps you're able to correlate the TLSv1
> connections with legitimate vs. junk email.

Results for 3 weeks of log files:

TLSv1   spam = 1182 ham = 1147
TLSv1.1 spam = 74 ham = 6
TLSv1.2 spam = 24355 ham = 10461
TLSv1.3 spam = 4453 ham = 2305

Note, that the definition of spam is there is a NOQUEUE entry for that IP address in the log files.  Hence this is an approximation as it is possible that the RBLs entries could have changed during those 3 weeks.  Also, I don't know what emails the recipients considered spam.  Only 2 users have mailboxes on my servers.  The others are elsewhere.

-- Doug


Reply | Threaded
Open this post in threaded view
|

Re: Disabling TLSv1

Viktor Dukhovni
On Fri, Mar 06, 2020 at 05:51:19AM -0800, Doug Hardie wrote:

> > An interesting question in your case is what fraction of the TLSv1
> > connections are non-spam.  Perhaps you're able to correlate the TLSv1
> > connections with legitimate vs. junk email.
>
> Results for 3 weeks of log files:
>
> TLSv1   spam = 1182 ham = 1147
> TLSv1.1 spam = 74 ham = 6
> TLSv1.2 spam = 24355 ham = 10461
> TLSv1.3 spam = 4453 ham = 2305
>
> Note, that the definition of spam is there is a NOQUEUE entry for that
> IP address in the log files.  Hence this is an approximation as it is
> possible that the RBLs entries could have changed during those 3
> weeks.  Also, I don't know what emails the recipients considered spam.
> Only 2 users have mailboxes on my servers.  The others are elsewhere.

Thanks for the data points.  So TLSv1 is not all spam, and so still
likely best left enabled a bit longer.  Unless it was all Postfix list
traffic. :-)  The folks at Cloud9 have not been keeping up with the
Joneses with their TLS stack versions, some day soon TLSv1 will actually
be turned off more broadly, and they'll have to upgrade or disable TLS
entirely...

--
    Viktor.