Skip to content

SSL/TLS - Mal wieder einige schlechte Nachrichten!

Heute gibt es mal wieder einige Nachrichten rund um SSL/TLS und das Zertifikatssystem. Natürlich schlechte. Gab es dazu eigentlich auch mal gute Nachrichten? Erinnern kann ich mich gerade an keine.

Eine CA verspielt das in sie gesetzte Vertrauen

Die Intermediate-CA MCS (ein ägyptischer ISP) der chinesischen CA CNNIC hat im März Zertifikate für einige Google-Domains ausgestellt. Das wäre noch kein Problem, wenn man den Auftrag dafür von Google bekommen hätte. Hatte man aber nicht. MCS hat ihren private Schlüssel in einem MitM-Proxy installiert, der dann die Zertifikate für die Google-Domains ausgestellt hat.

Zunächst sperrte Google daraufhin die Zertifikate von MCS und etwas später wegen erwiesener Unzuverlässigkeit auch die Root- und Extended-Validation-Zertifikate von CNNIC. Die werden in zukünftigen Chrome-Versionen nicht mehr enthalten sein. Was CNNIC natürlich gar nicht gut findet.

Die scheinen das Problem nicht verstanden zu haben. Eine ihrer Intermediate-CAs hat MitM-Zertifikate ausgestellt, und das soll in Ordnung sein?

Wenn eine von den Browser- und Systemherstellern als vertrauenswürdig eingestufte CA MitM-Zertifikate ausstellt, kann man den Zertifikaten nicht mehr vertrauen. Und zwar allen Zertifikaten, sofern die nicht durch Pinning geschützt sind. Und dann könnte man das Zertifikatsystem gleich ganz einstampfen. Also die CAs dicht machen, man braucht sie ja dann nicht mehr. Alle. Da scheint es doch eine durchaus angemessene Lösung zu sein, erst mal nur EINE CA aus dem Verkehr zu ziehen. Nämlich die, die sich nicht an die Regeln gehalten hat: CNNIC (und damit auch deren Intermediate-CAs).

Auch bei Mozilla traut man CNNIC nicht mehr. Nachdem man nach der Entdeckung der gefälschten Google-Zertifikate zunächst ebenfalls dem Intermediate-Zertifikat von MCS das Vertrauen entzogen hat, wurde nun auch von CNNIC neu ausgestellten Zertifikaten das Vertrauen entzogen. Was nur konsequent ist, da die Firefox-Entwickler die CAs schon 2012 gewarnt haben, dass das Ausstellen von MitM-Zertifikaten inakzeptabel ist. Was ja eigentlich eine Selbstverständlichkeit sein sollte.

Während Microsoft das Zertifikat von MCS ebenfalls gesperrt hat (zu CNNIC liegt noch keine Information vor), gibt es seitens Apple bisher keine Reaktion.

Daraufhin wollte ich die CA bei mir lokal als nicht vertrauenswürdig einstufen, aber das war gar nicht mehr nötig. Ich hatte schon vor einigen Jahren etlichen CAs das Vertrauen entzogen, und da war CNNIC anscheinend dabei. Jedenfalls ist deren Root-Zertifikat auf meinem Rechner als nicht vertrauenswürdig markiert.

Ein falsches Zertifikat, aber streng nach Regeln!

Ein finnischer IT-Manager hat sich von der CA Comodo (ja, genau, DIESER CA) ein Zertifikat für Microsofts Domain live.fi ausstellen lassen. Das war ganz einfach, er musste dazu nur eine spezielle Mailadresse registrieren und den Empfang einer E-Mail an diese Adresse bestätigen.

Bei der Beantragung eines Zertifikats muss die CA prüfen, ob der Antragsteller auch dazu berechtigt ist. Eine Möglichkeit, dass zu tun, besteht darin, eine E-Mail mit einem Verifizierungscode an eine E-Mail-Adresse zu schicken, die unter der Kontrolle des Domaininhabers steht wie zum Beispiel postmaster@ oder root@.

