On Mon, May 26, 2025 at 08:47:35PM +0000, Slavko via Exim-users wrote:
> >(HMAC) in TLS in the context of SMTP. There are some browser-specific
> >issues with CBC ciphers because TLS did MAC-then-encrypt rather than
> >encrypt-then-MAC, but these required scripting many connectiosn to
> >possibly leak cookie information. These attacks don't apply to SMTP.
>
> AFAIK 3DES was deprecated (and disallowed after 2023) by NIST.
> I believe, that there is some good reason for that...
The 3DES block size of 64 bits is no longer favoured, performance is not
great, and 112-bit security is frowned upon by nation states that
typically ask for 192-bit security for the more senstive use-cases.
But, there I've seen no practical attacks on 3DES-CBC beyond the generic
CBC mac-then-encrypt issues in browsers.
> >This is a reasonable choice for the *generic* application, which is
> >not doing opportunistic TLS, and possibly shares some of the browser
> >attack surfaces. It is less compelling for SMTP, but with the passage
> >of time, as noted above, the impact of dropping support for TLS 1.0/1.1
> >is becoming insignificant...
>
> I still do not understand one thing: why is as much effort invested
> to advocate old (deprecated) versions of TLS.
The effort is not to "advocate" these, but rather to encourage you to
not go out of your way to spend effort to disable them, in a protocol
where otherwise transmission is acceptable in cleartext.
With sufficiently recent OpenSSL, at the default security level you
get TLS >= 1.2 out of the box. At SECLEVEL=0 you get best effort
security, which is better than no security if you still have clients
that don't support TLS >= 1.2. Increasingly that's no longer a concern,
so your call.
> I understand, that deprecated doesn't mean disallowed, i understand it
> as "awoid if possible".
Which happens automatically when both ends support TLS 1.2 or better.
Again, there's little harm now to explicitly disable the older
protocols, but also little compelling reason to do it.
Do what makes sense to you, and don't worry about it either way, this
is far from your most pressing security concern.
--
Viktor.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
