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

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.

Hi Max,

TLS kannst Du nur erzwingen wenn "Email Protection > SMTP > Advanced > Require TLS Negotiation/Hosts" oder "Require TLS Negotiation Sender Domains"  Inhalt hat.

Dann müssen zwingend diese Mailserver/Domains TLS können und zwar mindestens in einer Version, die Du unter "Email Protection > SMTP > Advanced > TLS version" festlegst.

Erst wenn die Gegenseite TLS-fähig ist, erst dann ist TLS Version interessant.

Kann die Gegenseite kein TLS, dann wird "plain" eingeliefert.

Kann die Gegenstelle TLS, aber Gegenstelle und UTM werden sich über die Version/Ciphers nicht einig, dann nimmt die UTM die Email nicht an/bzw versendet sie nicht.

Es findet kein Fallback auf eine non-TLS Verbindung statt. Die Email wird nicht ausgeliefert/angenommen.

Ansonsten siehe Posts von BAlfson und DouglasFoster.

Hallo Peter,

ja, wenn ich dort "Any" respektive "*" eintrage, erzwinge ich also TLS mit der eingestellten Version. Das habe ich verstanden :)

Mir geht es jetzt aber wirklich um diese Frage: sehe ich Plain-Emails im Log (bzw kennt jemand eine Seite, die nur Plain-Email verschickt, damit ich das testen kann) bzw. eher noch wichtiger: was passiert mit den Plain-Mails, wenn sie "nicht ausgeliefert/angenommen" werden - bekommt der Emailabsender da eine Nachricht oder geht die einfach unter (Blackhole)?

Ich kann nämlich hervoragend damit leben, gar keine Plain Email anzunehmen, allerdings nur, wenn der Absender davon in Kenntnis gesetzt wird!

LG

Max

As I said, sender will only be notified after his mail system abandons all connection attempts.   This is typically 1 or 2 days, although the IETF standard says that systems should retry for 4 days.

As I said, sender will only be notified after his mail system abandons all connection attempts.   This is typically 1 or 2 days, although the IETF standard says that systems should retry for 4 days.