Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Sat, Aug 14, 2021 at 10:47:08AM -0400, Viktor Dukhovni 
 wrote:

> > On 14 Aug 2021, at 1:15 am, raf  wrote:
> > 
> > According to the hardenize.com security bingo site,
> > they get a green box for their mail server TLS, even
> > though they support TLSv1.0 (yellow), because they
> > don't support anonymous ciphers (red). If they were
> > supporting anonymous ciphers, it would get a
> > yellow/amber box overall.
> > 
> >  https://www.hardenize.com/report/rhenus.com
> 
> I should ping Ivan Ristic and ask him to change that policy.  It
> is counterproductive.  See:
> 
>   https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

That would be good. He might listen to you. Any reduction in
silly security theatre in the world is welcome.

> If you're not obligated by some regulatory requirement to have "green"
> checkmarks from a counterproductively strict TLS stack audit, leave
> "aNULL" ciphers enabled when doing unauthenticated opportunistic TLS.
> 
> Slinging unused certificates around adds nothing to your security.

I suppose being anti-anonymous ciphers makes sense for the web,
and then they misapplied that stance to mail.

> > Anonymous ciphers would be supported by default.
> 
> Postfix supports these by default, most other applications do not,
> as they're not part of the "DEFAULT" cipherlist in OpenSSL.

Thanks.

> > So maybe they stopped supporting them.
> 
> Perhaps they did explicitly turn off "aNULL", or they're not using Postfix.

It's probably more likely that they're not using Postfix.
Then the theory becomes: They did nothing. :-)

> -- 
>   Viktor.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

> On 14 Aug 2021, at 1:15 am, raf  wrote:
> 
> According to the hardenize.com security bingo site,
> they get a green box for their mail server TLS, even
> though they support TLSv1.0 (yellow), because they
> don't support anonymous ciphers (red). If they were
> supporting anonymous ciphers, it would get a
> yellow/amber box overall.
> 
>  https://www.hardenize.com/report/rhenus.com

I should ping Ivan Ristic and ask him to change that policy.  It
is counterproductive.  See:

  https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

If you're not obligated by some regulatory requirement to have "green"
checkmarks from a counterproductively strict TLS stack audit, leave
"aNULL" ciphers enabled when doing unauthenticated opportunistic TLS.

Slinging unused certificates around adds nothing to your security.

> Anonymous ciphers would be supported by default.

Postfix supports these by default, most other applications do not,
as they're not part of the "DEFAULT" cipherlist in OpenSSL.

> So maybe they stopped supporting them.

Perhaps they did explicitly turn off "aNULL", or they're not using Postfix.

-- 
Viktor.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Fri, Aug 13, 2021 at 04:20:59PM +0200, Josh Good 
 wrote:

> Hello, to follow up on this issue regarding Rhenus.com and TLS 1.2,
> I confirm that mail flow to them without using the STARTTLS verb in the
> SMTP transaction, is working fine. So it looks like plain text SMTP is
> still allowed by their publicly-referenced SMTP servers.
> 
> So at first sight it looks like Viktor's interpretation of Rhenus'
> communication was right.

Yes, doing what they actually seemed to be saying would
have been a disaster waiting for a quick rollback. They
couldn't've really meant what they said.

> However, upon further inspection, it appears that the publicly-referenced
> SMTP servers of Rhenus.com are still supporting TLS 1.0, which could be
> read as they not following through with their original notice of only
> supporting TLS 1.2 in SMTP from August 1st onwards.

> [...]
> 
> Perhaps they re-evaluated their decision and are keeping TLS 1.0 for
> SMTP? Who knows!
> 
> Regards,
> -- 
> Josh Good

According to the hardenize.com security bingo site,
they get a green box for their mail server TLS, even
though they support TLSv1.0 (yellow), because they
don't support anonymous ciphers (red). If they were
supporting anonymous ciphers, it would get a
yellow/amber box overall.

  https://www.hardenize.com/report/rhenus.com

Anonymous ciphers would be supported by default.
So maybe they stopped supporting them.
Or maybe they didn't support them earlier either,
and they haven't actually done anything.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Josh Good]

