Der (IT) Blog aus Braunschweig
Die IETF hat TLS 1.0 und 1.1 in den Ruhestand verabschiedet. Damit werden neue Sicherheitslücken in diesen Protokollen nicht mehr behoben.
Ab jetzt liegt es an OpenSSL und GnuTLS, wann TLS 1.0 und 1.1 aus den Kryptobibliotheken verschwinden werden.
Quelle: https://datatracker.ietf.org/doc/rfc8996/
Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.
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 🙂
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 🙂
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.
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 primes | No, DHE suites not supported |
| DH public server param (Ys) reuse | No, DHE suites not supported |
| ECDH public server param reuse | No |
Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.