On 2022-08-03 at 14:33:36 UTC-0400 (Wed, 03 Aug 2022 13:33:36 -0500)
Jarland Donnell via mailop <jarl...@mxroute.com>
is rumored to have said:
Genuine question though: What differentiates a client from a remote
SMTP server besides emotional attachment?
See RFC821. It uses "receiver-SMTP" and "sender-SMTP" rather than
'server' and 'client' but the meaning is identicval. One side of a SMTP
sessioin is a client and the other is a serv er. Absent support for the
obsolete and deprecated TURN command, that relationship is fixed for the
life of a SMTP session.
A remote SMTP server should not be told "This is a secure line" when
it isn't,
And it never is. Nothing ever says "This is a secure line" in TLS. The 2
participants negotiate a specific set of security features. There's no
such thing as a secure/insecure binary.
in just the same way and for the same reasons, that a client shouldn't
be told "This is a secure website" in Firefox when it isn't. By the
very fact alone that a remote SMTP server is connecting to yours over
TLS 1.0 we can reasonably deduce that the person on the other side is
not to be considered to be okay. Either they don't know how to manage
their server
Or the SMTP client is some black box that sends mail a few times a year
when something breaks, and there's no way to update its SSL library.
or they are the victim of a server side downgrade attack.
Are you aware of how such an attack might work in the specific case of a
SMTP client using STARTTLS? Have you given the question any thought?
You can't only react to security you have to be proactive, and just
because I've never seen someone be the victim of a downgrade attack on
a Postfix install doesn't mean that it isn't the best security
practice to protect against that.
Using TLS1.0 with reasonable cipher restrictions is never less secure
than just using plaintext. That is what matters.
Thinking of security as an on/off switch is not useful. Thinking of
security mechanisms as vulnerable/invulnerable is not useful.
Else, why are there even any articles about old versions being
insecure?
To describe the specific vulnerabilities, I suppose. Are you familiar
with them?
Why are there any efforts to remove old TLS versions from every major
software application and operating system?
Because TLS 1.2 and 1.3 have narrower vulnerabilities and stronger
ciphers than older versions. Also because there are attacks against 1.0
which are facilitated by the behavioral model of web browsers and web
servers. Those are infeasible with SMTP.
Are all of these security experts and corporations just playing a game
with TLS versions, or is there perhaps something to this security
practice?
The overwhelming majority of TLS usage is with protocols which have no
mechanism to fall back to plaintext automatically if a TLS session can't
be established. If you're trying to log into a website and the TLS
negotiation fails, your web browser won't retry the failed https URL as
a http URL. A MTA that can't get STARTTLS to work will retry (or even
continue in the same session) without encryption, as it SHOULD per the
standard. That calls for different configuration than a web server or
web browser or any other common use of TLS. Most people managing
TLS-enabled systems don't manage MTAs that talk to the open net, so
generic TLS security advice doesn't always apply to MTAs.
On 2022-08-03 13:16, Bill Cole via mailop wrote:
On 2022-08-03 at 13:37:56 UTC-0400 (Wed, 03 Aug 2022 12:37:56 -0500)
Jarland Donnell via mailop <jarl...@mxroute.com>
is rumored to have said:
If you must divulge your SSN over the phone (for reasons) do you
just
blurt it out at normal volume indifferent to who is around? Or do
you
walk to a secluded corner of the room and cup your hand around the
mouth piece? Even questionable security is better than no security
in
many cases.
No, it isn't. It isn't security at all. If you call someone and tell
them you need their SSN and they ask "Is this a secure line?" If
it's not, you're supposed to say "No." You're not supposed to say
"This is a secure line" and leave unstated the subtext of "If you
didn't do your research to know why this isn't a secure line, it's
your problem." It's on you when you say "Yes" to "Is this secure?"
when it isn't secure.
But that's not at issue with allowing TLS 1.0 and 1.1 in SMTP.
Clients
aren't "told" a session is "secure," they *negotiate* a session's
specific security features in a deterministic manner. Presumably a
client that can't do TLS 1.2 or 1.3 has no expectation of any better
security than they can get with whatever TLS versions they can do.
If you believe that either of those older versions of TLS is as
vulnerable as plain text, please specify why. As far as I am aware,
the only problems with them are inclusion of some weak (but not
trivially so) ciphers by default and attacks that can't work against
a
typical SMTP server.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