On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:
> 
> 
> > On 29 Jul 2021, at 8:17 am, raf  wrote:
> > 
> > The Rhenus email did say:
> > 
> >  "...must be sent with the TLS 1.2 protocol or higher.
> >  Any mail received without fulfilling this condition
> >  will be rejected by our server."
> > 
> > That second sentence sounds to me like a definite
> > statement that an SMTP connection that doesn't initiate
> > STARTTLS will not be able to send email. At least, I
> > can't see how else to interpret those words.
> 
> The simplest thing they could do is just disable TLS 1.0.
> This would also comply with some brain in neutral audit.
> 
> My money is on brain in neutral, as opposed to a carefully
> considered risk assessment in which they've concluded that
> they only receive legitimate email from TLS-1.2-capable
> senders.  I may be wrong in this case, but my "b[ae]tting
> average" would generally be quite high in general.
> 
> So expect a poorly thought out simple TLS policy, rather
> than a carefully considered comprehensive policy.

Hello, to follow up on this issue regarding Rhenus.com and TLS 1.2,
I confirm that mail flow to them without using the STARTTLS verb in the
SMTP transaction, is working fine. So it looks like plain text SMTP is
still allowed by their publicly-referenced SMTP servers.

So at first sight it looks like Viktor's interpretation of Rhenus'
communication was right.

However, upon further inspection, it appears that the publicly-referenced
SMTP servers of Rhenus.com are still supporting TLS 1.0, which could be
read as they not following through with their original notice of only
supporting TLS 1.2 in SMTP from August 1st onwards.


If, from a TLS 1.0-only host I run this command, I get this:

$ openssl s_client -connect mx-in2.de.rhenus.com:25 -starttls smtp
(...snip...)
fnyzu7HSqPgBNKe6kmjaWNFZOdfopGvl7wEjU84NsL8y3rZ3gYm5WGtyw92ryWLj
pWIMifIkDTXFMOivRPW2p+29gkXBhl3mGlLlBGrmpKr8yjRfvDZDXi8SzHsMPECX
tTS3eAqF8viudEmzB7OqRyyICi3wlH8em7hOVwsPpxU=
-END CERTIFICATE-
subject=/CN=*.de.rhenus.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte TLS RSA CA G1
---
No client certificate CA names sent
---
SSL handshake has read 4658 bytes and written 478 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES128-SHA
Session-ID: B047DEA0C1366F7D150DA86F0FB28E04FA41F7E54CE70391E8EFE2F864BDB80E
Session-ID-ctx:
Master-Key: 
3517C702197323871960E7819DC37A576F80A4FB11A80C6EC2F71B8D9256B4BF799C6509DA7DCD26D3EAE033FAAE2A34
Key-Arg   : None
Start Time: 1628863962
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
220 mx-in2.de.rhenus.com ESMTP
421 Exceeded allowable connection time, disconnecting.
closed

---> Which means they are still supporting TLS 1.0 in SMTP.


And if I issue that same command from a TLS 1.2-supporting host, I get:

