Moin,
in der aktuellen (LdN211) Folge haben Philip und Ulf zum Schluss über die Geheimdienste und aktuelle Trojaner geredet.
Gibt es dazu mehr Quellen die das ganze von einer mehr technischen Seite analysieren/betrachten? Mich würde insb. der Part interessieren, wie der Traffic über die ISB an die Geheimdienste umgeleitet werden sollen. Ich konnte hierzu leider keine eigenen Quellen finden.
VG
In dem Gesetzentwurf steht zur Technik überhaupt nichts. Das ist auch Absicht, weil Gesetze normalerweise möglichst Technik-neutral formuliert werden, damit man sie nicht anpassen muss, wenn es technische Fortschritte gibt.
Näherungsweise kann man sich das so vorstellen, dass der gesamte Traffic für bestimmte Kunden über einen Proxy des Geheimdienstes geleitet wird. So gut wie alle Daten werden einfach durchgeleitet, aber sobald im Datenstrom eine ausführbaren Datei auftaucht, wird die mit einem Trojaner verseucht und erst dann weitergeleitet.
Ich war für die Berichterstattung etwas verwundert. Ihr (Ulf) habt das Thema TLS eigentlich vorbildlich erklärt. Allerdings ist die Schlussfolgerung meiner Meinung nach falsch:
Beispiel Firefox- oder Windows-Update: natürlich bauen diese Programme nur eine Verbindung zum Update-Service auf, wenn der Server sich mit einem für seine Domain gültigen Zertifikat „ausweisen“ kann. Vermutlich wird es sogar noch Fingerprint Prüfungen der Intermediate Zertifikate geben. Zum Schluss sind sicher auch Windows-Updates beispielsweise zusätzlich signiert.
Würde der Geheimdienst also die Verbindung (wie richtig erklärt mit eigenem Zertifikat) aufbrechen, würde der Download gar nicht gestartet. Alles andere wäre selbst verständlich eine massive Sicherheitslücke.
Anders sieht es vielleicht beim normalen Aufruf von Webseiten aus. Hier bekommt der User eine Warnung angezeigt, die er je nach Browser einfach (oben eben recht aufwendig, bei z.B. Safari mit TouchID) ignorieren muss. Gerade hier werden die Browser auch immer strikter, sodass der „normale“ User tendenziell eher die Seite nicht aufruft.
Aber hier besteht natürlich eine Gefahr bzw. Möglichkeit für Geheimdienste.
Verschlimmert wird das Ganze natürlich dadurch, dass viele gerade im Unternehmensumfeld darauf „trainiert“ werden diese Hinweise auf (internen) Seiten einfach zu ignorieren.
Wir haben uns natürlich ein plastisches Beispiel gesucht. Es mag sein, dass FF sinnvolle Sicherheitsmaßnahmen ergreift, beispielsweise Certificate Pinning. Aber meine eigenen Versuche mit dem Charles Proxy
weisen darauf hin, dass jedenfalls die allermeisten Apps kein ordentliches Pinning einsetzen und jedes Cert schlucken, das vom System als gültig akzeptiert wird.
Wenn man das selbst testen will „hackt“ man natürlich sein Gerät mit einem Root-Cert. Aber man kann wohl getrost davon ausgehen, dass ein Geheimdienst auch Zugriff auf eine normale Root-CA hat, deren Certs vom OS by default akzeptiert werden. Wenn nicht die Telekom mitspielt, dann findet sich garantiert ein befreundeter Dienst, der das gerne übernimmt.
Um an dieser Stelle nochmal nachzubohren:
Das heißt, @vieuxrenard du gehst davon aus, dass Geheimdienste auch heute schon die Möglichkeit haben, gefälschte Zertifikate durch Root-CAs signieren zu lassen?
Das gab es zwar schon, zum Beispiel 2011, als die damalige niederländische CA DigiNotar ein gefälschtes Wildcard-Zertifikat für google.com ausgestellt hatte und dieses für MITM-Attacken im Iran verwendet wurden. Auch andere Fälle sind bekannt, bei denen CAs schlicht selbst gehackt wurden, um falsche Zertifikate zu signieren.
Allerdings gibt es genau wegen solcher Fälle mittlerweile eine – aus meiner Sicht – halbwegs wirkungsvolle Maßnahme gegen fälschlicherweise ausgestellte Zertifikate: Certificate Transparency.
Laurie et al. schlugen dafür ein öffentliches, kryptographisch signiertes append-only Log basierend auf einem Merkle-Tree vor, in das jedes neu ausgestellte Zertifikat eingetragen wird. Jedes Zertifikat kann dann darauf hin überprüft werden, ob es im Log vorkommt.
Dadurch sollte es auch Geheimdiensten recht schwer fallen, gültige Zertifikate, zum Beispiel für mozilla.org, zu nutzen.
Faktisch haben die Geheimdienste ja schon jetzt legal die Möglichkeit, 20% des deutschen Traffics passiv zu analysieren. Wie wir durch die Selector-Affäre vor einigen Jahren mitbekommen haben, wurden die deutschen Geheimdienste hier ja auch zu Erfüllungsgehilfen für die CIA und NSA und haben effektiv Wirtschaftsspionage betrieben.
Sobald aber aktiv in den Verkehr eingegriffen werden darf, gehen die Möglichkeiten massiv hoch. Downgrade-Attacken können beispielsweise die TLS-Verbindungen von neuen, sicheren Versionen auf ältere, unsichere Versionen runterbrechen. Hat man in Firefox oder Chrome nicht das https-only-Plugin aktiviert, versuchen alle heutigen Browser auch im Zweifel eine unverschlüsselte HTTP-Verbindung (falls nicht explizit verschlüsseltes HTTPS angefordert wird). HSTS - was dem Browser signalisiert, dass nur verschlüsselte HTTPS-Verbindungen gemacht werden sollen - funktioniert erst nach dem ersten Aufruf einer Seite und nicht bei noch nie besuchten Seiten. Zuletzt ist der Browser selbst ja neben Dutzenden weiteren Programmen installiert, wovon die meisten automatische Updater installiert haben, wovon im Zweifel dann mindestens eins unsicher implementiert sind.
Wer mehr über die Schwierigkeiten von sicheren Updates lernen will, kann mal mit dem BDF-Proxy rumspielen[1] oder sich die dort verlinkten Vorträge anschauen - der BDFProxy macht genau das, was die Geheimdienste auch wollen: er baut dynamisch in den Traffic Malware in ausführbare Downloads (wie Softwareupdates) ein.
[1] GitHub - secretsquirrel/BDFProxy: Patch Binaries via MITM: BackdoorFactory + mitmProxy.
Danke für die Hintergründe. Das kann man nur hoffen … aber ob die Prüfung wirklich immer zuverlässig ist? Es genügt ja eine schlecht programmierte Routine in einem Autoupdater, und schon kommen die Schlapphüte ins System.