SSL über SOAP
Tags: soa
Kategorie Promotion | 3 Kommentare »
Inzwischen bin ich zurück von meinem Urlaub. Vor meinem Urlaub war ich auf der „European Conference on Web Services (ECOWS)“ in Halle und dem zugehörigen Workshop über „Emerging Web Services Technology (WEWST)“. Es gab da noch einige interessante Beiträge, so zum Beispiel über eine SSL Implementierung auf Basis von SOAP. Den zugehörige Vortrag „SSL-over-SOAP: Towards a Token-based Key Establishment Framework for Web Services“ von Gajek, Liao, Schwenk und Moeller
fand ich sehr interessant, weil er ein Problem angesprochen hat, das zeigt, dass wir noch ganz am Anfang mit SOA sind…
Der Vortrag „SSL-over-SOAP: Towards a Token-based Key Establishment Framework for Web Services“ von Gajek, Liao, Schwenk und Moeller beschäftigte sich mit der Frage, wie ein Schlüssel zwischen zwei Kommunikationspartnern vereinbart werden kann, die im Rahmen einer SOA verschlüsselt über SOAP miteinander kommunizieren wollen. Dies ist eine wichtige Fragestellung, denn wenn kein Schlüssel (Geheimwort) vereinbart werden kann, dann nützen einem Verschlüsselungsstandards wie XML Encryption und XML Signature auch nichts.
Die Verschlüsselung basiert prinzipiell auf der Idee, dass man den Klartext mit einem Geheimwort so verknüpft, dass der erzeugte Text nicht mit sinnvollem Aufwand wieder in den Klartext überführt werden kann, wenn man das Geheimwort nicht kennt. Wie genau die Verknüpfung von Klartext und Geheimwort funktioniert, regelt der verwendete Verschlüsselungsalgorithmus. Wird eine Nachricht von einem Sender verschlüsselt und auf der anderen Seite von einem Empfänger entschlüsselt, dann müssen beide Seiten natürlich das Geheimwort kennen. Das Geheimwort kann man nun natürlich nicht als eigene Nachricht im Klartext austauschen, da ein Angreifer sonst natürlich nur dieses Geheimwort abfangen muss. Für die Lösung dieses Problem gibt es verschiedene Verfahren, aber es gibt bislang kein Verfahren, dass auf SOAP aufsetzt und damit im Rahmen einer technischen SOA sofort einsetzbar ist. Dies ist verwunderlich, da es zum Beispiel für die Verschlüsselung und Signieren von SOAP Nachrichten diverse Standards gibt, wie zum Beispiel XML Signature.
In ihrem Paper stellen nun Gajek et al. vor, wie sie das Handshake-Verfahren von SSL auf SOAP portiert haben. Ich muss zugeben, dass ich nicht alle Einzelheiten verstanden habe. Was ich aber verstanden habe ist, dass es sowas bis heute noch nicht in standardisierter Form gibt. Das finde ich persönlich erschreckend, denn es ist eine Grundvoraussetzung, damit man kommerzielle Web Services anbieten kann. Dies zeigt letztendlich, dass die ganze SOA Sache noch ziemlich am Anfang ist und es noch einige Jahre dauern wird, bis diese Technologie vollständig einsetzbar ist.
Leider stehen die meisten kommerziellen Web Services, die man „mal so“ konsumieren kann nur via SOAP über HTTP zur Verfügung. Dann kann man auch SOAP über HTTPS machen und ist aus dem Schneider. Im eigenen Unternehmen, dort wo man End-to-End QoS konfigurieren möchte und möglicherweise auch andere Transporte als HTTP(S) verwendet, sind solche Schlüssel ja bekannt (hinter dem Schlüssel verbirgt sich ja ein Trustmodell – wenn zwei WS einfach einen Schlüssel vereinbaren, woher weiß ich dass ich dem Dienst vertrauen kann?).
Insofern: Interessante Idee, aber ich halte es nicht für eine kritisch fehlende Komponente im WS-* stack.
HTTPS ist keine Lösung, da es auf einer ganz anderen Abstraktionsebene greift. Stell dir vor, du willst über einen Web Service irgendwas mit Kreditkartendaten oder Bankdaten machen. Dann kann es sein, dass der Web Service zwar die Bankdaten lesen können soll, aber vielleicht nicht die Kreditkartennummer. Deshalb möchtest du einen Teil der Nachricht verschlüsseln, einen anderen Teil nicht. Würdest du jetzt über HTTPS gehen, könntest du nur die gesamte Nachricht verschlüsseln. Auch greift HTTPS ja viel früher, nämlich schon beim Application Server. Damit könnte aber jeder Admin, der Zugang zum Server hat, bereits die Kreditkartendaten lesen, selbst wenn dies eigentlich erst in der Applikation möglich sein sollte.
Ansonsten hast du natürlich Recht, dass im Unternehmenskontext die Schlüssel oftmals über andere Wege ausgetauscht werden können und man so das Problem umgehen kann.
Ja, das ist genau das, was ich mit End-to-End QoS meinte. Wenn du mehrere Intermediaries hast, die den Inhalt nicht lesen dürfen, brauche ich message level security. Allerdings ist dann ein automatischer Schlüsselaustausch auch nicht sehr so sinnvoll.