Forward Secrecy zu sicher für die Banken

Ein weiteres problematisches Verfahren, das in TLS 1.3 ersetzt wird, ist der Handshake mittels RSA-Verschlüsselung. Das TLS-Protokoll unterstützte beim Handshake in der Vergangenheit zwei Varianten: einen Schlüsselaustausch, der vom Zertifikat des Servers nur signiert war - mittels RSA oder ECDSA -, und eine Variante, bei der ein Geheimnis direkt mit RSA verschlüsselt wurde. Nur die erste der beiden Varianten - der Schlüsselaustausch - bietet Forward Secrecy.

Forward Secrecy bedeutet, dass die Verschlüsselung selbst dann noch geschützt ist, wenn der langfristige Serverschlüssel, der Teil des Zertifikats ist, kompromittiert wird. Ein großer Vorteil: Selbst wenn ein Angreifer nachträglich den Server hackt oder auf andere Weise an den geheimen Schlüssel kommt, ermöglicht das nicht das Entschlüsseln von Verbindungen aus der Vergangenheit. Der Handshake mittels RSA-Verschlüsselung hat diese Forward-Secrecy-Eigenschaft nicht.

Ein weiteres Problem der RSA-Verschlüsselung sind Bleichenbacher-Angriffe. Der Kryptograph Daniel Bleichenbacher entdeckte diesen Angriff bereits 1998. TLS enthält Gegenmaßnahmen gegen Bleichenbacher-Angriffe, diese sind jedoch ausgesprochen umständlich. Im Fall einer fehlerhaften Entschlüsselung muss eine TLS-Implementierung den Handshake mit Fake-Daten weiterführen und darf ihn nicht vorzeitig abbrechen. Auch diese Workarounds sind anfällig gegen Timing-Angriffe. Dass nicht alle Implementierungen diese Gegenmaßnahmen korrekt durchführten, konnte 2014 ein Team der Fachhochschule Münster und der Ruhr-Universität Bochum zeigen. Eine Variante des Bleichenbacher-Angriffs führte auch zur Drown-Attacke, die Schwächen im Uralt-Protokoll SSL Version 2 ausnutzte.

Eine besondere Eigenschaft der Bleichenbacher-Angriffe könnte auch zukünftig zu Problemen führen: Wenn ein entsprechender Fehler vorhanden ist, reicht es bereits, wenn ein Server die entsprechenden Verfahren unterstützt, sie müssen nicht zum Einsatz kommen. Ein Angreifer kann möglicherweise die Tatsache, dass ein Server den RSA-Handshake mit TLS 1.2 anbietet, ausnutzen, um eine Verbindung mit TLS 1.3 anzugreifen. Auf dieses Problem wiesen im vergangenen Jahr Forscher der Universität Bochum hin.

Banken protestieren gegen zu viel Sicherheit

Die Entfernung des RSA-Handshakes war eine der ersten Entscheidungen bei der Entwicklung von TLS 1.3. Sie wurde von allen Beteiligten uneingeschränkt begrüßt. Doch vor kurzem meldete sich ein Vertreter einer Lobbyorganisation der Finanzbranche und äußerte Bedenken. In vielen Banken nutze man intern TLS mit dem RSA-Handshake, um auf Netzwerkebene den Datenverkehr entschlüsseln zu können. Das ist mit Verfahren, die Forward Secrecy nutzen, so nicht mehr möglich. TLS 1.3 ist schlicht zu sicher für diesen Anwendungszweck.

In der TLS-Arbeitsgruppe fand die Bankenlobby mit ihrem Einwand wenig Freunde. Kenny Paterson wies darauf hin, dass die Bankenlobby reichlich spät dran sei mit ihren Einwänden. Die Party sei fast vorbei, und man sei nur noch damit beschäftigt, leere Bierdosen einzusammeln und Aschenbecher zu leeren.

RSA-Signaturen mit PSS

Dass der RSA-Verschlüsselungs-Handshake aus dem Protokoll gestrichen wird, bedeutet nicht das Ende von RSA in TLS. Zertifikate mit RSA-Schlüsseln können weiterhin für einen Forward-Secrecy-Handshake als Signaturverfahren genutzt werden.

Auch dabei gibt es jedoch eine Änderung: Bisher nutzte TLS als Padding-Verfahren für RSA ausschließlich das veraltete PKCS #1 1.5. Dieses Signaturverfahren hat ebenfalls eine Schwäche, die auch von Bleichenbacher entdeckt wurde. Sie betrifft allerdings nur fehlerhafte Implementierungen. Eine Variante dieses Bleichenbacher-Signaturangriffs ist der BERserk-Angriff. Statt PKCS #1 1.5 kommt das Padding-Verfahren PSS (Probabilistic Signature Scheme) zum Einsatz, das keine derartige Schwäche hat.