$ openssl s_client -connect mx-in2.de.rhenus.com:25 -starttls smtp
(...snip...)
fnyzu7HSqPgBNKe6kmjaWNFZOdfopGvl7wEjU84NsL8y3rZ3gYm5WGtyw92ryWLj
pWIMifIkDTXFMOivRPW2p+29gkXBhl3mGlLlBGrmpKr8yjRfvDZDXi8SzHsMPECX
tTS3eAqF8viudEmzB7OqRyyICi3wlH8em7hOVwsPpxU=
-END CERTIFICATE-
subject=CN = *.de.rhenus.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA 
G1
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4485 bytes and written 481 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
Session-ID: FB20C4A6328728D31B5BEB618879C67F33C9BFA8BF51CFC686D3B5EEEBFF51A7
Session-ID-ctx:
Master-Key: 
CC8AA3D2CCEB7F7873CC6C8252210216E93CD74F55F6E0AFCC5FAAB81C707AADEADC0D07AC17F94ACE546D264CD260D2
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 61 d1 9e cc d6 ab 6a 48-e9 ba f9 1c b2 1a 57 05   a.jH..W.
0010 - ce 9f e4 f8 d7 42 48 52-2e 55 ff 1b ee d7 6b a9   .BHR.Uk.
0020 - fa 2d 41 a6 8a f3 a5 70-5e ef 0d 1c f9 93 8a de   .-Ap^...
0030 - f7 ed 04 b4 d2 34 b3 e3-65 bd 82 c4 03 cb 69 c1   .4..e.i.
0040 - fc 3f 3d 33 17 6f 59 b6-82 ac 77 f3 c1 6c 9e 68   .?=3.oY...w..l.h
0050 - d6 1e 73 e9 76 24 3a 18-40 00 6d 97 0b 86 95 9b   ..s.v$:.@.m.
0060 - 20 a4 f6 d0 2a d1 ed 17-9f 78 5c 7c 2b 04 89 3b...*x\|+..;
0070 - dc ea 6d d5 d9 28 52 67-35 11 43 2e 51 f4 f5 0f   ..m..(Rg5.C.Q...
0080 - 36 4e 89 8a 81 79 8c f1-50 c0 dd ec aa 66 26 ec   6N...y..Pf&.
0090 - fa de 54 3c 1a fe 05 68-12 2c ae 17 6a f0 20 2b   ..T<...h.,..j. +
00a0 - d2 ba 0a 9a a8 

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Wietse Venema]

Sean McBride:
> On Thu, 29 Jul 2021 22:17:49 +1000, raf said:
> 
> >That second sentence sounds to me like a definite
> >statement that an SMTP connection that doesn't initiate
> >STARTTLS will not be able to send email. At least, I
> >can't see how else to interpret those words.
> 
> Which is an odd thing considering, according to hardenize.com, they don't 
> support any of: DMARC, DNSSEC, DANE, MTA-TLS, or TLS-RPT:
> 
> 
> 
> You'd think those would be higher up any checklist...

It does not matter if it is secure. It matters if the box is checked.

Wietse

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Sean McBride]

On Thu, 29 Jul 2021 22:17:49 +1000, raf said:

>That second sentence sounds to me like a definite
>statement that an SMTP connection that doesn't initiate
>STARTTLS will not be able to send email. At least, I
>can't see how else to interpret those words.

Which is an odd thing considering, according to hardenize.com, they don't 
support any of: DMARC, DNSSEC, DANE, MTA-TLS, or TLS-RPT:



You'd think those would be higher up any checklist...

Sean

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Erwan David]

