21.09.2011 10:30

Aktueller Angriff auf SSL / TLS1.0

Aktuell wird in einigen Online-Medien über einen Angriff auf SSL/TLSgeschrieben, siehe etwa The Register, Threatpost oder Heise.

Wir sind am recherchieren, was jetzt schon bekannt ist. Der Vortrag ist für Freitag, den 23. September angekündigt, ab dann sollten gesicherte Informationen vorliegen.

Aktuell stellt sich die Lage so da (Achtung: das stimmt vielleicht nicht 100%ig, da ist noch Raten dabei):

  • Das zugrunde liegende Problem in TLS1.0 ist schon lange bekannt. Siehe openssl oder dieses Paper. Neu scheint zu sein, dass der bislang theoretische Angriff jetzt in der Praxis funktioniert.

  • TLS 1.1 und 1.2 korrigieren das Problem, sind aber aus Kompatibilitätsgründen noch nicht wirklich im Einsatz.

  • Der Angriff basiert darauf, dass neben der anzugreifenden TLS Verbindung der Browser sich von irgendwo anders Javascript eintritt, das dann TLS-Requests an das Ziel absetzt. Diese werden in die bestehende TCP/TLS Session hineingemultiplext (Connection-Keepalive!) womit das JavaScript known-plaintext in die anzugreifende session injiziert. Der Abhörende kann damit Parameter der Verschlüsselung ermitteln.

  • Es gibt mehrere Theorien, was damit möglich ist:

    • Der know-plaintext Angriff ist voll erfolgreich und das Schlüsselmaterial der Session kann ermittelt werden, und diese so voll entschlüsselt werden.

    • Die injizierten HTTPS-Requests bekommen vom Browser gültige Session-Cookies (analog zu cross-site request forgery-attacks), wenn man die richtig an blockgrenzen schiebt, kann man hier Zeichen für Zeichen das cookie ermitteln (das mag dann ein bisschen wie blind-sql-injection funktionieren).

  • Abwehr: Das ist jetzt noch sehr spekulativ.

    • Connection-Keepalive abdrehen mag helfen, geht aber ernsthaft auf die Performance.

    • Blockcipher in CBC-mode ist das Problem: TLS erlaubt hier durchaus auch andere Methoden; wie sehr die in allen Browsern und Servern unterstützt werden, ist mir nicht klar.

    • Der Browser limitiert, welche Requests für eine offene TLS Session in Frage kommen. (etwa: alle, die aus http oder nicht-same origin kommen, dürfen das nicht)

    • Der Browser könnte das Muster der tausenden ajax-requests erkennen und unterbinden.

    • TLS 1.1 Das wird dauern und wird nicht ohne Schmerzen gehen.

    • Der Angriff scheint darauf zu basieren, dass der Cookie-Header an Blockgrenzen ausgerichtet wird. Ein zufälliges Umsortieren der Request-Header mag hier auch etwas helfen.

    • In die gleiche Kerbe würde ein X- Header nach dem GET/POST schlagen, der ein zufällige Zahl an Zeichen einfügt.

    • Random padding blocks in die TLS connection einbauen.

  • Weitere Links dazu: IETF TLS Liste, ycombinator, OpenSSL

  • Was kann man jetzt tun?

    • Aktuell sind wir in dem Zeitfenster, wo alle wild spekulieren und nur wenig harte Informationen vorliegen. Ich rate daher vor Schnellschüssen ab, das Ganze ist noch keine akute Gefahr.

    • Relevant wird werden, was im nächsten Monat die Browserhersteller und die Serversoftwareschreiber an Empfehlungen abgeben. Die sind schon vorab informiert gewesen, stehen aber noch unter NDA. Das sollte mit der Publikation am Freitag vorbei sein, ich erwarte daher kurz darauf fundierte Aussagen von Mozilla, Google, Apache & co.

Autor: Otmar Lendl