TLS 1.2 Mandatory setzen

Hallo Marc,

(Sorry, my German-speaking brain isn't creating thoughts at the moment. )

Since you certainly have a paid subscription, don't do the following until it has been "blessed" by Sophos Support.

There's probably a line (about 297) in /var/chroot-smtp/etc/exim.conf that contains

openssl_options = +no_sslv3

Change that to:

openssl_options +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1

And restart the Proxy:

/var/mdw/scripts/smtp restart

In my opinion Sophos should make a KnowledgeBase article for this fix for everyone in Europe.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Thanks Bob. As GDPR is comming, I am sure that will be useful for me too. But of course I will first get in touch with Sophos support. Maybe if enough tickets to that relate they release a kba.

Best

Alex

Agreed.  you neef good log parsing to know what is affected by any lockdown decision.

i surveyed my traffic:. 2 residential ISPs and 2 important businesses were not doing encryption.   Requiring it everywhere would block a lot of important traffic.

Alexander Busch said:

Hallo Marc,

das Erzwingen von TLS ist via GUI möglich, TLS 1.2 über die Konsole, siehe Post oben von Bob.

Kommt diese Lösung Deinen Anforderungen nicht nach?

Beste Grüße

Alex

 

Sorry für die späte Antwort. Dies kommt schon der Anforderung nach jedoch muss die Änderung über die Console nach jedem Update erneut durchgeführt werden.

Ab 9.510 kann die TLS-Version über den Webmin gesetzt werden!

9.510 is not yet perfected.  See Sophos UTM 9.510-4 released - let's share experiences! to confirm that one of the glitches mentioned is not a showstopper for your installation.

Cheers - Bob

Die TLS Probleme wurden mit der 9.510-5 behoben.

Was passiert nun mit MTA, die kein TSL unterstützen? Wird die Mail einfach gedropt? Gibt es eine Möglichkeit, den Log relativ einfach danach zu filtern oder dem Sender eine Nachricht zu schicken, dass wir nur TLS 1.2 akzeptieren (oder passiert das sogar schon)?

You need to look at your logs.   There will be some kind of rejection message.   Below is an example of the log file entries for an incoming message which was accepted and delivered.   A rejected message will have a disconnect during Exim-in. 

A server which cannot connect with encryption is likely to attempt reconnection without encryption.

Identifiable data in this example has been redacted.

Mesages flow from exim-in to smtpd to exim-out
Exim-In uniquely identifies this message as 1gI4Ci-00068x-2h (rows 4, 5, 6, 8, 9, 11, 12)
Exim-Out uniquely identifies this message as 1gI4Cq-00069A-41 (rows 9, 10, 13, 14)

Rows 1,2,3, and 7 are essentially useless because they cannot be matched to a specific mail message.

Row 9 is the critical row for connecting the Exim-In records to the Exim-Out records.
Row 10 contains the data used for Message Manager

Row 4 is the DKIM status report.
Row 5 "ctasd reports unknown" is the antivirus scan result
Row 6 has the encryption details for the incoming connection
Row 13 has the encryption details for the outgoing connection

1) 2018:11:01-00:03:32 defense exim-in[9851]: 2018-11-01 00:03:32 SMTP connection from [<SourceIP>]:47317 (TCP/IP connection count = 1)

2) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 H=<SourceHost> [<SourceIP>]:47317 Warning: ToCompany.com profile excludes greylisting: Skipping greylisting for this message
2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 H=<SourceHost> [<SourceIP>]:47317 Warning: ToCompany.com profile excludes SANDBOX scan

3) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 [<SourceIP>] F=<FromUser@FromDomain.com> R=<ToUser@ToCompany.com> Accepted: from relay

4) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 1gI4Ci-00068x-2h DKIM: d=FromDomain.com s=selector1 c=relaxed/relaxed a=rsa-sha256 [verification succeeded]

5) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 1gI4Ci-00068x-2h ctasd reports 'Unknown' RefID:str=0001.0A02020E.5BDA7B14.0065,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0

6) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 1gI4Ci-00068x-2h <= FromUser@FromDomain.com H=<SourceHost> [<SourceIP>]:47317 P=esmtps X=TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256 S=15225 id=D0A5A79D8EFA4D12809375CC11D45FB7@mmi.local

7) 2018:11:01-00:03:32 defense exim-in[23619]: 2018-11-01 00:03:32 SMTP connection from <SourceHost> [<SourceIP>]:47317 closed by QUIT

8) 2018:11:01-00:03:34 defense smtpd[9843]: QMGR[9843]: 1gI4Ci-00068x-2h moved to work queue

9) 2018:11:01-00:03:40 defense smtpd[23632]: SCANNER[23632]: 1gI4Cq-00069A-41 <= FromUser@FromDomain.com R=1gI4Ci-00068x-2h P=INPUT S=2511

10) 2018:11:01-00:03:40 defense smtpd[23632]: SCANNER[23632]: id="1000" severity="info" sys="SecureMail" sub="smtp" name="email passed" srcip="<SourceIP>" from="FromUser@FromDomain.com" to="ToUser@ToCompany.com" subject="eStatement Ready for Pickup" queueid="1gI4Cq-00069A-41" size="2511"

11) 2018:11:01-00:03:40 defense smtpd[23632]: SCANNER[23632]: 1gI4Ci-00068x-2h => work R=SCANNER T=SCANNER