Le 29/07/2021 à 18:46, Dominic Raferd a écrit :
> Some commercial vulnerability scan services (e.g. by Qualys,
> SecurityMetrics) which are required by payment providers regard
> TLSv1/TLSv1.1 as absolute fails for PCI DSS compliance and
> organisations that must meet PCI DSS
> (https://www.pcisecuritystandards.org/) have no choice but to respect
> this. The same services do not treat port 25 open for plain text as a
> fail.
>
Putting your email in the PCI-DSS protected domain is also a rather bold
move...

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

> On 29 Jul 2021, at 12:46 pm, Dominic Raferd  wrote:
> 
> Some commercial vulnerability scan services (e.g. by Qualys, SecurityMetrics) 
> which are required by payment providers regard TLSv1/TLSv1.1 as absolute 
> fails for PCI DSS compliance and organisations that must meet PCI DSS 
> (https://www.pcisecuritystandards.org/) have no choice but to respect this. 
> The same services do not treat port 25 open for plain text as a fail.

In other words: brain in neutral commercial reality.

-- 
Viktor.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Dominic Raferd]

On 29/07/2021 17:24, Josh Good wrote:

On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:

On 29 Jul 2021, at 8:17 am, raf  wrote:

The Rhenus email did say:

  "...must be sent with the TLS 1.2 protocol or higher.
  Any mail received without fulfilling this condition
  will be rejected by our server."

That second sentence sounds to me like a definite
statement that an SMTP connection that doesn't initiate
STARTTLS will not be able to send email. At least, I
can't see how else to interpret those words.

The simplest thing they could do is just disable TLS 1.0.
This would also comply with some brain in neutral audit.

My money is on brain in neutral, as opposed to a carefully
considered risk assessment in which they've concluded that
they only receive legitimate email from TLS-1.2-capable
senders.

Well, there is also the third option, the kamikaze approach: we're
disabling TLS 1.0, and while we are at it we will also disable this
"backdoor" we just found of "plain text" connections to our world-facing
SMTP servers... Risk assessments?, what are those? This is security!
Some commercial vulnerability scan services (e.g. by Qualys, 
SecurityMetrics) which are required by payment providers regard 
TLSv1/TLSv1.1 as absolute fails for PCI DSS compliance and organisations 
that must meet PCI DSS (https://www.pcisecuritystandards.org/) have no 
choice but to respect this. The same services do not treat port 25 open 
for plain text as a fail.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Josh Good]

On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:
> > On 29 Jul 2021, at 8:17 am, raf  wrote:
> > 
> > The Rhenus email did say:
> > 
> >  "...must be sent with the TLS 1.2 protocol or higher.
> >  Any mail received without fulfilling this condition
> >  will be rejected by our server."
> > 
> > That second sentence sounds to me like a definite
> > statement that an SMTP connection that doesn't initiate
> > STARTTLS will not be able to send email. At least, I
> > can't see how else to interpret those words.
> 
> The simplest thing they could do is just disable TLS 1.0.
> This would also comply with some brain in neutral audit.
> 
> My money is on brain in neutral, as opposed to a carefully
> considered risk assessment in which they've concluded that
> they only receive legitimate email from TLS-1.2-capable
> senders.

Well, there is also the third option, the kamikaze approach: we're
disabling TLS 1.0, and while we are at it we will also disable this
"backdoor" we just found of "plain text" connections to our world-facing
SMTP servers... Risk assessments?, what are those? This is security!

-- 
Josh Good

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

> On 29 Jul 2021, at 8:17 am, raf  wrote:
> 
> The Rhenus email did say:
> 
>  "...must be sent with the TLS 1.2 protocol or higher.
>  Any mail received without fulfilling this condition
>  will be rejected by our server."
> 
> That second sentence sounds to me like a definite
> statement that an SMTP connection that doesn't initiate
> STARTTLS will not be able to send email. At least, I
> can't see how else to interpret those words.

The simplest thing they could do is just disable TLS 1.0.
This would also comply with some brain in neutral audit.

My money is on brain in neutral, as opposed to a carefully
considered risk assessment in which they've concluded that
they only receive legitimate email from TLS-1.2-capable
senders.  I may be wrong in this case, but my "b[ae]tting
average" would generally be quite high in general.

So expect a poorly thought out simple TLS policy, rather
than a carefully considered comprehensive policy.

-- 
Viktor.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Thu, Jul 29, 2021 at 09:13:39AM +0200, Josh Good 
 wrote:

> Well, it's not exactly clear, in the Rhenus notification, whether they
> are just disabling TLS 1.0, or that plus also disabling plain text SMTP.
> 
> Viktor thinks it's just the first case. But we should not underestimate
> the push that a checklist-based security audit can exert on an
> overburdened IT Dept.
> 
> I will find out for sure on the first of August, or the following days,
> for if they (Rhenus) disable plain text SMTP in their publicly-referenced
> SMTP servers, PAIN will ensue and my urgent intervention will probably
> be requested to "fix" things...
> 
> Regards,
> Josh Good

The Rhenus email did say:

  "...must be sent with the TLS 1.2 protocol or higher.
  Any mail received without fulfilling this condition
  will be rejected by our server."

That second sentence sounds to me like a definite
statement that an SMTP connection that doesn't initiate
STARTTLS will not be able to send email. At least, I
can't see how else to interpret those words.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Thu, Jul 29, 2021 at 10:37:46AM +0200, Matus UHLAR - fantomas 
 wrote:

> On 29.07.21 10:26, raf wrote:
> 
> > On my little personal mail server, 75% of incoming
> > connections to port 25 are plaintext. Only 25% use
> > STARTTLS (by definition). Disabling STARTTLS would
> > be a disaster, and stop all incoming mail.
> 
> you apparently mean:
> 
> "Requiring STARTTLS would be a disaster, and stop 75% of incoming mail"

No, but I can see why you think I meant that. I didn't
express myself well there. Sorry about that. But the
sentence before the above quote was "Disabling
plaintext/STARTTLS SMTP would be courageous".

The conversation was about whether or not STARTTLS was
being phased out (presumably in favour of TLS-only
connections). The suggestion was partly based on the
fact that the original RFC for STARTTLS had been
obsoleted. I was pointing out that that RFC was only
obsoleted because there was a new RFC that replaced it.
STARTTLS (as used with ports 25 and 587) isn't going
away. It can't be replaced by TLS-only (as used with
port 465) connections for various reasons, not least of
which is that port 25 won't going away, and it will
never change to be TLS-only. Although, as Viktor
pointed out, it might eventually change to be plaintext
followed by mandatory STARTTLS. Apologies for my lack
of clarity.

