A generic "confirmation of a secure connection" is not a part of any
MTA-MTA interaction.
I mean if our standard is so high that it needs to be a flashing neon
sign then neither does a web browser or any other piece of software. I
cannot believe that I am in a mailing list full of professional admins
that is universally speaking up on this topic to ONLY state that there
is zero merit to a best security practice of disallowing insecure SSL
protocols and ciphers for communication between servers. I'd be torn a
new one and have a reddit thread ripping into me for the mere suggestion
of what seems to be universal agreement here (assuming from lack of
diversity of opinion).
Either allowing an end user to negotiate a secure connection, to which
their software absolutely acknowledges it as a secure connection, is
either sane or it isn't. Ignore the protocol. Ignore the software.
Either it's sane to shake hands and agree that a connection is secure,
when it isn't, or it's not.
And why are the people on this mailing list so scared to let things fall
back to plain text? It's still how surely the vast majority of email is
done. If we're agreeing that insecure SSL is sane and that it's safe as
long as the two servers trust each other, completely ignoring upstreams
in between as seems to be the agreed upon philosophy in this discussion,
then there's no harm in them transmitting to each other in plain text.
If there's no one listening in that can capture plain text traffic and
compromise your security, then there's no harm in plain text SMTP
transactions. If there is ANY danger of those things at all, then the
false sense of security by acknowledging a secure transaction using
insecure protocols/ciphers is at best equivalent. To walk away feeling
better about an exploitable packet than a plain text packet doesn't make
sense, either the information transmitted is secure or it isn't. If it
isn't transmitted using a secure protocol/cipher, then it isn't secure.
If you wouldn't transmit it over plain text but you would transmit it
over TLS 1.0, your logic is simply not justifiable.
On 2022-08-03 18:22, Bill Cole via mailop wrote:
On 2022-08-03 at 17:32:56 UTC-0400 (Wed, 03 Aug 2022 16:32:56 -0500)
Jarland Donnell via mailop <jarl...@mxroute.com>
is rumored to have said:
Firefox does not speak MTA, so you are talking about a completely
different problem. MTA is oportunistic TLS, web is required TLS.
Are equivalencies a bad thing though?
Only if you are saying things like 2+2=5, as in this case.
I'm talking about a general acceptance of the idea that a user should
not be given a false sense of security by being presented with
confirmation of a secure connection when it isn't secure.
A generic "confirmation of a secure connection" is not a part of any
MTA-MTA interaction.
Both the client and server *negotiate* security mechanisms to a common
ground of overall TLS version and ciphersuite. They AGREE on the
specific details of their security. And in any case, a TLSv1.0 session
using a good ciphersuite is no less secure for SMTP than a TLSv1.3
session using the same ciphersuite.
I shouldn't have to hold back from using similar situations in
illustrations simply because they're not a 1:1 match in irrelevant
ways.
The fact that SMTP is supposed to fall back to plaintext automatically
when STARTTLS fails is entirely relevant to whether you allow TLS
versions that are not inherently unsafe when used with SMTP.
The relevancy as pointed out in my words remains, stripping end users
from any connection to the technical details of a mail server is to be
completely ignorant of the exceptional growth of individual mail
server administrators who need guidance and rely on a sane industry to
perform sane activities around them.
Oh... I'm so sorry to have to break it to you, but I have bad news...
Email is messy and imperfect and largely run by people and orgs whose
behavior is not well-described by the word "sane."
Telling them "no" when it isn't sane to tell them yes is sane
behavior. If it isn't, then telling any end user anywhere at any time
using any application "no" instead of "You have a secure connection"
under any any every circumstance including ones in which the
connection is in fact not secure, would be equally as insane
regardless of their choice in protocol.
How is that in any way relevant to the use of TLSv1.0 between MTAs
speaking SMTP?
There is no end user involved. There is no "You have a secure
connection" assertion by either side except for a mutual agreement on
which specific ciphers and protocols to use. When STARTTLS fails in
SMTP, there may not even be a new connection made before the client
goes ahead in plaintext.
The government wire tapping the upstream provider to catch your
packets isn't going to say "Oh this is SMTP, I'm not supposed to touch
it." There's no universal bro code to leave SMTP alone and only spy on
HTTP activity.
That's really not it.
Catching packets and analyzing them is not all that is involved in
compromising a TLSv1.0 or 1.1 session. All of the attacks I am aware
of require the ability to elicit a lot of repeated or predictable
traffic between server and client on one session. This can be feasible
when the underlying protocol is HTTP, but is not feasible with SMTP.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