Comodo akzeptiert unter anderem auch hostmaster@, und der Finne konnte beim Freemailer live.fi die Adresse hostmaster@live.fi registrieren. Danach hat er testweise versucht, ein Zertifikat zu erhalten. Erfolgreich. Und das Problem bereits im Januar an Microsoft und die finnische Regulierungsbehörde für Kommunikation gemeldet. Eine Reaktion erfolgte erst im März - Microsoft sperrte seinen Live-Account.

Ein Freemailer, der die bekannten Role-Account-Adressen nicht für die Registrierung durch Kunden sperrt hat so einen "Angriff" ja eigentlich verdient. Vor allem, weil die Verwendung von hostmaster@ in einer Richtlinie über die Prüfung von Domains (PDF, siehe Seite 17, Abschnitt 11.1.1, Punkt 4; via Fefe) enthalten ist. An der unter anderem Microsoft mitgearbeitet hat.

Ach so: Das war nicht das erste Mal, dass man bei Live solche Adressen registrieren konnte. Für die belgische Domain war das schon 2010 möglich. Und Microsoft wusste das auch.

RC4 - Unsicherer geht immer

RC4 gilt schon länger als unsicher, und auf der Black Hat Asia 2015 hat Itsik Mantin einen neuen Angriff vorgestellt, mit dem sich Teile der mit RC4 verschlüsselten HTTPS-Daten entschlüsseln lassen. Eine Variante des Angriffs kommt sogar ohne den sonst nötigen aktiven MitM aus, das passive Belauschen der Kommunikation reicht aus.

Wie seit dem vorigen Jahr üblich gibt es für den Angriff auch einen Namen: "Bar Mitzvah Attack".

Die Lösung des Problems ist ganz einfach: Es muss nur der RC4-Algorithmus in Clients und Servern deaktiviert werden.

FREAK - Factoring RSA Export Keys

Zu FREAK werde ich bei Gelegenheit noch einen längeren Text schreiben, deshalb habe ich den Angriff im Blog bisher auch nicht erwähnt. Jetzt ist das aber angebracht. Also:

FREAK (Factoring RSA Export Keys) ist ein Anfang März vorgestellter Angriff auf HTTPS-Server, die die in den 90er Jahren von den USA für den Export vorgeschriebenen schwachen Verschlüsselungsalgorithmen unterstützen. Der Angreifer muss als MitM agieren und kann dann den Rückfall auf die schwache Verschlüsselung mit einem unsicheren 512-Bit-Schlüssel erzwingen und diese danach brechen. Vorausgesetzt, dass auch der Client diese schwache Verschlüsselung unterstützt.

Auch dieses Problem lässt sich ganz einfach lösen: Sowohl auf den Clients als auch auf den Servern müssen die schwachen Export-Chiffren gelöscht werden. Entsprechende Updates/Patches wurden inzwischen für einen Großteil der betroffenen Software veröffentlicht.

Fazit

Das sind jede Menge schlechter Nachrichten. Interessanterweise reichen alle weit in die Vergangenheit zurück. Dass die CAs nicht unbedingt zuverlässig sind ist seit langem bekannt, und sowohl RC4 als auch die Export-Chiffren sollte heutzutage schon lange niemand mehr nutzen.

Aber während man die Chiffren einfach ausschalten kann (zum Glück gibt es noch ein paar sichere Alternativen) sieht es bei den CAs anders aus. Das Zertifizierungssystem muss dringend überarbeitet oder noch besser durch eine sichere Alternative ersetzt werden. Und das am besten, bevor wirklich etwas Schlimmes passiert. Bisher wird da nämlich nur an den Symptomen herum gedoktert: Als unzuverlässig aufgefallenen CAs wird von den Browser- und Systemherstellern das Vertrauen entzogen (oder wie im Fall von Apple und MCS/CNNIC auch nicht), und mittels Pinning werden ausgewählte Zertifikate gezielt geschützt. Auf Dauer wird das nicht reichen.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Einige Angriffe auf CAs im Überblick

Vorschau anzeigen
Das größte Problem bei der Sicherheit von SSL/TLS allgemein und HTTPS im besonderen ist und bleibt das bestehende Zertifizierungssystem. Es gibt einfach zu viele CAs, denen die Browser und Betriebssysteme ab Werk vertrauen. Stellt eine di