Mailserver – Gebrochenes TLS im Einsatz

Wer erinnert sich noch an diesen Beitrag BSI versendet Emails ohne TLS Verschlüsselung oder den hier : Sächsische Polizei benutzte gebrochene Verschlüsselung? Ja, genau, es geht wieder um Transportverschlüsselung von Mailservern. Ich habe mal wieder hingesehen 🙂 Von den angekündigten „Args“ habe aber wegen der Lesbarkeit Abstand genommen 😉 Einige Gespräche mit IT Abteilungen sind auch merkwürdig verlaufen und finden daher hier keinen Einzug.

Etwas TLS Kontext

Ich habe auf unserer Serverfarm letzte Woche eine Umfrage gemacht, welche TLS Versionen im Einsatz sind und eine entsprechende Domainliste mit veralteter TLS 1.0 oder TLS 1.1 Versionen erstellt. Die Liste ist 884 Domains lang und natürlich nur ein Bruchteil aller weltweit betroffenen Server. Man muß auch dazu sagen, daß es nicht immer die Mailserver einer Domain selbst sind, sondern auch veraltete und schlecht gewartete Mailprogramme, z.b. Outlook und AppleMail.

Was ich nicht erwartet hatte war, daß die jeweiligen PCs auf dem aktuellen Stand sind und trotzdem mit TLSv1 Kontakt aufnehmen. Der untersuchte Apple Mac hatte alle Securityupdates eingespielt und sendet, genau wie ein Win7 + Outlook PC, trotzdem nur mit TLSv1(.0). Ob das Absicht ist ?

Die zweite Meinung vom BSI

Um eine zweite Meinung zum Thema „Einsatz von TLS 1.0 und 1.1 im Unternehmerischen Umfeld“ zu bekommen, habe ich mich an das Bundesamt für Sicherheit in der Informationstechnik und deren Sicherheitsberatung gewendet. Folgende Antwort auf die Frage, ob man TLS 1.0 und 1.1 noch einsetzen kann, kam bei mir an:

Sehr geehrte Damen und Herren,

vielen Dank für Ihre Anfrage nach der Sicherheit beim Einsatz von Transport
Layer Security (TLS).

Das BSI hat für den Einsatz von TLS eine technische Richtlinie erstellt,
"Technische Richtlinie TR-02102-2 Kryptographische Verfahren: Empfehlungen und 
Schlüssellängen Teil 2 – Verwendung von Transport Layer Security (TLS)":
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf
https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html

Laut der technischen Richtlinie gelten TLS 1.0 und TLS 1.1 als unsicher und 
werden nicht mehr empfohlen.

Für die Bundesverwaltung hat das BSI einen Mindeststandard zum Einsatz von
TLS entwickelt, der für die Stellen des Bundes verbindlich umzusetzen ist:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindeststandard_BSI_TLS_1_2_Version_1_0.pdf 
https://www.bsi.bund.de/DE/Themen/StandardsKriterien/Mindeststandards/SSL-TLS-Protokoll/SSL-TLS-Protokoll_node.html

Dieser Mindeststandard referenziert die technische Richtlinie TR-02102-2 und
fordert für die Bundesverwaltung den Einsatz von TLS 1.2 mit PFS.

Wir hoffen, Ihnen mit diesen Informationen gute Argumente für die Stärkung
der Informationssicherheit in Ihrem Unternehmen geliefert zu haben.

Mit freundlichen Grüßen
das Team Sicherheitsberatung

Also ganz wichtig diese Passage :

Dieser Mindeststandard referenziert die technische Richtlinie TR-02102-2 und fordert für die Bundesverwaltung den Einsatz von TLS 1.2 mit PFS.

Mit anderen Worten, überspitzt, es darf nur noch TLSv1.2 mit PFS eingesetzt werden, weil 1.0 und 1.1 als gebrochen gelten, alles andere wäre ja fahrlässig. Oder liest da jetzt jemand was anderes raus 😉 ? Dazu später noch mehr.

Die Liste

