Transportverschlüsselung kontra Industrie eTLS hebelt Forward Secrecy von TLS 1.3 wieder aus

Mit eTLS hat die ETSI eine Implementierungs­variante von TLS 1.3 entwickelt, welche die vollständige Forward Secrecy des IETF-Standards mit nicht-ephemeralen DH-Schlüsseln unterwandert. eTLS ist also ein vergleichsweise durchsichtiger Versuch einiger Interessengruppen, die Forward Secrecy von TLS 1.3 gleich wieder abzuschaffen.

Anbieter zum Thema

FTAPI Software GmbH

Mimecast Germany GmbH

valvisio international AG

Die IETF (Internet Engineering Task Force) hatte sich geweigert, TLS 1.3 durch das Beibehalten von kompromittierten Krypto-Altlasten zu verwässern. Das Resultat ist ein IETF-Standard, der nahezu alle bekannten Verwundbarkeiten seiner Vorgänger behoben und unzählige Angriffsvektoren unwirksam gemacht hat. Lesen Sie dazu auch unsere Artikelserie zur Transportverschlüsselung (Teil 1, Teil 2, Teil 3).

Mit der Einführung von TLS 1.3 neigt sich aber auch die Ära der Deep Packet Inspection (DPI) in Datacentern ganz offiziell ihrem Ende zu und wird durch Encrypted Traffic Analytics (ETA) ersetzt. Die Abwehr gegen bösartige Datenpakete sollen fortan anstelle althergebrachter DPI-Middleboxen zeitgemäße(re) Sicherheitslösungen für Encrypted Traffic Analytics (ETA) datenschutzfreundlich richten. Einigen Unternehmen, interessanterweise vor allem aus der Finanzindustrie, ist der Mehraufwand ein Dorn im Auge. Mit eTLS hat die europäische Standardorganisation ETSI kürzlich eine eigene TLS-Variante für Middleboxen ins Rennen geschickt, die den bisherigen Status Quo durch die Hintertüre wieder einführen soll: ETSI TS 103 523-3 V1.1.1 (2018-10) (pdf).

Bildergalerie

Stein des Anstoßes

Der wichtigste Stein des Anstoßes an TLS 1.3 (RFC 8446) besteht in der Gewährleistung von Perfect Forward Secrecy mit Chiffren, welche einem Versuch der Echtzeit-Entschlüsselung Widerstand leisten können. Zuvor war es — für Datacenter-Betreiber wie auch für unberechtigte Dritte — möglich, eine TLS-Verbindung passiv mitzulesen und in Echtzeit zu dechiffrieren. Das geht mit TLS 1.3 aber zum Glück nicht mehr. Doch man kann es offenbar nicht jedem recht machen. Den Vertretern des Bankenlobbyverbandes BPI war das Neuland von TLS 1.3 zu ungewiss. Ungeachtet der Cybergefahren verlangten diese Marktteilnehmer nach einem statischen Schlüssel zum Dechiffrieren der Kommunikation.

Rich Salz ist Senior Architect bei Akamai und sprach über eTLS in einem exklusiven Interview mit Security-Insider.

Die TLS-Arbeitsgruppe der IETF habe einen ähnlichen Vorschlag „monatelang intensiv diskutiert“, enthüllt Rich Salz, Senior Architect bei Akamai, im exklusiven Interview mit Security Insider. Schlussendlich habe man die Idee verworfen, weil es keinen Weg gab, sie „sicher“ zu implementieren, also keine Möglichkeit, „ein Opt-In der Betroffenen einzuholen und auch keinen Weg, um eine Massenüberwachung zu verhindern.“

So hat sich die IETF für die Abschaffung statischer RSA- und Diffie-Hellman-Chiffren in TLS 1.3 entschieden und nur Chiffren zugelassen, die Forward Secrecy unterstützen. Die ETSI verzichtet lieber auf die Forward Secrecy durch den Einsatz von nicht-ephemeralen Schlüsseln.

Der Verzicht auf Perfect Forward Secrecy hat enorme praktische Implikationen unabhängig von der verwendeten Chiffre. Sollte ein Angreifer den Kommunikationsaustausch mitgeschnitten und sich nachträglich den Serverschlüssel erschlichen haben, wären die aufgezeichneten Daten allesamt kompromittiert. Im Gegensatz dazu bleibt die Geheimhaltung der Datenübertragung in TLS 1.3 auch beim Verlust des Serverschlüssels gewahrt, da sich die ephemeralen Session-Keys davon nicht direkt ableiten lassen. Sollten auch die Session-Keys in falsche Hände geraten, wären von dem Vorfall beim Einsatz von TLS 1.3 höchstens nur die Daten einer einzigen Benutzersitzung betroffen, nicht der gesamte Kommunikationsaustausch — eigentlich auch ein Vorteil.

