There's nothing that requires you to log a TLS 1.0/1.1 connection as
being secure. You could choose to log it as if it were plaintext. It's
likely to be logged with the protocol and cipher information.
What you log it as isn't as important as what the other party logs it
as. Sure if it were within spec to be able to return a message that the
other MTA logs as "Secure but not really secure" that would be a great
middle ground, the problem is that the other MTA accepts it and logs it
as secure, and by virtue of the transaction happening at all we can
pretty well assume that it doesn't fall within the intentions of the
other party. After all, if they didn't want secure email it was much
easier to not. If they did, and they're doing so insecurely, that is a
problem. That it is their problem alone goes back to the whole reasoning
behind the basic security practices of removing insecure
protocols/ciphers be it client or server level, the existence of the
connection shows that the other party is either compromised or
incapable. At that point the same risks exist as they would for an end
user visiting a secure site with Firefox, who fully understands their
duty to not show that lock icon when it isn't really secure.
Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.
And again, this is where the basic security practice comes in. If that
logic was sound, then it is a travesty that software and OS developers
have removed old SSL protocols and ciphers, is it not? Why did they
remove them? I'm not trying to lean on them to say "They did it so it's
the way." I'm trying to add legitimacy to say "I'm not just some crazy
guy shouting from the corner, look at how many respected people
understand why allowing insecure protocols and ciphers is a bad security
practice." The most reasonable sounding counter point being that they
are servers, not clients. But I think that falls apart pretty quickly
when the server is Bob's DigitalOcean MailInABox turnkey appliance.
Running a mail server doesn't mean you always make informed choices, or
that you're always aware of risks, in the same way that a desktop user
staring at their web browser can't be expected to always be informed or
aware of all risk either.
Anyway, good topic.
On 2022-08-03 14:02, Simon Arlott via mailop wrote:
On 03/08/2022 16:46, Jarland Donnell via mailop wrote:
It's a pretty big and well respected security practice to consider
plain
text to be more secure than insecure SSL for one reason: A plain text
connection isn't logged or reported as a secure connection. Both being
There's nothing that requires you to log a TLS 1.0/1.1 connection as
being secure. You could choose to log it as if it were plaintext. It's
likely to be logged with the protocol and cipher information.
insecure, only one of the two involves your server negotiating and
reporting to the third party that you are accepting it over a secure
Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.
connection. Which is basically a lie. Plain isn't a lie, and that's
worth something.
Having said that, I'm currently accepting TLS 1.0/1.1 connections as a
server with a restricted cipher list but requiring TLS 1.2 as a client
(which will then fallback to plaintext).
Cipher selection is another issue... I have come across one
organisation
that had configured their TLS-only servers to only support the x25519
curve when using ECDHE - and my cipher configuration requires
DHE/ECDHE.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