Having said that, requiring STARTTLS right now might
well cause a loss of much incoming mail. It would in my
case. But presumably, Rhenus have analysed their
incoming email connections, and are satisfied that it
won't harm their business. :-)

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Jaroslaw Rafa]

Dnia 29.07.2021 o godz. 12:26:49 Tobi pisze:
> 
> Just take the case when they loose a huge customer order because
> customer still operates an Exchange 2003 server, which by best can talk
> TLS 1.0. Then Management will soon show up in IT department and highly
> probably ignore the fact that it was them pushing this policy in first
> place ;-)

The management will probably present the whole case as being "goal-driven".
Currently, their goal is to be compliant with some security guidelines (that
they don't understand, they just want to blindly fulfill them), so they do
everything to reach that goal. When they will be unable to communicate with
the customer, they will have a next goal, to "adapt to their customer needs"
and they will restore the functionality they have previously turned off to
be able to reach that next goal. Plus, they will now have a formal business
justification to be not compliant with the mentioned security guidelines -
because they will be unable to communicate with their customers if they
comply.

That's just how the corporate bureaucracy works...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Tobi]

Josh,

On 7/29/21 9:13 AM, Josh Good wrote:
> Well, it's not exactly clear, in the Rhenus notification, whether they
> are just disabling TLS 1.0, or that plus also disabling plain text SMTP.
>
> Viktor thinks it's just the first case. But we should not underestimate
> the push that a checklist-based security audit can exert on an
> overburdened IT Dept.


I bet a beer that they're going the second path: enforce TLS1.2 +
disabling plain text SMTP. Although I think this is not a good idea imho
the first path (enforcing TLS1.2 but still keeping plain) is just plain
stupid ;-) They would not gain anything by doing so, because imho a
TLS1.0 connection is better than a fallback on plain. Do not get me
wrong I think it's a good idea to push towards using only strong TLS
versions/ciphers but the implementation may cause far more problems than
expected.

Just take the case when they loose a huge customer order because
customer still operates an Exchange 2003 server, which by best can talk
TLS 1.0. Then Management will soon show up in IT department and highly
probably ignore the fact that it was them pushing this policy in first
place ;-)

Cheers


tobi




OpenPGP_signature
Description: OpenPGP digital signature

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Matus UHLAR - fantomas]

On Wed, Jul 28, 2021 at 04:39:39PM +0200, Josh Good 
 wrote:


Hello everybody.

I've been made aware of this communication recently received at some
site whose email is managed on-premises (i.e., not outsourced to any
big mailbox provider in the "cloud"):

> From: Rhenus Logistics 
> Sent: 30 June 2021 17:05
> To: [omitted]
> Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
>
> Good Afternoon,
> We inform you that due to Rhenus security policies, as of 08/01/2021
> receiving of emails that do not comply with version 1.2 of the TLS
> protocol will be restricted.
> All emails sent in particular to the domain @es.rhenus.com and in
> general to any Rhenus domain @*.rhenus.com must be sent with the TLS
> 1.2 protocol or higher.
> Any mail received without fulfilling this condition will be rejected
> by our server.
> Please forward this message to your IT department for consideration
> and action.
> If you have any questions, please head over your Rhenus contact
>
> IT //SERVICES