12) 2018:11:01-00:03:40 defense smtpd[23632]: SCANNER[23632]: 1gI4Ci-00068x-2h Completed

13) 2018:11:01-00:03:40 defense exim-out[23635]: 2018-11-01 00:03:40 1gI4Cq-00069A-41 => ToUser@ToCompany.com P=<FromUser@FromDomain.com> R=static_route_hostlist T=static_smtp H=<TargetIP> [<TargetIP>]:25 X=TLSv1.2:AES128-SHA256:128 C="250 2.6.0 <D0A5A79D8EFA4D12809375CC11D45FB7@mmi.local> [InternalId=18992] Queued mail for delivery"

14) 2018:11:01-00:03:40 defense exim-out[23635]: 2018-11-01 00:03:40 1gI4Cq-00069A-41 Completed

Hallo Max,

Erstmal herzlich willkommen hier in der Community !

(Sorry, my German-speaking brain isn't creating thoughts at the moment. )

Thanks, Doug, you gave me the following idea.

I believe that messages using TLSv1.1 will be rejected if you have selected a minimum TLS version of 1.2.  I don't expect that anyone uses TLSv1.0 anymore or has no TLS capability, but I don't know that for a fact.

You can check to see which of your correspondents used TLSv1.1 this year with the following at the command line:

 # zgrep 'TLSv1.1' /var/log/smtp/2018/*/* |grep -oP '<= .*? H=' |sort -n|uniq -c|sort -n

You could then email the ones you want to continue receiving mail from that they should have their mail server upgraded to do TLSv1.2.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Hallo,

danke euch beiden vorab! Da ich leider keine Möglichkeit habe, eine no-TLS/TLS1.0/TLS.1.1 Mail zu senden und auch keine Onlinetools dazu gefunden habe, bei denen man das einstellen könnte, weiß ich leider nicht, was passiert, wenn solch eine Mail hereinkommt - gibt es ein Fallback auf no-TLS? Bekommt der andere Mailserver bzw. Absender eine Nachricht, dass das Mail nicht angenommen wurde? Wir wollen natürlich nicht, dass MAils einfach an der Firewall "verloren" gehen, ohne das jemand etwas davon mitbekommt.

LG

Max

Nearly all mail server connections are based on STARTTLS, so the traffic will attempt to negotiate encryption, and fall back to unencrypted if TLS negotiation fails. The exim.conf changes that were discussed in the early days of this document only control which TLS methods are allowed, not whether unencrypted traffic is allowed. To block unencrypted traffic

• From the GUI, you can specify TLS-required hosts / networks, which could be set to ANY. From my reading of the help, this setting may apply to outbound traffic.
• So you can specify TLS-required mail domains, but this setting is stated to apply to inbound mail only.

 The scenario that created the TLS encryption requirement:

1. Bad guy wants to intercept your traffic, but you and your business partners communicate using TLS encryption,
2. You and your business partners have a TLS in both directions.
3. Bad guy inserts himself into the connection in a way that weakens TLS connection
4. Bad guy uses one of the TLS hacks to intercept and decode your traffic.

If step 2 has not been implemented, bad guy simply inserts himself into the connection in a way that prevents encryption, and his job is much easier.

If you require TLS 1.2 for encryption, but allows unencrypted, then the traffic will be unencrypted and the bad guy's job is much easier.

As to the last question: if you successfully block both unencrypted traffic and encryption before TLS 1.2, then you will miss some mail.  But that is the point. Your new policy says that the correspondent must upgrade to a TLS1.2-enabled configuration.   

For outbound traffic, the documentation says that encryption failure causes the outbound messages to be queued until the abandonment timer occurs (probably at least 24 hours). For inbound traffic, the sender probably experiences the same behavior, but the actual behavior depends on their mail system.

Nearly all mail server connections are based on STARTTLS, so the traffic will attempt to negotiate encryption, and fall back to unencrypted if TLS negotiation fails. The exim.conf changes that were discussed in the early days of this document only control which TLS methods are allowed, not whether unencrypted traffic is allowed. To block unencrypted traffic

• From the GUI, you can specify TLS-required hosts / networks, which could be set to ANY. From my reading of the help, this setting may apply to outbound traffic.
• So you can specify TLS-required mail domains, but this setting is stated to apply to inbound mail only.

 The scenario that created the TLS encryption requirement:

1. Bad guy wants to intercept your traffic, but you and your business partners communicate using TLS encryption,
2. You and your business partners have a TLS in both directions.
3. Bad guy inserts himself into the connection in a way that weakens TLS connection
4. Bad guy uses one of the TLS hacks to intercept and decode your traffic.

If step 2 has not been implemented, bad guy simply inserts himself into the connection in a way that prevents encryption, and his job is much easier.

If you require TLS 1.2 for encryption, but allows unencrypted, then the traffic will be unencrypted and the bad guy's job is much easier.

As to the last question: if you successfully block both unencrypted traffic and encryption before TLS 1.2, then you will miss some mail.  But that is the point. Your new policy says that the correspondent must upgrade to a TLS1.2-enabled configuration.   

For outbound traffic, the documentation says that encryption failure causes the outbound messages to be queued until the abandonment timer occurs (probably at least 24 hours). For inbound traffic, the sender probably experiences the same behavior, but the actual behavior depends on their mail system.