Transportverschlüsselung Teil 1

TLS 1.3 - Viel heiße Luft oder ein großer Wurf?

Die Idee von eTLS ist eigentlich recht einfach: Die Kommunikation zwischen der Firewall und der Außenwelt erfolgt unter Verwendung eines ephemeralen Diffie-Hellmann-Schlüssels; im unternehmenseigenen Netzwerk kommt zwar formal auch ein Diffie-Hellman-Schlüssel zum Einsatz, doch einer, der sich nicht mit jeder Sitzung verändert. Dieser statische DH-Schlüssel bleibt dann für Wochen oder gar Monate unverändert. Wer in den Besitz dieses Schlüssels käme, könnte die gesamte Kommunikation dechiffrieren, müsste sie jedoch im Unternehmensnetzwerk mitschneiden. Letzteres ist ja nicht prinzipiell unmöglich — es genügt nur eine Schwachstelle.

eTLS gibt vor, die Erkennung von Malware-Aktivitäten, Datenexfiltrationsattacken und DDoS-Vorfällen zu unterstützen. Im Gegenzug fordert der Standard den Verzicht auf Forward-Secrecy (da intern statische Schlüssel zum Einsatz kommen) und setzt dadurch schutzwürdige Kommunikation aufs Spiel — unnötig, denn die Erkennung von böswilliger Betriebsamkeit zählt ohnehin zum Leistungsumfang von ETA-Lösungen und diese setzen derartige Einschnitte der Cybersicherheit nicht voraus.

eTLS ist insofern kein Patentrezept für Kommunikationssicherheit, sondern ganz im Gegenteil: eine Einladung zur Cyberspionage.

Besonders bedauerlich sei in diesem Kontext die Bezeichnung des Standards, argumentiert Salz, der Cybersicherheitsexperte von Akamai. Die ETSI hat ihn auf den Namen „Enterprise TLS“ getauft — so kommt das Kürzel eTLS zustande. Es sei „bedauerlich“, denn das Protokoll würde die Endpunktsicherheitsgarantie abschaffen, möglicherweise ohne den Client davon in Kenntnis zu setzen. So entstehe aber der implizite Eindruck, dass viele Unternehmen in Zukunft eTLS tatsächlich einsetzen würden. Dabei sind die potenziellen datenschutzrechtlichen Implikationen nicht von der Hand zu weisen.

Transportverschlüsselung Teil 2

Webmaster in der HTTPS-Pflicht

Wer im Glashaus sitzt: die PSD2

Banken in Europa stehen zugegebenermaßen unter enormen Druck, an TLS 1.3 liegt es aber nicht. Wohl aber an neuer, massiver Banken-Regulierung: PSD2 (mehr Wettbewerb durch Open Banking), Mifid II (mehr Anlegerschutz) und Basel IV (neue Kapitalauflagen). Keine Richtlinie ist wie die andere, aber im Hinblick auf die damit verbundenen Cyberrisiken spielt die PSD2 in einer eigenen Liga.

Der europäische Gesetzgeber hat mit der Einführung der PSD2 (EU 2015/2366) die Banken gezwungen, spätestens ab dem kommenden September (2019) ihre eigenen Kundendaten durch die Bereitstellung offener APIs gegenüber eigenen Wettbewerbern offen zu legen. Die Banken müssen die benötigten APIs auf eigene Kosten entwickeln und den eigenen Mitbewerbern praktisch zum Selbstkostenpreis zur Verfügung stellen. Und als ob das noch nicht genug wäre an Anforderungen sind die betroffenen Finanzinstitute auch noch gezwungen, ihre Zahlungsinstrumente über APIs den Wettbewerbern feilzubieten und die Haftung für etwaigen Missbrauch der Daten und Finanzmittel zu übernehmen.

Ob der Verzicht auf eine robuste Transportverschlüsselung so vorteilhaft ist, wenn an den offenen Banken-APIs demnächst Hacker lauschen könnten?

TLS 1.3 ist der sprichwörtliche „Junge zum Prügeln“. eTLS ist ein vergleichsweise durchsichtiger Versuch einiger Interessengruppen, die Forward Secrecy von TLS 1.3 abzuschaffen und zugleich vor dem Artikel 25 der DSGVO „in Deckung zu gehen“. Denn dieser spricht vor „Datenschutz durch Technikgestaltung (...)“ und zwar unter Berücksichtigung „des Stands der Technik“. Ein „neuer“ Standard, so fadenscheinig er auch sein mag, macht sich gut.