The above could mean that starting 08/01/2021 their TLS support will
only support TLS 1.2 (and not any earlier TLS version) with their
inbound SMTP servers remaining configured in "opportunistic TLS" mode
--- or it could be read as if they will enable "smtpd_enforce_tls = yes"
(or "smtpd_tls_security_level = encrypt") in their inbound SMTP servers
(I don't know if they are using Postfix, but you get what I mean).

If the case is the second one, is that a current trend? Has rfc2487
been obsoleted and mandatory TLS is now considered "industry standard"
in publicly-referenced SMTP server?

I've tried to contact Rhenus IT Services to inquire about this, but my
phone calls haven't gone through. So I thought I may as well ask this
list if this a single case or the "new normal"...


On 29.07.21 10:26, raf wrote:

RFC2487 has been obsoleted, but only because it's been
replaced by RFC3207, and then further updated by
RFC7817. It hasn't gone away. It's just been updated.


note that both 2487 and 3207 just describe how to upgrade from plaintext to
TLS connection. They don't describe if/when to upgrade and what to do if the
upgrade is not possible (or fails)


On my little personal mail server, 75% of incoming
connections to port 25 are plaintext. Only 25% use
STARTTLS (by definition). Disabling STARTTLS would
be a disaster, and stop all incoming mail.


you apparently mean: 


"Requiring STARTTLS would be a disaster, and stop 75% of incoming mail"


I'm sure that Rhenus will still use STARTTLS on port
25. They'll just require STARTTLS to be used and
they'll only support TLSv1.2+. The only alternative
would be to close port 25, use port 465 (TLS-only)
instead, and hope that all mail servers that want to
send them email try to use port 465. But that's not
going to happen.


many of mailservers refuse unauthenticated mail on port 465, so this is
no-go.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #9: Out of error messages.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Josh Good]

On 2021 Jul 29, 15:48, raf wrote:
> On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni 
>  wrote:
> 
> > On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> > 
> > > And similarly, port 25 will never be TLS-only. STARTTLS
> > > isn't going away.
> > 
> > I am less certain that public Internet SMTP will not in the next decade
> > or two switch to STARTTLS required.
> 
> The Rhenus email makes it look like that transition is starting.
> 

Well, it's not exactly clear, in the Rhenus notification, whether they
are just disabling TLS 1.0, or that plus also disabling plain text SMTP.

Viktor thinks it's just the first case. But we should not underestimate
the push that a checklist-based security audit can exert on an
overburdened IT Dept.

I will find out for sure on the first of August, or the following days,
for if they (Rhenus) disable plain text SMTP in their publicly-referenced
SMTP servers, PAIN will ensue and my urgent intervention will probably
be requested to "fix" things...

Regards,

-- 
Josh Good

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Eero Volotinen]

Sounds like requirement from some security audit..

Eero

On Thu, Jul 29, 2021 at 8:49 AM raf  wrote:

> On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni <
> postfix-us...@dukhovni.org> wrote:
>
> > On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> >
> > > And similarly, port 25 will never be TLS-only. STARTTLS
> > > isn't going away.
> >
> > I am less certain that public Internet SMTP will not in the next decade
> > or two switch to STARTTLS required.
> >
> > --
> > Viktor.
>
> The Rhenus email makes it look like that transition is starting.
>
> cheers,
> raf
>
>

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni 
 wrote:

> On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> 
> > And similarly, port 25 will never be TLS-only. STARTTLS
> > isn't going away.
> 
> I am less certain that public Internet SMTP will not in the next decade
> or two switch to STARTTLS required.
> 
> -- 
> Viktor.

The Rhenus email makes it look like that transition is starting.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:

> Yes. That's why I said "But that's not going to happen".
> And similarly, port 25 will never be TLS-only. STARTTLS
> isn't going away.

I am less certain that public Internet SMTP will not in the next decade
or two switch to STARTTLS required.

-- 
Viktor.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Wed, Jul 28, 2021 at 09:21:22PM -0400, Viktor Dukhovni 
 wrote:

