EBICS und TLS 1.2 – etwas sicherer, aber nicht ohne Tücken

Curd Reinert, Projektleiter EBICS-Kernel, PPI AG


Wer einen Blick in die aktuelle EBICS-Spezifikation wirft, stellt womöglich überrascht fest, dass dort für die Transport Layer Security (TLS) noch die Version 1.0 vorgeschrieben ist. Das war mal eine sehr kluge Wahl: Bei Veröffentlichung der EBICS-Spezifikation war TLS 1.0 der Stand der Technik. Man hat sich also vor allem gegen SSL entschieden. Und damit waren die Hersteller und Betreiber z. B. bei POODLE fein raus: EBICS schließt SSL aus, die EBICS-Anwendungen waren vor POODLE sicher. Ohnehin hätte POODLE bei einem EBICS-Client kaum eine Chance: Der Angreifer bringt den Client dazu, tausende Anfragen an den HTTPS-Server zu schicken, um z. B. an das Session-Cookie zu kommen. Bei EBICS wird aber weder ein Session-Cookie genutzt, noch sind die Clients Web-Anwendungen, die man per JavaScript dazu bringen kann, tausende Anfragen zu schicken. Aber erklären Sie das mal der Revision!


Und das war ja auch nur einer der bösen Angriffe mit den lustigen Namen: HEARTBLEED nutzte einen Fehler in der TLS-Implementierung von OpenSSL aus. Und dann ist da noch BEAST. Wie schon bei POODLE eignet sich EBICS auch nicht für den BEAST-Angriff. Aber der Ruf von TLS 1.0 ist nachhaltig beschädigt, und alle Seiten raten zum sicheren Nachfolger TLS 1.2.

Das hat man auch bei EBICS erkannt und entsprechende Change Requests für die nächste Version vorgesehen, um TLS 1.2 zu unterstützen. Leider verzögert sich diese nächste Version, und in der Zwischenzeit fragen die Revisoren: Wieso macht ihr mit EBICS noch TLS 1.0? „Weil es so in der Spezifikation steht“, reicht als Argument kaum noch aus, wenn das BSI offiziell vor dieser Version warnt. Auf der offiziellen EBICS-Seite stehen darum jetzt Sicherheitsempfehlungen, die zu TLS 1.2 raten – ohne zu erklären, wie sich das mit der Spezifikation vereinbaren lässt.

Wir haben 82 EBICS-Server in Deutschland und Frankreich getestet: Gerade einmal 52 Server konnten mit uns TLS 1.2 sprechen. Wenn Sie sich also als Kundenprodukthersteller heute dazu entschließen, TLS 1.0 gar nicht mehr zu unterstützen, dann können Sie sich mit ca. einem Drittel der EBICS-Server nicht mehr verbinden. Server-Betreibern dürfte es mit den Kundenprodukten in den unterschiedlichsten Versionen noch schlechter ergehen.



Was kann man dann tun? Man kann TLS 1.2 anbieten, ohne TLS 1.0 zu verbieten. Das geht sowohl als Client als auch als Server, und im TLS-Handshake einigen sich beide Seiten auf die sicherste gemeinsame Variante – so die Theorie. Bei immerhin 28 der getesteten Server hat das auch funktioniert. Leider haben wir aber auch zwei Server gefunden, die die Kommunikation rigoros abbrechen, wenn der Client TLS 1.2 vorschlägt. Das ist für die Hersteller von Kundenprodukten sehr unangenehm, weil die Clients dann nicht einfach „auf Verdacht“ TLS 1.2 vorschlagen können – oder sie nehmen in Kauf, dass die Kommunikation mit einigen wenigen Servern scheitert.

Wir haben die Betreiber der beiden EBICS-Server benachrichtigt. Da unser Test aber nicht alle EBICS-Server umfasst, sollte jeder Betreiber das Verhalten seines EBICS-Servers selbst prüfen.
Eine Frage drängt sich noch auf: Wie gefährlich wäre eine Entschlüsselung des TLS-Layers in EBICS überhaupt; welche Daten wären sichtbar? Die Auftragsdaten selber werden ein zweites Mal verschlüsselt und bleiben für den Angreifer unsichtbar. Es bleibt der XML-Rahmen um die Auftragsdaten, oder wie man es in der Post-Snowden-Ära nennt: Metadaten. Das sind vor allem die Auftragsart bzw. das Fileformat, die Kunden- und die Teilnehmer-ID. Mit anderen Worten: nicht besonders viel. Ob man damit die Gemüter beruhigen kann, steht auf einem ganz anderen Blatt.

Curd Reinert

0 Kommentare:

Kommentar veröffentlichen