TLS 1.0/1.1 deprecated in 03/2021. Wouldja disable them on SMTP/MTA by 08/2026 and not lose emails?

jsg

@manish said:

@david said: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Don't the vulnerabilities come from the protocol-level implementation, not the cipher suite itself?

One answer (of many possible): what's the worth of a no matter how good protocol-level implementation - of an SSL/TLS related program, mind you - when the crypto is questionable?

@jsg said: most people just use the cipher settings that come by default (incl. awful crap)

And with any reasonable MTA, it should go well, isn't it?

The cipher settings are nothing to do with the MTA.

nikio

@manish said:

@tommyluo said: centos6,centos7,windows 2008,all out of date,but still many using these systems.

Yes, correct. Just because something is deprecated doesn't mean it's technically unacceptable or dysfunctional immediately.

Incorrect. Windows 8 is dysfunctional and unacceptable as a matter of course. CentOS is just plain dysfunctional.

manish

@jsg said: The cipher settings are nothing to do with the MTA.

Some MTAs have secure defaults without having to configure anything in terms of cipherlist and TLS protocols. For instance no ciphersuites without FS.

manish

@nikio said: just plain dysfunctional.

It's not technically dysfunctional. My point is that when the IETF says that X, Y and Z are deprecated, that doesn't automatically make it a worldwide rule from XYZ hours.

david

@manish said: Don't the vulnerabilities come from the protocol-level implementation, not the cipher suite itself?

I'm not aware of any successful hack of TLS 1.1, but maybe someone else knows of some. TLS 1.1 was published in 2006 and TLS 1.2 was published in 2008.

But even if it's vulnerable, what's the exposure? The email is decrypted? The alternative would be transmitting it unencrypted, anyway. Email encryption is opportunistic.

manish

@david said: Email encryption is opportunistic.

That true. So, for now, you will stick to TLS 1.1 as minimum. Productive feedback from you. Thanks again!

jorohe6515

There are security flaws using downgrading attacks on TLS versions, so a general recommendation is to disable all SSLvX, TLS1.0 and TLS1.1. Afaik TLS1.2 is still considered to be safe, even if deprecated.

However, I also think that you should offer TLS1.0 and TLS1.1 (at least I do, with strategy in mind: better weak encryption than no encryption for old senders).

But what to do, to mitigate downgrading attacks from TLS1.3 to 1.1/1.0 for "modern" senders? Easy, just enable MTA-STS, which enforces min. TLS1.2

So my recommendation would be: use MTA-STS with accepting TLS1.0 to TLS1.3 --or in case you cannot setup MTA-STS for your domains, allow TLS1.2 and 1.3 only.

jorohe6515

@david said:
But even if it's vulnerable, what's the exposure? The email is decrypted? The alternative would be transmitting it unencrypted, anyway. Email encryption is opportunistic.

The risk are downgrading attacks where modern servers are forced to use a vulnerable version. Then, email could maybe decrypted. To prevent, use MTA-STS and you should be fine to accept older versions.

DANE btw could also be used for same purpose, but I think MTA-STS (even if theoretically worse) is used more often today. To be sure, you can also enable both:)

david

@jorohe6515 said:

@david said:
But even if it's vulnerable, what's the exposure? The email is decrypted? The alternative would be transmitting it unencrypted, anyway. Email encryption is opportunistic.

The risk are downgrading attacks where modern servers are forced to use a vulnerable version. Then, email could maybe decrypted. To prevent, use MTA-STS and you should be fine to accept older versions.

DANE btw could also be used for same purpose, but I think MTA-STS (even if theoretically worse) is used more often today. To be sure, you can also enable both:)

That's a good point, and a good reason to disable TLS v1.0/v1.1 if not using MTA-STS (which I'm not currently). So I've changed my mind about this and disabled it and I'll go with TLS v1.2 and v1.3 only for now.

manish

@jorohe6515 said: TLS1.2 is still considered to be safe, even if deprecated.

Is it officially deprecated by IETF or any other org?

@jorohe6515 said: for old senders

Yes, exactly why I opened this discussion, to get data on who these old senders are and whether they even exist. So far, admins have confirmed that TLS 1.1 is still in active use as per the stats of their servers. TLS 1.0 is dead.

@jorohe6515 said: DANE btw could also be used for same purpose, but I think MTA-STS (even if theoretically worse)

They are related technologies and cannot replace/interfere the other even when the two clash/overlap.

I must appreciate the dev of the MTA I picked. I have SMTP Security via DANE and MTA-STS implemented from get go. Also default secure ciphersuites even with TLS 1.0...1.3 enabled where there is none in the cipherlist without FS even with AEAD.

@david said: So I've changed my mind about this and disabled it and I'll go with TLS v1.2 and v1.3 only for now.

