Tag Archives: TLS

IT Niedersachsen verwechselt Mailserver ;)

Posted on by

Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.

IT Niedersachsen verwechselt Mailserver 😉

Wenn man viel Infrastruktur hat, kann einem das schon mal passieren. Vor einigen Jahren hatte ich mal einen Beitrag ĂŒber die Stadt WolfenbĂŒttel im IT Sec Vortrag, weil deren Mailserver komische Zertifikate fĂŒr SMTP benutzt hatte, die keiner kennen konnte, weil selbst-signiert und fĂŒr interne Testserver gedacht. Damals hatte deren IT das Problem, es ĂŒberhaupt zu finden, weil die Microsoftlösung Ihnen einen vom Pferd erzĂ€hlt hatte 🙂

Vielleicht ist das jetzt so etwas Àhnliches:

Wenn man eine Email an eine Adresse schicken will, die von diesem Server bedient wird:

80.228.54.249 „inetmail23.niedersachsen.de“

Dann bekommt man im Exim das hier:

SSL verify error: certificate name mismatch: DN=“/C=DE/ST=Niedersachsen/L=Hannover/O=Land Niedersachsen/OU=IT.Niedersachsen, FG 24a/CN=inetmail14.niedersachsen.de“

Weil das ausgelieferte Zertifikat nicht mit dem Hostnamen ĂŒbereinstimmt. Vermutlich wurde einfach nur das falsche Zertifikat verteilt. Witzig ist nur, daß es auf beiden Servern passiert ist, denn ein „host inetmail23.niedersachsen.de“ zeigt zwei verschiedene IPs an. Da darf man von einem Deployserverproblem ausgehen, also hat es keiner mit Handarbeit verteilt 🙂

 

TLS: Timing Attacke RACCOON

Posted on by

Intel kennt das Problem: Laufend kommt einer an und kann an der Laufzeit von Berechnungen Daten ableiten, die er nicht sieht. Jetzt ist mal wieder TLS dran mit so einem Angriff auf den DH SchlĂŒssel.

TLS: Timing Attacke RACCOON

Wie die Hacker News berichten, gibt es eine neue, aber sehr spezielle, Methode an einen ServerschlĂŒssel zu kommen. Voraussetzung ist allerdings, daß der Server seine verwendeten SchlĂŒssel erneut benutzt. Das sollte er wegen PFS sowieso nicht tun, aber nicht alle Dialekte von TLS 1.2 sind PFS fĂ€hig.

Um die LĂŒcke ausnutzen zu können, muß der Angreifer zu dem sehr prĂ€zise Messungen zur Laufzeit machen können, daher muß er technisch sehr dicht am Server dran sein, um die Messungen akkurat vornehmen zu können. In den meisten FĂ€llen wird der Versuch da bereits scheitern. Auch Scheitern wird der Angriff, wenn PFS zum Einsatz kommt, weil der Server den privaten DH SchlĂŒssel dann nicht wieder verwendet.

F5, Mozilla, Microsoft und OpenSSL haben schon Updates parat, wobei M$ sich darauf beschrĂ€nkt, die DHE einfach abzuschalten, statt das Problem zu lösen 😀 Auch ne Methode 😉 Wie man hier nachlesen kann: OPENSSL: https://www.openssl.org/news/secadv/20200909.txt hat OpenSSL das Problem in Ă€lteren OpenSSL Versionen bereits durch eine andere Defaulteinstellung behoben. Damit ist die GefĂ€hrlichkeit des Angriffs eher gering einzuschĂ€tzen.

Ich habe mir mal die MĂŒhe gemacht und konnte selbst in einer 2 Jahre alten OpenSSL Version den nötigen Cipher nicht und damit ist der Webserver auch nicht anfĂ€llig. Ein Test durch SSLLabs hat das bestĂ€tigt:

Uses common DH primesNo, DHE suites not supported
DH public server param (Ys) reuseNo, DHE suites not supported
ECDH public server param reuseNo

Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.

Exim: TLS Protokollnamen haben sich geÀndert

Posted on by

Heute habe ich ein kleines exotisches Problem aus der Exim Welt fĂŒr Euch, aus dem Ihr auch ohne Exim was lernen könnt.

Exim: TLS Protokollnamen haben sich geÀndert

Im Exim gibt es die Variable $tls_cipher. In dieser steht das TLS Protokoll drin,  auf welches sich die beteiligten Mailserver geeinigt haben. Rund eine Woche vor Exim 4.93 wurde „noch schnell“ ein Patch zur Standardisierung von SSL/TLS-Protokollnamen in das kommende Release (4.93) eingefĂŒgt. Leider war das eher unĂŒberlegt, denn es wurde vergessen diesen Wechsel der Namen im ChangeLog von Exim 4.93 bekannt zu geben.

Nun setzten wir dies tatsÀchlich in einer ACL ein:

deny condition = ${if eq{${substr_0_7:$tls_cipher}}{TLSv1.2} {0}{1}}

Was dazu gefĂŒhrt hat, daß beim Wechsel auf Fedora 31 und in Folge auf Exim 4.94 die Config anpassen mußten:

deny condition = ${if eq{${substr_0_6:$tls_cipher}}{TLS1.2} {0}{1}}

Da diese Änderung nicht dokumentiert wurde, kam es nach dem Upgrade zu einer Störung des Mailverkehrs. Das möchte man natĂŒrlich vermeiden und deswegen liest ein Admin die Changelogs durch. Nutzte hier nur nichts.

Nehmt daher fĂŒr Eure Projekte zwei Sachen mit:

1. Alles was zu Änderungen von Ausgaben und Variableninhalten fĂŒhrt, muß von Euch kommuniziert werden, sonst => Problem mit Nutzern.

2. „Testen! Testen! Testen!“