> On Thu, Jul 29, 2021 at 10:26:09AM +1000, raf wrote:
> 
> > The only alternative would be to close port 25, use port 465
> > (TLS-only) instead, 
> 
> This profoundly confuses the SMTP (relay) protocol with the 
> SUBMIT protocol.  MTAs won't EVER send on port 465 or 587.
> 
> -- 
> Viktor.

Yes. That's why I said "But that's not going to happen".
And similarly, port 25 will never be TLS-only. STARTTLS
isn't going away.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

On Thu, Jul 29, 2021 at 10:26:09AM +1000, raf wrote:

> The only alternative would be to close port 25, use port 465
> (TLS-only) instead, 

This profoundly confuses the SMTP (relay) protocol with the 
SUBMIT protocol.  MTAs won't EVER send on port 465 or 587.

-- 
Viktor.

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[raf]

On Wed, Jul 28, 2021 at 04:39:39PM +0200, Josh Good 
 wrote:

> Hello everybody.
> 
> I've been made aware of this communication recently received at some
> site whose email is managed on-premises (i.e., not outsourced to any
> big mailbox provider in the "cloud"):
> 
> > From: Rhenus Logistics  
> > Sent: 30 June 2021 17:05
> > To: [omitted]
> > Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
> >  
> > Good Afternoon,
> > We inform you that due to Rhenus security policies, as of 08/01/2021
> > receiving of emails that do not comply with version 1.2 of the TLS 
> > protocol will be restricted.
> > All emails sent in particular to the domain @es.rhenus.com and in 
> > general to any Rhenus domain @*.rhenus.com must be sent with the TLS 
> > 1.2 protocol or higher.
> > Any mail received without fulfilling this condition will be rejected 
> > by our server.
> > Please forward this message to your IT department for consideration 
> > and action.
> > If you have any questions, please head over your Rhenus contact
> >  
> > IT //SERVICES
> 
> The above could mean that starting 08/01/2021 their TLS support will
> only support TLS 1.2 (and not any earlier TLS version) with their
> inbound SMTP servers remaining configured in "opportunistic TLS" mode
> --- or it could be read as if they will enable "smtpd_enforce_tls = yes"
> (or "smtpd_tls_security_level = encrypt") in their inbound SMTP servers
> (I don't know if they are using Postfix, but you get what I mean).
> 
> If the case is the second one, is that a current trend? Has rfc2487
> been obsoleted and mandatory TLS is now considered "industry standard"
> in publicly-referenced SMTP server?
> 
> I've tried to contact Rhenus IT Services to inquire about this, but my
> phone calls haven't gone through. So I thought I may as well ask this
> list if this a single case or the "new normal"...
> 
> Regards,
> 
> -- 
> Josh Good

Hi,

RFC2487 has been obsoleted, but only because it's been
replaced by RFC3207, and then further updated by
RFC7817. It hasn't gone away. It's just been updated.

Disabling plaintext/STARTTLS SMTP would be courageous. :-)
On my little personal mail server, 75% of incoming
connections to port 25 are plaintext. Only 25% use
STARTTLS (by definition). Disabling STARTTLS would
be a disaster, and stop all incoming mail.

Of my incoming TLS connections, almost none of them are
TLSv1.0 and none are TLSv1.1. It the past month, the
numbers are:

  TLSv1.0 6
  TLSv1.1 0
  TLSv1.2 21902
  TLSv1.3 4334

And the TLSv1.0 connections were all attempts at spam.
Disabling TLSv1.0 and TLSv1.1 is probably mostly
harmless, and they have been deprecated (RFC8996). At
least, nobody will lose their job for disabling TLSv1.0
and TLSv1.1. :-)

But the known flaws have been mitigated, so it doesn't
actually matter (yet). But if any other flaw is
discovered, I wouldn't expect it to be fixed. So
leaving TLSv1.0 active means accepting the
responsibility of keeping an eye out for the next flaw
to be published, and disabling it then.

I'm sure that Rhenus will still use STARTTLS on port
25. They'll just require STARTTLS to be used and
they'll only support TLSv1.2+. The only alternative
would be to close port 25, use port 465 (TLS-only)
instead, and hope that all mail servers that want to
send them email try to use port 465. But that's not
going to happen.

