TLS 1.3 könnte PFS aushebeln

TLS-Verschlüsselung kontra Netzwerk-Monitoring

| Redakteur: Peter Schmitz

Ein IT-Sicherheitsexperte mahnt: Die Degradierung des Diffie-Hellman-Verfahrens in TLS zum Zwecke eines Netzwerk-Monitorings wäre eine reine Abhörmaßnahme.
Ein IT-Sicherheitsexperte mahnt: Die Degradierung des Diffie-Hellman-Verfahrens in TLS zum Zwecke eines Netzwerk-Monitorings wäre eine reine Abhörmaßnahme. (Bild: Pixabay / CC0)

Die Arbeiten am Verschlüsselungsprotokoll TLS 1.3. sind fast beendet und TLS 1.3 ist kurz davor in die Standardisierungsphase zu gehen. Ausgerechnet jetzt streiten jedoch Gegner und Befürworter über einen möglichen "Nachschlüssel" für TLS-verschlüsselte Verbindungen in Rechenzentren. Security-Experten warnen: Das neue Verfahren könnte die Perfect Forward Secrecy (PFS) aushebeln.

Während des 99. IETF-Meetings in Prag kam ein Entwurf auf den Tisch, der als Erweiterung für TLS 1.3 eingesetzt werden soll und das Einsetzen des Verschlüsselungsprotokolls in Rechenzentren beschreibt. Konkret geht es um einen Entwurf zu Data Center use of Static Diffie-Hellman in TLS 1.3 (pdf) und wie das von TLS 1.3 geforderte Diffie-Hellman-Verfahren so degradiert werden kann, dass ein passives Netzwerk-Monitoring möglich ist. „Das ist eine reine Abhörmaßnahme, die da im Standard festgeschrieben werden würde. Mit ihrem sehr knappen Voting dagegen hat die IETF dem aber einen Riegel vorgeschoben. Denn das vorgeschlagene Prinzip würde das Krypto-Verfahren Perfect Forward Secrecy (PFS) einfach aushebeln“, kritisiert Christian Heutger, Geschäftsführer der PSW Group.

Insbesondere Banken, aber auch andere Großkonzerne, sind per Gesetz dazu verpflichtet, den eigenen Netzwerkverkehr zu überwachen. Das soll helfen, Manipulationen durch Mitarbeiter aufdecken zu können. Die mittels TLS 1.3 eingeführten Pläne würden es Betreibern riesiger Rechenzentren erschweren, auf Fehlersuche zu gehen und diese zu beheben. Die so verursachten längeren Zeiten für die Fehlersuche und -behebung würden einem DDoS-Angriff gleichen. Beispielsweise könnte der Traffic auf Firewall-Applikationen, Load-Balancern oder weiteren Fronting-Servern, die dem Serverendpunkt der TLS-Verbindung vorangehen, durch die Verschlüsselung bei einem Fehler unzureichend analysiert werden.

Dieses Problem soll nach dem Willen einiger Konferenz-Teilnehmer direkt auf der Ebene des TLS-Protokolls gelöst werden. Dafür wurde ein “statischer Diffie-Hellman-Schlüssel“ vorgeschlagen. Dieser wird auf dem TLS- oder auf einem zentralen Key-Management-Server erzeugt und dann im Rechenzentrum weiterverteilt. Anstelle des eigentlichen vom Server generierten Schlüssels wird ein „statischer Schlüssel“ gemeinsam mit zufälligen Nonce-Werten zum Aufbauen der Verbindungen verwendet. Diesen könnten Betreiber von Rechenzentren dafür verwenden, den internen Traffic zur weiterführenden Analyse beim Fehlersuchen zu entschlüsseln. Damit geht aber auch die wichtigste Eigenschaft von Diffie Hellman verloren: die Perfect Forward Secrecy.

„Die Umsetzung von Perfect Forward Secrecy ist aber eines der Hauptziele von TLS in der Version 1.3. Damit dieses Prinzip erhalten bleiben kann, müssen die Schlüssel je Sitzung neu generiert werden. Dies ist bei Verwendung statischer Schlüssel nicht konsequent möglich“, kritisiert Christian Heutger. Perfect Forward Secrecy verhindert durch Bildung eines Sitzungsschlüssels das nachträgliche Entschlüsseln. Selbst wenn der Serverschlüssel als Zertifikatteil kompromittiert wird, bleibt die Verschlüsselung geschützt.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44851994 / Verschlüsselung)