TLS 1.3 Europa baut eine Hintertür zum Schnüffeln ein

[ingo2]

Ich habe hier gerade diesen Artikel auf Heise-Security gelesen: https://www.heise.de/security/meldung/I ... 45220.html. Die Diskussion dazu ist wenig informativ. TLS sichert - bzw. soll absichern - halt nur die Übertragung zwischen 2 Endpunkten gegen mitlesen und spoofing ab. Dass dabei die beiden Endpunkte einander vertrauen müssen, ist Voraussetzung, um das zu gewährleisten gibt's z.B. TLSA/DANE. Ist ja auch der übliche Anwendungsfall: ich will z.B. mit meinem heimischen Serverlein, der Bank, der Krankenkasse, ... sicher verschlüsselt kommunizieren - und mit Niemanden anderes.

Jetzt wollen die Europäer - genaugenommen die ETSI - dies verhindern, indem der Diffie-Hellmann Schlüsseltausch aufgeweicht wird und auf Serverseite statische Keys verwendet werden. Sie nennen das vornehm "eTLS" (sollte eigentlich backdoorTLS heißen). Das gemeine daran: der Client kann das praktisch nicht feststellen bzw. von sicherem TLS 1.3 unterscheiden.

Interesse an solch einer Sauerei können doch eigentlich nur Geheimdienste und ähnliche Organisationen haben, denn sie können aufgezeichnete Kommunikation nachträglich in aller Ruhe entschlüsseln. Genau das soll ja der regelmäßige Schlüsselwechsel unterbinden.

Gibt es da wirklich keine machbare Möglichkeit, das auf Clientseite zu detektieren?

[hikaru]

Gibt es da wirklich keine machbare Möglichkeit, das auf Clientseite zu detektieren?

Ich bin alles andere als ein Experte auf dem Gebiet, aber ich meine, es kann prinzipbedingt keine clientseitige Möglichkeit geben um nachzuweisen, dass der Server sicher ist.

Als erste Kontrollmöglichkeit wird ja im Artikel erwähnt, dass der Client die vom Server gesendeten URI-Labels auswerten soll. Ja dann sendet der Server eben keine verdächtigen Labels. Negativbeweise funktionieren in der Regel nicht. Ein Positivbeweis ist prinzipiell erbringbar, ich weiß aber nicht wie ein TLS-Server einfach nachweisen sollte, dass er kein "e" hat.
Im zweiten Schritt soll der Client prüfen, ob ein Server mehrfach den selben Schlüssel sendet. Viel Spaß dabei, wenn der Server pseudozufällig einen von 10^x kompromittierten Schlüsseln sendet! Der Algorithmus des Zufallsgenerators und der Schlüsselpool sind natürlich geheim. Die kompromittierten Schlüssel würden nach 10^y Jahren auffliegen, einfach weil es irgendwann Kollisionen gäbe, die man prinzipiell auf Clientseite detektieren könnte. Aber auch dagegen hilft ein geheimer Pseudozufallsgenerator, der jedes Jahr neue Schlüssel generiert.

Die Juristen meinen, eTLS soll aus Urhebenrechtsgründen nicht so heißen dürfen. Als ob das einen Schlapphut interessieren würde.

eTLS scheint vom Design her fertig zu sein. Gibt es einen Grund anzunehmen, dass es (oder etwas Ähnliches) nicht schon längst benutzt wird?

Eigentlich ist die Sache aber weniger dramatisch als sie klingt. Die Frage lautet ja, ob du dem Server vertraust oder nicht. eTLS ist offensichtlich nicht vertrauenswürdig. Bei der Vertrauensabwägung musst du nun also auch noch berücksichtigen, ob er eTLS bzw. etwas Ähnliches verwendet oder nicht. Das hättest du aber ohnehin bisher schon machen sollen.
Die eigentliche Vertrauensfrage lautet nicht, ob die Serversoftware Hintertüren bietet, sondern ob du dem Serverbetreiber die Absicht unterstellst, Software mit Hintertüren einzusetzen - und falls du ihm die Absicht nicht unterstellst, ob du ihm dann die Kompetenz zuschreibst sicherzustellen, das ihm kein anderer Hintertüren unterschiebt.

[ingo2]

Eigentlich ist die Sache aber weniger dramatisch als sie klingt. Die Frage lautet ja, ob du dem Server vertraust oder nicht. eTLS ist offensichtlich nicht vertrauenswürdig. Bei der Vertrauensabwägung musst du nun also auch noch berücksichtigen, ob er eTLS bzw. etwas Ähnliches verwendet oder nicht. Das hättest du aber ohnehin bisher schon machen sollen.
Die eigentliche Vertrauensfrage lautet nicht, ob die Serversoftware Hintertüren bietet, sondern ob du dem Serverbetreiber die Absicht unterstellst, Software mit Hintertüren einzusetzen - und falls du ihm die Absicht nicht unterstellst, ob du ihm dann die Kompetenz zuschreibst sicherzustellen, das ihm kein anderer Hintertüren unterschiebt.

@hikaru: Sehr gute Zusammenfassung, das Man-in-the-middle Problem ist damit also immer noch nicht gelöst.

Tja, so wie es aussieht, ist TLS 1.3 mit Diffie-Hellman Schlüsseltausch (statt bisher RSA) noch immer nicht ausreichend. Selbst wenn ich DNSSEC und DANE benutze, um sicher zu gehen, daß ich mit dem "richtigen" Server verbunden bin und kommunizieren will, fehlt noch eine Authentifizierung - speziell in der Phase des Schlüsseltauschs.
OpenVPN z.B. kann das sogar, dafür gibt's den "ta.key", kann man mit dem Parameter "tls-auth" einbinden.

Etwas besser wäre schon, wenn der Client den DH-Parameter liefert, der kann dann nach Bedarf wechseln.

[ingo2]

Hier habe ich eine gute Beschreibung zum Thema DH mit statischem Server-Key gefunden:
https://tools.ietf.org/id/draft-green-t ... 13-01.html

Kleiner Trost: auch die Serverbetreiber schwächen die Sicherheit ihrer IT (s. Kapitel 10. Security considerations )