Doch mit eTLS würden die Banken vor allem sich selbst ins Knie schießen. Bei der Umsetzung von API-Zugriffen nach der PSD2-Richtlinie unter Verwendung von eTLS ist eine massive Cyber-Katastrophe mit Kontodaten und/oder Finanzmitteln praktisch vorprogrammiert. Der Verlust eines Schlüssels würde genügen, um einen Cybersicherheitsvorfall einer im Bankensektor bisher nie gesehener Größe loszutreten. Es braucht ja wirklich nicht viel. Gerade in einer Zeit, wo Massenentlassungen im Finanzwesen Schlagzeilen machen, dürfte es an verärgerten, verzweifelten oder verängstigten Insidern mit Zugang zu wertvollen Serverschlüsseln nicht mangeln. Die Banken müssen da nicht noch extra nachhelfen.

Transportverschlüsselung Teil 3

HTTPS mit TLS 1.3 in der Praxis

Wenn sich eine Industrie selbst „regulieren“ möchte

Der europäische Gesetzgeber hat den verstärkten Datenschutz bewusst in die DSGVO hineingeschrieben, damit neue Richtlinien für die digitalisierte Wirtschaft und Gesellschaft – wie eben die PSD2 – technisch dann auch überhaupt realisierbar sind.

Die sichere Verschlüsselung bei TLS 1.3 ist nicht ein Selbstzweck, sondern eher ein Mittel zum Zweck. Es geht um die Wahrung des Fortbestands der digitalen Wirtschaft. Im Kontext der Digitalisierung wächst die Notwendigkeit der manipulationssicheren Verwaltung von kritischen Infrastrukturen, virtualisierten Finanzmitteln und anderen Vermögenswerten. Die Daten müssen manipulations- und abhörsicher gehandhabt werden.

Viele Branchenverbände leisten zweifellos eine wertvolle Arbeit, um den Anliegen ihrer Mitglieder Verhör zu verschaffen und sie dienen damit zudem oft auch der Allgemeinheit. Doch die Fähigkeit zur Selbstregulierung einer Branche weist immer gewisse Grenzen auf, weil es ja zu Interessenskonflikten kommen kann und das ist offenbar hier der Fall gewesen.

An der falschen Schraube gedreht

Angesichts der rasch steigenden Rechenleistung hat auch TLS 1.3 eine beschränkte Haltbarkeitsdauer. Sollte das Quantencomputing mit Sieben-Meilen-Stiefeln vorankommen, könnte der Tag, wo auch dieser Standard einen Nachfolger braucht, schneller kommen, als es allen legitimen Beteiligten lieb sein mag. Das ist aber noch kein Grund, um auf Forward Secrecy verzichten zu wollen.

Die ETSI selbst ist wohl kaum ein Aushängeschild für Cybersicherheit. Die Organisation setzt auf der eigenen Webseite unter etsi.org zwar bereits TLS 1.3 ein. Doch warum die mehrfach kompromittierten TLS-Protokollversionen 1.0 und 1.1 auch noch aktiviert sind, entzieht sich jeglicher Begründung. Der Wunsch nach mehr Kompatibilität kann nicht der Grund gewesen sein. Auch die Verwendung eines RSA-2048-Bit-Zertifikats mit einem SHA1-RSA-Schlüssel wirft kein gutes Licht auf die Konfiguration. Immerhin haben unter anderem CWI-Institute und Google die Wirksamkeit einer Kollisionsattacke gegen SHA1 nachgewiesen.

Tief im Rechenzentrumsnetz

Encrypted Traffic Analytics (ETA) im Datacenter ersetzt Deep Packet Inspection

Fazit

Diverse Interessengruppen hatten es versucht — zum Glück vergeblich —, die Einführung von Forward Secrecy in TLS-1.3 abzuwenden. Mit eTLS sind sie dennoch ans Ziel gelangt: durch die Hintertüre eines ETSI-Standards.

eTLS hat das Potenzial, die Vorsätze der DSGVO auszuhebeln. Der Implementierungsstandard dürfte nebenbei auch die Wirtschaftsspionage dramatisch vereinfachen — ein schauerlicher Gedanke im Kontext der PSD2-Richtlinie. eTLS ist ein sicher gut gemeinter Standard, aber mit großem Missbrauchspotenzial. Der Einsatz statischer DH-Zertifikate läuft auf einen Blankoscheck für Cyberkriminalität hinaus — ein Ergebnis, das niemand wirklich braucht.

Über die Autoren: Filipe Pereira Martins und Anna Kobylinska arbeiten für McKinley Denali Inc. (USA) und sind als IT-Consultants auf Cybersecurity spezialisiert.

(ID:45641941)