Bevor ich Euch hier die Liste der Domains präsentiere, muß ich noch mal auf den Kontext hinweisen. Die Liste ist stark gekürzt und nach bestem Wissen von Fehlern durch Endgeräte bereinigt. Auch könnten SPAMMER im Namen einer Domain Mails geschickt haben, das konnte nicht bereinigt werden. Wer sich auch immer auf dieser Liste wiederfindet, sollte das zum Anlass nehmen, mal seine Mailinfrastruktur zu prüfen.
amazon.de
aol.de
apaed.tu-darmstadt.de
appelmann.de
architekten-stade.de
bistum-dresden-meissen.de
blog.magento-agentur-muenchen.de
bounce.academia-mail.com
bounce.crm.glamour.de
bounce.info.bonprix.de
bounce.kommunikation.wuv.de
bounce.kundenservice.dpv.de
bounce.mailing.adac.de
bounce.mail.verivox.de
bounce.news.ing-diba.de
bounce.newspromo.de
bounce.reedexpo-email.com
bounces.amazon.de
bounces.audible.de
burggymnasium.de
cornelsen.borekmedia.de
deutschepost.de
dgs.de
dhl.de
flyeralarm.de
heidelberger-coaching.de
kundenservice.vodafone.com
lists.tu-darmstadt.de
login.power-nic.de
mail.edeka.de
mail.paypal.de
news.experten.de
news.haendlerbund.de
news.hagebaumarkt.de
news.hamburg-messe.de
news.heide-park.de
newsletter.bund.de
newsletter.sparkasse-koelnbonn.de
newsletter.spkhb.de
nomail.hrz.tu-darmstadt.de
paypal.de
postbank.de
postpay.de
service.de.jura.com
service.hsv.de
service.meine-verbraucherzentrale.de
sternfreunde-braunschweig.de
sw.mail.edeka.de
tigersoft.de
tu-braunschweig.de
uk-koeln.de
unitymedia.de
uni.leuphana.de
wiso.uni-hamburg.de
facebookmail.com
support.facebook.com
mail.paypal.de
paypal.at
paypal.com

Bei diesen Domainnamen handelt es sich um die Domains der Sender, nicht der Mailserver selbst. Beispiel: nomail.hrz.tu-darmstadt.de.

Die Rückmeldungen

Von einigen habe ich natürlich schon Rückmeldung bekommen. Ohne Namen zu nennen, waren einige lahm, andere ausweichend:

Es steht auch bereits ein neues Mailsystem zur Verfügung. Aufgrund interner Umstrukturierungen bei *** verzögert sich dessen Verwendung jedoch noch etwas.

WAS ? 10 JAHRE!!!

Nach zehn Jahren kommt es dann auf ein, zwei zusätzliche Jahre auch nicht mehr an 😉 Was 10 Jahre schon? Ja, laut der Liste bei Wikipedia, erschien TLS1.2 2008 auf der Bühne. Da wir 2018 haben, sind das jetzt sportliche 10 Jahre 🙂

SSL 3.1 bzw. TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008

Nein, ich möchte dazu keinen zitierfähigen Kommentar abgeben.

Wesentlich besser war diese Antwort:

„...danke für den Hinweis. Da war das letzte Software Update weniger schlau als wir dachten 😐
Unsere 3 Server sollten jetzt mit der korrekten TLS Version senden.“ (Rechtschreibfehler behoben)

PayPal hat sich jedes Kommentars verweigert. Da PayPal auch Finanzinformationen per Mail verschicken könnte, wurde die BaFin eingeschaltet. Tja, ich war ja schon froh, daß nicht wieder die Polizei oder ein Bundesland .. ups.. glatt übersehen :

landkreis-helmstedt.de

Ich habe natürlich mit dem zuständigen Herrn telefoniert und er hat sofort verstanden worum es ging und wird es umgehend beheben. Dafür Daumen rauf ! Das war bislang der produktivste Kontakt aller kontaktierten Problemfälle.

Das CERT-BUND, auch betreut vom BSI, hat geschrieben:

vielen Dank für den Hinweis auf die TLS 1.0 Verwendung beim Newsletter-Versand über "newsletter.bund.de". Der IT-Dienstleister prüft, ob kurzfristig eine Umstellung auf TLS 1.2 möglich ist.

Mittelfristig ist geplant, dass der Newsletter-Versand über "mx.bund.de" erfolgt.

Mit freundlichen Grüßen
das Team CERT-Bund

geht doch 😀