cheers,
raf

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Tobi]

Hi


imho this is a single case. Enforcing TLS on a public faced smtp port
makes no sense to me. Except if you want to reject quite a bunch of mail :-)
Sure TLS encrypted connections are preferable but to enforce it on an
incoming smtp server is sportive. They would better leave smtpd
encryption on may and deploy a proper DANE setup instead.

Sure it's their servers so their rules applies. Everyone is allowed to
shot own foot ;-)

Cheers

tobi

On 7/28/21 4:39 PM, Josh Good wrote:
> Hello everybody.
>
> I've been made aware of this communication recently received at some
> site whose email is managed on-premises (i.e., not outsourced to any
> big mailbox provider in the "cloud"):
>
>> From: Rhenus Logistics  
>> Sent: 30 June 2021 17:05
>> To: [omitted]
>> Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
>>  
>> Good Afternoon,
>> We inform you that due to Rhenus security policies, as of 08/01/2021
>> receiving of emails that do not comply with version 1.2 of the TLS 
>> protocol will be restricted.
>> All emails sent in particular to the domain @es.rhenus.com and in 
>> general to any Rhenus domain @*.rhenus.com must be sent with the TLS 
>> 1.2 protocol or higher.
>> Any mail received without fulfilling this condition will be rejected 
>> by our server.
>> Please forward this message to your IT department for consideration 
>> and action.
>> If you have any questions, please head over your Rhenus contact
>>  
>> IT //SERVICES
>
> The above could mean that starting 08/01/2021 their TLS support will
> only support TLS 1.2 (and not any earlier TLS version) with their
> inbound SMTP servers remaining configured in "opportunistic TLS" mode
> --- or it could be read as if they will enable "smtpd_enforce_tls = yes"
> (or "smtpd_tls_security_level = encrypt") in their inbound SMTP servers
> (I don't know if they are using Postfix, but you get what I mean).
>
> If the case is the second one, is that a current trend? Has rfc2487
> been obsoleted and mandatory TLS is now considered "industry standard"
> in publicly-referenced SMTP server?
>
> I've tried to contact Rhenus IT Services to inquire about this, but my
> phone calls haven't gone through. So I thought I may as well ask this
> list if this a single case or the "new normal"...
>
> Regards,
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Viktor Dukhovni]

On Wed, Jul 28, 2021 at 04:39:39PM +0200, Josh Good wrote:

> > Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
> >  
> > Good Afternoon, We inform you that due to Rhenus security policies,
> > as of 08/01/2021 receiving of emails that do not comply with version
> > 1.2 of the TLS protocol will be restricted.  All emails sent in
> > particular to the domain @es.rhenus.com and in general to any Rhenus
> > domain @*.rhenus.com must be sent with the TLS 1.2 protocol or
> > higher.  Any mail received without fulfilling this condition will be
> > rejected by our server.
> 
> The above could mean that starting 08/01/2021 their TLS support will
> only support TLS 1.2 (and not any earlier TLS version) with their
> inbound SMTP servers remaining configured in "opportunistic TLS" mode

That's my reading of the situation.  Someone decided to implement
checklist compliance, disconnected from any sound threat model.

Communication with SMTP clients or remote servers that only support TLS
1.0 will likely be in the clear, b/c that's of course more secure that
TLS 1.0. :-)

Of course one should ensure that all the systems one operates do support
TLS 1.2 and probably also TLS 1.3, but I would as yet recommend
disabling TLS 1.0 in SMTP, there is no compelling reason to do that.

> If the case is the second one, is that a current trend? Has rfc2487
> been obsoleted and mandatory TLS is now considered "industry standard"
> in publicly-referenced SMTP server?

Use of STARTTLS in MTA-to-MTA SMTP is of course recommended, and widely
practiced,

https://transparencyreport.google.com/safer-email/overview

but is not as yet a requirement.  Some "elite" operators may choose to
refuse to communicate with the laggards still sending in cleartext, but
that's just a bleeding edge choice, not a protocol requirement.

-- 
Viktor.