Great choice, I forgot to add whether people use MTA-STS, DANE DNSSEC in my question originally. I just took it as granted in 2026.

Or you could just deploy the modern SMTP Security mechanisms.

jorohe6515

@manish said:
Is it officially deprecated by IETF or any other org?

IETF says it is obsolete and replaced with 1.3
https://www.rfc-editor.org/info/rfc5246/

I must appreciate the dev of the MTA I picked. I have SMTP Security via DANE and MTA-STS implemented from get go. Also default secure ciphersuites even with TLS 1.0...1.3 enabled where there is none in the cipherlist without FS even with AEAD.

Exactly same config here (but not on maddy). I think this is a good setup.

manish

@jorohe6515 said: IETF says it is obsolete

Yet we are discussing whether or not to support TLS 1.0/1.1 for MTAs. Such is the legacy of email systems?

US's NSA called TLS 1.0/1.1 obsolete in Jan 2021.

@jorohe6515 said:

Exactly same config here (but not on maddy). I think this is a good setup.

What do you use if you like to share?

tommyluo

Seems most of the mail service providers are using TLS 1.3 as long as the recipient server supports it:

Anonymous TLS connection established from mail-qt1-f171.google.com[209.85.160.171]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-oa1-f44.google.com[209.85.160.44]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-lj1-f181.google.com[209.85.208.181]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-yw1-f169.google.com[209.85.128.169]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

Anonymous TLS connection established from mail-northeuropeazolkn19010020.outbound.protection.outlook.com[52.103.32.20]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-westus3azolkn19010027.outbound.protection.outlook.com[52.103.23.27]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-northeuropeazolkn19011077.outbound.protection.outlook.com[52.103.32.77]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from mail-norwayeastazolkn19011036.outbound.protection.outlook.com[52.103.51.36]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256

Anonymous TLS connection established from sonic313-20.consmr.mail.ir2.yahoo.com[77.238.179.187]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from sonic303-20.consmr.mail.ir2.yahoo.com[77.238.178.201]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from sonic314-19.consmr.mail.ir2.yahoo.com[77.238.177.145]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

Anonymous TLS connection established from ci-2007i-snip4-11.eps.apple.com[57.103.88.93]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Anonymous TLS connection established from pv-2006g-snip4-3.eps.apple.com[57.103.67.106]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA25

Anonymous TLS connection established from zebra.cherry.relay.mailchannels.net[23.83.223.195]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

manish

@tommyluo said: Seems most of the mail service providers are using TLS 1.3 as long as the recipient server supports it:

Yes, they do. So, you are actively only using TLS 1.3 or better to send/receive via MTA?

tommyluo

No,mine is set to accept all TLS 1.0 ~ TLS 1.3

smtpd_tls_mandatory_protocols = !SSLv3, !SSLv2
smtpd_tls_protocols = !SSLv3, !SSLv2

But in future,maybe will disable TLS 1.0

Adjust to be:
smtpd_tls_mandatory_protocols = !SSLv3, !SSLv2, !TLSv1
smtpd_tls_protocols = !SSLv3, !SSLv2, !TLSv1

tommyluo

But for website under nginx,only accept TLS 1.2 and TLS 1.3

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

manish

@tommyluo said: But in future,maybe will disable TLS 1.0

Hmm. When exactly do you plan to do so for MTA? I hope you use a minimum of ECDHE+AES ciphers.

I also use TLS 1.0...1.3 for MTA, that being said secure defaults only use ciphersuites with FS. Also, I have MTA-STS + SMTP DANE setup.

@tommyluo said: website under nginx,only accept TLS 1.2 and TLS 1.3

Yes, for web server use of ssl_protocols TLSv1.3; should work fine, I guess.

barbarza

@manish said:
TLS 1.0 and 1.1 were officially declared deprecated by the IETF in March 2021.

Google's Gmail still supports TLS 1.0, 1.1 and 3DES (outbound only) for compatibility with legacy systems.

If you ask a lot of seasoned admins, TLS 1.0 looks dead for email, TLS 1.1 is mostly used by scanners and spammers, with some real traffic, but rare. How does everyone feel about removing receive/send support for everything lower than TLS 1.2 currently.

I understand we have enough room to do best TLS magic with IMAPS/submissions or webmail, but when it comes to SMTP/MTA, there is always this feeling to continue to allow TLS 1.0/1.1 for now until the big ESPs start dropping support.

Dear Email Hosting providers:

How many emails have you received/sent with TLS 1.0/1.1 on SMTP/MTA over the period of past 12 months? This will help assess the risk of disabling TLS 1.0/1.1 by August 2026.

What are your thoughts?

Thank you!

It's okay, I've already read all your emails.

manish

@barbarza said: I've already read all your emails