Eine gängige Antwort war: „Schicken Sie mir das per EMail“ oder „Was erwarten Sie jetzt von mir?“ . Letzterer Satz kommt mir so bekannt vor ;D

Die Krönung

Aber wollt Ihr wissen, wer wirklich den Vogel abgeschossen hat ? Das war das BSI selbst 😀

2018-02-19 13:13:17 1enkJl-0007Vh-Ox <= sicherheitsberatung@bsi.bund.de H=m2-bn.bund.de [77.87.228.74] P=esmtps X=TLSv1:ECDHE-RSA-AES256-SHA:256 CV=no S=4513

Ich hatte ein zitierfähiges Statement fürs Blog angefordert, aber zur Zeit schweigt sich das BSI aus 🙂

Wer wissen will, was der Bund so alles über unsichere Mailverbindungen rausschickt :

2018-02-14 15:07:11 1elxiH-0003H1-Bi <= buerger-cert-newsletter_pgp@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=12118
2018-02-14 15:22:28 1elxx4-0008OP-2j <= buerger-cert-newsletter@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=5631
2018-02-16 13:27:45 1emf79-0005ne-Hd <= BGH-Pressemitteilungen@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=4497

Und so muß das eigentlich immer aussehen :

2018-02-19 13:18:37 1enkOw-0008B0-OH <= bugzilla@redhat.com H=mx1-phx2.redhat.com [209.132.183.26] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=3920

Der Kommentar

Ich glaube ja jetzt nicht, daß über die Newsletter vertrauliche Kommunikation läuft, aber gerade noch empfiehlt das BSI dem Bund nur TLSv1.2 einzusetzen und dann patzt der eigene BULK-Mailserver bei genau diesem Thema, das geht doch nicht Leute. Ihr habt eine Vorbildfunktion. Wenn Ihr das falsch macht, wer soll den Leuten das sonst zeigen?

Immerhin reagierte das BSI beim letzten mal binnen 24h auf das Problem, noch ist Zeit das zu unterbieten 😉 Aber es wird knapp …. und verloren .. Zeit ist um 😀 Die Stellungnahme hat zu lange gedauert (s.o.) .

Empfohlene Tools

Es gibt eine nette Seite, die für einen den TLS Check macht :

https://www.checktls.com/perl/live/TestReceiver.pl

Eine Beispielausgabe für Bloggt-in-braunschweig.de habe ich hier mal für euch:

Trying TLS on s120.resellerdesktop.de[83.246.80.133] (10):

