On Mon, 27 Jul 2015 12:53:19 -0700, Török Edwin <ed...@etorok.net> wrote:
Would this be for incoming or outgoing connections?
It's the incoming that I'm primarily concerned with, but that's a good
point to raise. Should the setting effect both directions or be applied
independently?
For incoming connections this would downgrade security, if remote server
uses TLSv1.1 and fails to make a connection to OpenSMTPD (because it
requires TLSv1.2) then it'll fall back to plaintext
which is worse than a hard to exploit vulnerability in TLS.
This argument assumes that incoming plaintext connections are accepted,
which I am completely aware is the default. I've been forcing inbound TLS
via the tls-require option for over a year now with no complaints.
For outgoing connections you could require tls always, but I'm not sure
thats realistic yet if you actually want to deliver mail, and if you're
not careful it might cause plaintext fallbacks.
Just looking at my personal mail server I have roughly:
smtp-in:
TLSv1/SSLv3 (TLSv1.2) 63%
TLSv1/SSLv3 (SSLv3) 24%
TLSv1/SSLv3 () 7%
plaintext (proto=SMTP) 6%
If I reject SSLv3, TLSv1 and 1.1 I'd have:
TLSv1.2 63%
plaintext 37%
The SSLv3 seems to come from public mailing list servers.
smtp-out:
TLSv1/SSLv3 (TLSv1.2) 96%
TLSv1/SSLv3 () 4%
I wouldn't be opposed to deprecating SSLv3, but what is the right way to
do that without breaking mail deliverability or causing plaintext
fallbacks?
Perhaps you could accept the connection and reject immediately with an
SMTP error code and a message describing the problem?
Basically, I want to force TLSv1.2 in both directions, plaintext is always
verboten, and if the other party doesn't support it, that's their problem,
I'm prepared to do without.
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