seconds test stage and result
[000.100] Connected to server
[000.206] <– <span class="nortest stage and result
Connected to server
220 localhost.localdomain ESMTP Exim 4.89 Tue, 20 Feb 2018 10:55:04 +0100
We are allowed to connect
EHLO checktls.com
250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP
We can use this server
TLS is an option on this server
STARTTLS
220 TLS go ahead
STARTTLS command works on this server
Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-RSA-AES128-GCM-SHA256
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (s120.resellerdesktop.de = s120.resellerdesktop.de | DNS:pma.s120.resellerdesktop.de | DNS:s120.resellerdesktop.de | DNS:webmail.s120.resellerdesktop.de | DNS:www.s120.resellerdesktop.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:be:8f:cc:06:04:d3:6c:18:2a:45:87:b2:11:be:b4:dc:22
subject= /CN=s120.resellerdesktop.de
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Certificate 2 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate 3 of 3 in chain: Cert VALIDATED: ok
serialNumber=44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
EHLO checktls.com
250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250 HELP
TLS successfully started on this server
MAIL FROM:
250 OK
Sender is OK
Note: This does not affect the CheckTLS Confidence Factor
QUIT
221 localhost.localdomain closing connectionmal“>220 localhost.localdomain ESMTP Exim 4.89 Tue, 20 Feb 2018 10:55:04 +0100
[000.207] We are allowed to connect
[000.207] –> EHLO checktls.com
[000.307] <– 250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP
[000.307] We can use this server
[000.308] TLS is an option on this server
[000.308] –> STARTTLS
[000.411] <– 220 TLS go ahead
[000.411] STARTTLS command works on this server
[000.656] Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-RSA-AES128-GCM-SHA256
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (s120.resellerdesktop.de = s120.resellerdesktop.de | DNS:pma.s120.resellerdesktop.de | DNS:s120.resellerdesktop.de | DNS:webmail.s120.resellerdesktop.de | DNS:www.s120.resellerdesktop.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:be:8f:cc:06:04:d3:6c:18:2a:45:87:b2:11:be:b4:dc:22
subject= /CN=s120.resellerdesktop.de
issuer= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
Certificate 2 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
subject= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate 3 of 3 in chain: Cert VALIDATED: ok
serialNumber=44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
[001.048] ~~> EHLO checktls.com
[001.148] <~~ 250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250 HELP
[001.148] TLS successfully started on this server
[001.149] ~~> MAIL FROM:
[001.249] <~~ 250 OK
[001.249] Sender is OK
Hier war eine TEST EMAILADRESSE von uns drin.
[001.350] Note: This does not affect the CheckTLS Confidence Factor
[001.351] ~~> QUIT
[001.452] <~~ 221 localhost.localdomain closing connection

So (oben) muß das aussehen, aber auf keinen fall so (unten) :

seconds test stage and result
[000.117] Connected to server
[000.720] <– 220 mailer.faller.de ESMTP mailgw ready.
[000.720] We are allowed to connect
[000.721] –> EHLO checktls.com
[000.830] <– 250-mailer.faller.de checktls.com [www6.checktls.com] pleased to meet you.
250 DSN
[000.831] We can use this server
[000.831] TLS is not an option on this server
[000.831] –> MAIL FROM:
[000.955] <– 250 OK
[000.955] Sender is OK
[000.956] –> RCPT TO:
[001.088] <– 450 Temporary denied.
[001.089] Cannot proof email address (reason: RCPT TO rejected)
[001.089] Note: This does not affect the CheckTLS Confidence Factor
[001.089] –> QUIT
[001.204] <– 221 Closing connection.

In dem Sinne, checkt mal Eure Mailserver, ob die TLSv1.2 können und wenn, warum nicht!

Wer Fragen zu seiner Domain hat (bitte von der Domain senden) kann diese an „marius äd bloggt-in-braunschweig.de“ stellen, wir suchen gerne raus, was genau im Log steht. Dies Angebot kann aufgrund der entsprechenden Vorschriften nur eine begrenzte Zeit aufrecht gehalten werden.

Ach ja, im Rahmen der Krypto-Party der BS-LUG am 21. 2. 2018 um 18 Uhr im Haus der Talente, Braunschweig. sprechen wir mal drüber 😉

eine Weisheit

Wenn man die Scheisse Anderer nicht auslöffeln will,
sollte man den Stein, unter dem sie zu finden ist, nicht umdrehen.

Ein Teaser

Es folgt (vermutlich) bald(tm) ein Beitrag zum Thema Mailserver-TLS und es kommen oft die Worte „WIESO?“ ,“unsicher“,“gebrochen“ und vermutlich „args!“ darin vor. Die Liste der Verdächtigen beinhaltet das Who-is-Who nationaler und internationaler Konzerne.

hmm

Da ich ja schon früher über TLS geschrieben habe, wär es dann nicht eigentlich ein Cliffhanger in einer Endlos-Storyline ? 🙂

Followup – Der SSLv3 Stand

Ihr erinnert Euch noch an diese Beiträge zum Thema SSLv3 aus 2016 ?

Sächsische Polizei benutzte gebrochene Verschlüsselung

Neue TLS Probleme beim BSI

Häufigkeit von TLS Ciphern

Stand der Dinge

Ich habe mir mal gedacht, dies Analyse 2 Jahre danach nochmal zu machen und bin zu dem erfreulichen Ergebnis gekommen, daß kein Kontakt der letzten 4 Wochen noch mit SSLv3 um die Ecke gekommen ist. Natürlich hat das jetzt auch einen deftigen Nachteil, ich habe nichts über das man schreiben könnte 😉 Ich finde aber, daß ich den Preis gerne bezahle 😀

Naja, machen wir doch noch was daraus, das Update der meist benutzten Chipers der letzten 4 Wochen :

214417x TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
109616x TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
40927x TLSv1:ECDHE-RSA-AES256-SHA:256
19728x TLSv1.2:ECDHE-RSA-AES256-SHA384:256
16346x TLSv1:ECDHE-RSA-AES128-SHA:128
12112x TLSv1:AES128-SHA:128
9864x TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
7270x TLSv1:DHE-RSA-AES256-SHA:256
7139x TLSv1.2:AES256-GCM-SHA384:256
6924x TLSv1:AES256-SHA:256
3767x TLSv1.2:AES128-SHA256:128
2649x TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256
2443x TLSv1.2:DHE-RSA-AES128-SHA:128
2062x TLSv1.2:ECDHE-RSA-AES256-SHA:256
1226x TLSv1.1:ECDHE-RSA-AES256-SHA:256
805x TLSv1.2:AES128-SHA:128
748x TLSv1.2:DHE-RSA-AES256-SHA:256
442x TLSv1.2:AES256-SHA:256
362x TLSv1:DHE-RSA-CAMELLIA256-SHA:256
167x TLSv1:DES-CBC3-SHA:168
151x TLSv1.2:AES256-SHA256:256
135x TLSv1.2:ECDHE-RSA-AES128-SHA256:128
59x TLSv1:EDH-RSA-DES-CBC3-SHA:168
51x TLSv1.2:DHE-RSA-AES256-SHA256:256
40x TLSv1.2:AES128-GCM-SHA256:128
35x TLSv1:DHE-RSA-AES128-SHA:128
22x TLSv1.1:DHE-RSA-AES256-SHA:256
14x TLSv1.1:AES256-SHA:256
5x TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
3x TLSv1:DHE-RSA-DES-CBC3-SHA:168
3x TLSv1.2:ECDHE-RSA-AES128-SHA:128
2x TLSv1.2:ECDHE-RSA-DES-CBC3-SHA:168
1x TLSv1.2:DHE-RSA-CAMELLIA256-SHA:256
1x TLSv1.1:AES128-SHA:128

Bei 459.536 Emailtransporten insgesamt, ist der hohe Anteil an TLSv1 Protokollen doch erschreckend.

Die beiden Spitzenplätze sind gleich geblieben, aber in nachfolgenden Rängen, hat sich einiges, und das nicht zu guten getan, wenn ich das mit dem Beitrag vom März 2017 vergleiche. Am besten macht Ihr Euch da selbst ein Bild.

 

Exim – Wie man TLS erzwingt II

Im letzten Beitrag Exim – Wie man TLS erzwingt war das Blockieren von ausgehenden Verbindungen ohne TLS Thema. Heute befassen wir uns mit dem Gegenteil : Wie verhindern wir, daß wir eine Email bekommen, die unsicher übertragen wurde?

Exim ’s Access Control Lists

Exim als Mailserver erlaubt es uns, in jede Phase der Übertragung von Emails per SMTP einzugreifen und Emails aufgrund von Mustern und Bedingungen abzulehnen. Die ACL genannten Bedingungsketten sind universell einsetzbar, hier ein Beispiel:

acl_check_helo:

drop condition = ${if eq{$sender_helo_name}{ylmf-pc} {1}}
     message = Your a naugthy boy

accept

Die Helo-ACL prüft ob, sich der anfragende Mailserver mit einem bestimmten Namenskürzel meldet, hier „ylmf-pc„. Das ist so ziemlich todsicher ein Bot aus einem asiatischen Netzwerk. Zur Erklärung :

drop ist das Ziel der Aktion, wenn die condition greift. Hier der Vergleich (if eq) von dem was der „Client“ gesendet hat und dem ylmf-pc Text. Übersetzt heißt das : if ( „sender_helo_name“  == „ylmf-pc“ )  { log.message = „Your a naugthy boy“; message.drop(); }

So sieht das dann im SMTP aus :

220 irgendeinserver.de ESMTP Exim 4.89 Sun, 03 Dec 2017 14:33:48 +0100
HELO ylmf-pc
550 Your a naugthy boy

Ansonsten akzeptiere ( accept ) die Email. Natürlich könnte man hier auch schon DNS IP Blacklisten eintragen, oder andere Abfragen, die keinen Empfänger / Sender benötigen. Die meisten ACls werden aber genau bei der Sender- und Empfängerprüfung eingesetzt. Genau das werden wir in der ACL acl_check_rcpt tun.

Zum Glück sind die nötigen Anweisungen extrem übersichtlich :

acl_check_rcpt:
 ...
 deny condition = ${if eq{$tls_cipher}{}{1}{0}}
      message   = Sender did not use TLS secured connection.

Meint:

If ( tls_cipher ==  „“ ) { log.message = „Sender did not use TLS secured connection. „; message.deny() }

Das war es schon. Damit kommen nur noch Emails weiter, die über eine TLS gesicherte Verbindung gesendet werden. Ob das Spam ist oder nicht, muß man natürlich trotzdem prüfen, wenn die Mail erst einmal übertragen wurde.

Analyse

Da erst einmal nur der Empfänger in der SMTP Phase genannt wurde, ist der Inhalt der Email noch aus dem sendenen Server, denn der wird erst mit dem DATA Block übertragen. In die HELO ACL kann man das nicht einbauen, da SMTP verlangt, daß ein netter Server erstmal HELO  oder EHLO sagt, bevor er weiter macht.

Die übliche SMTP-Befehlsreihenfolge dürfte daher :

HELO
STARTTLS
MAIL FROM:
RCPT TO:
DATA

sein. Man kann es natürlich auch bereits in der mail_from ACL machen, ob das einen großen Unterschied machen wird, ist fraglich.

 

Exim – Wie man TLS erzwingt

Exim ist einer der vielseitigsten Mailserver die man auf einem Server haben kann, fast Nichts ist unmöglich. In einer Zeit, in der immer mehr abgehört wird und die Kommunikation von Personen, Firmen und Behörden geschützt werden muß, finden sich immer noch Mailserver, die kein TLS sprechen.

Mailtransportverschlüsselung

TLS wurde vor fast 19 Jahren per RFC als Nachfolger von SSL geboren und hat dies erfolgreich abgelöst. Sollte man jedenfalls meinen. Tatsächlich habe ich erst heute eine Rechnung von 1und1 bekommen, ja, Name & Shame in progress, die mit einem gebrochenen TLS 1.0 aka. „SSLv3 modified“ übertragen wurde :

H=mbulk.1and1.com [212.227.126.220] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256

Da unser Server TLS1.2 spricht und anbietet, kann man von einem Konfigurationsfehler ausgehen. Wenigsten wurde hier TLS gesprochen. Andere Mailserver können nicht mal SSL, die senden und empfangen unverschlüsselt, nicht wahr liebe Admins von faller.de 😉

Wie man TLS erzwingt

Im letzteren Fall kann man Exim dazu bewegen, daß er keine Emails ohne TLS sendet. Damit kann verhindert werden, daß Geheimnisse abgehört werden können. Exim ist von Haus aus mit den nötigen Funktionen ausgestattet und daher extrem leicht dafür zu begeistern 🙂

Der in praktisch jeder Eximconfig vorkommende Transporttreiber „remote_smtp“ muß nur um zwei Befehle erweitert werden:

remote_smtp:
 driver = smtp
 hosts_require_tls = *
 tls_tempfail_tryclear = false

Das zwingt Exim dazu, ohne TLS Verbindung abzubrechen und auf keinen Fall auf Klartext zurückzufallen. Das wäre ja auch selten dämlich, oder ? Tja, wie sich herausstellte, ist sich immer einer in der Welt nicht zu blöd, genau das zu machen 😀 Mein Name & Shame Beispiel für diesen Fail, hat sich allerdings bekehren lassen und sendet jetzt vorbildlich in TLSv1.2 \o/

Der ewige Optimist Exim

Exim sieht einen Fail beim TLS leider als temporären Fehler an. Er geht also davon aus, daß der empfangende Mailserver irgendwann in der Retryzeit seine Meinung ändert 😀 Aus Erfahrung kann ich sagen, nein, tun die empfangenden Mailserver nicht 🙂

Daher müssen wir die Retryzeit für diesen Fall auf 0 setzen, so daß sofort eine Delivery Message erzeugt wird.  Das erledigen wir so :

begin retry

*          refused
*           quota
*        tls_required
*             *         F,2h,15m; G,16h,1h,1.5; F,4d,6h

Das war es bis auf einen kleinen Schönheitsfehler schon: die Delivery Message macht für den Leser derselben keinen Sinn, da ein falscher Fehlergrund ausgegeben wird, aber das ist Euer Problem 😉