Lobster Experten Fragen

AS2

AS2 steht für Applicability Statement 2. Zu deutsch: Verwendbarkeitserklärung 2. Toller Begriff, oder? Sagt so irgendwie …. gar nix. Aber das kann man ja nachlesen.

Im RFC2026 „The Internet Standards Process“ erfahren wir dazu:

An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 7.

An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required, recommended, or elective (see section 3.3).

Und TS wiederum steht für „Technical Specification“. So, jetzt sind wir alle wesentlich schlauer. ;-)
Da wird immer auf Juristendeutsch geschimpft…
Kurz zusammengefasst beschreibt also ein Applicability Statement, wie man (meist mehrere) technische Standards nutzt und miteinander kombiniert, um eine bestimmte Funktionalität im Internet zu erreichen.

Gehen wir die Sache praktisch an und fragen uns einfach mal:

Was ist AS2?

AS2 ist ein Übertragungsverfahren, das speziell für den Austausch von Geschäftsdaten entwickelt wurde. Dementsprechend hat man hier von Anfang an Wert auf Dinge wie Sicherheit und Nachweisbarkeit gelegt. Sicherheit wird durch Verschlüsselung und Signatur erreicht, die Nachweisbarkeit durch Empfangsbestätigungen (sogenannte MDNs).
Die Basis bildet HTTP bzw. HTTPS. Damit hat man den Vorteil, dass die Antwort auf eine Übertragung sofort (synchron) noch in derselben Verbindung gegeben werden kann. Außerdem ist das HTTP-Protokoll praktisch überall einsetzbar und nur in seltenen Fällen von Firewalls geblockt. Mit HTTPS (also SSL bzw. TLS) hat man zugleich eine Grundverschlüsselung der gesamten Kommunikation. Im Unterschied zu einfachem HTTP gibt es bei AS2 aber für Daten nur die Sende-Richtung (bei HTTP wäre das ein POST oder PUT), aber keinen Download von Dateien wie bei einem HTTP GET (es kommt höchstens eine kleine Empfangsbestätigung zurück).
Das ist aber noch nicht alles. Wie schon bei SSL, so kommen nun noch weitere Zertifikate zum Einsatz. Die Daten werden noch mal extra verschlüsselt und signiert. Hier wird der S/MIME-Standard genutzt. Und: Es gibt eine Empfangsbestätigung. Aber eines nach dem anderen.

Intermezzo: Zertifikate

Erst mal kurz zu diesen Zertifikaten:
Ganz vereinfacht arbeiten Zertifikate (wir sprechen hier speziell von Public-Key-Zertifikaten) mit einem genialen mathematischen Kunstgriff, nämlich der sogenannten asynchronen Verschlüsselung. Dieses Verfahren nutzt zwei Schlüsseln (große Zahlen), wobei man immer einen Schlüssel zur Verschlüsselung verwenden kann, dann aber den anderen zur Entschlüsselung braucht. Man kann also denselben Schlüssel, mit dem verschlüsselt wurde, nicht wieder zur Entschlüsselung einsetzen.
Das praktische daran ist: Einen der beiden Schlüssel kann man veröffentlichen (das ist der „Public Key“), damit jedermann Daten, die er einem schicken will, damit verschlüsseln kann. Und niemand, nicht mal er selbst, kann die Daten wieder entschlüsseln. Man selbst kann dies aber mit dem anderen Code, den man für sich behalten hat (sinnigerweise „Private Key“ genannt), durchführen.
So kann sichergestellt werden, dass wirklich nur der Adressat der Sendung diese auch lesen kann.
Umgekehrt funktioniert das auch. Verschlüsseln Sie etwas mit Ihrem privaten Schlüssel, kann es nur mit Ihrem öffentlichen wieder lesbar gemacht werden. So ist garantiert, dass die Daten auch wirklich von Ihnen stammen (solange der private Schlüssel niemandem in die Hände gefallen ist…). Diese Umkehrung macht man sich bei der sogenannten Signatur zu Nutze. Nur wird dabei nicht die ganze Nachricht verschlüsselt. Stattdessen wird ein sogenannter Hashwert über die Daten gebildet (eine Art Kennzahl, simpelstes Beispiel wäre eine Quersumme) und nur dieser Wert mit dem privaten Schlüssel codiert. Der Empfänger bildet über die Daten denselben Hashwert (setzt also denselben Algorithmus ein), entschlüsselt den Wert des Senders und vergleicht. Stimmen beide Werte nicht überein, wurden entweder die Daten manipuliert oder der angebliche Absender stimmt nicht. Auf jeden Fall stinkt das, was er da bekommen hat, und er kann es zurückweisen.
Zertifikate enthalten den öffentlichen Schlüssel eines solchen Schlüsselpärchens und ein paar Metadaten (wem gehört das Ding, für welchen Server gilt es, solche Sachen). Außerdem kann das Zertifikat darüber informieren, dass (und von wem) es beglaubigt wurde, man ihm also vertrauen kann.
Das muss man wissen, um das Prinzip von AS2 zu verstehen.

So läuft es bei AS2

Spielen wir das alte Alice-und-Bob-Spiel. Alice will Daten per AS2 an Bob senden. Folgende Schritte finden während der Übertragung statt:

  1. Alice bildet einen Hashwert über die Daten und signiert diesen mit ihrem privaten Schlüssel.
  2. Alice verschlüsselt die Daten (plus den signierten Hashwert) mit Bobs öffentlichem Schlüssel.
  3. Alice baut eine HTTP- oder HTTPS-Verbindung zu Bob auf.
  4. Im Falle HTTPS wird die ganze Übertragung noch mal extra verschlüsselt, darauf gehen wir hier nicht näher ein.
  5. In diversen speziellen HTTP-Headern werden die Kennungen (Seriennummern) der verwendeten Zertifikate mitgesendet, außerdem die AS2-Kennungen von Sender und Empfänger.
  6. Der reine HTTP-Empfang kann an dieser Stelle schon mal bestätigt werden, falls die offizielle Empfangsbestätigung erst später folgt.
  7. Bob entschlüsselt die Übertragung mit seinem privaten Schlüssel. Welchen er nehmen muss, steht ja im HTTP-Header.
  8. Bob bildet einen Hashwert über die entschlüsselten Daten, entschlüsselt Alices Hashwert mit ihrem öffentlichen Schlüssel und vergleicht die beiden.
  9. Bob entscheidet, ob er Alice den Empfang positiv oder negativ bestätigen will (negativ z.B., wenn er Manipulation vermutet oder die ganze Entschlüsselung schief ging).
  10. Die Empfangsbestätigung (Message Disposition Notification, MDN) kann mit Bobs privatem Schlüssel signiert werden.
  11. Bob schickt die MDN an Alice, synchron (als Antwort auf Alices HTTP-Request) oder asynchron (in einer neu aufzubauenden HTTP-Verbindung, diesmal von Bob zu Alice).

Dieser Ablauf ist sehr schön schematisch in einem Bild des Wikipedia-Artikels zu AS2 dargestellt.
Übrigens: Wenn Sie sich fragen, wozu denn noch die HTTPS-Verschlüsselung gebraucht wird, wenn AS2 dies doch sowieso schon vornimmt: AS2 verschlüsselt die Daten, aber nicht die HTTP-Header. So kann noch jeder mitlesen, wer an wen mit welchen Zertifikaten Daten schickt (und noch ein paar andere Kleinigkeiten). HTTPS verschlüsselt auch noch diese Metadaten.
Davon abgesehen ist bei AS2 die Verwendung von Verschlüsselung und Signatur nicht zwingend vorgeschrieben. Man kann das auch weglassen. Wenn man dabei nicht wenigstens HTTPS verwendet, kann man seine Daten auch gleich in die Zeitung setzen…

Die MDN

Die MDN ist ein wichtiger Bestandteil von AS2 und muss deshalb näher erläutert werden.
In einer MDN steht die Nachrichten-ID der Datenübertragung drin, die bestätigt werden soll. Diese ID hat der Absender (bei uns Alice) in einem HTTP-Header mitgeliefert. Also heißt die MDN ganz einfach: Danke, ich habe Deine Nachricht Nr. xyz erhalten, konnte sie entschlüsseln und als (sehr wahrscheinlich) authentisch einstufen. Oder sie sagt, dass die Daten korrupt waren, ein benutztes Zertifikat unbekannt oder was auch immer. Bei einer negativen MDN spricht man verkürzt von einer NDN.
Diese Information ist für den Versender wichtig. Das ist wie mit einem Einschreiben mit Rückschein, an diesem Punkt geht die Verantwortung für die Daten auf den Empfänger über. Er bestätigt, sie sauber erhalten zu haben. Wenn danach etwas schief geht, ist der Absender aus dem Schneider.
Ob die MDN nun sofort als Antwort auf den HTTP-Request rausgeht, in dem die Daten reinkamen, oder erst ein paar Minuten oder gar Stunden später als eigenständige Übertragung, ist für diesen Zweck unerheblich. Manchmal wird auch die reine HTTP-Übertragung von einem System erledigt, das Entschlüsseln und der Signatur-Check aber erst später von einem anderen. Deshalb gibt es die Wahlmöglichkeit zwischen synchronen und asynchronen MDNs. Eine synchrone MDN geht direkt als HTTP Response auf den HTTP Request raus, mit dem die Daten geschickt wurden. Eine asynchrone MDN dagegen wird in einem eigenen HTTP Request an den Absender der Daten zurückgeschickt.
Allerdings kann der Empfänger nicht einfach so entscheiden, dass er seine MDN erst später schicken mag. Im Gegenteil, der Absender ist derjenige, der dem Empfänger vorschreibt, wie er seine MDN haben will. Und falls der Absender eine asynchrone MDN anfordert, dann gibt er dem Empfänger auch gleich die URL mit, an die diese MDN dann geschickt werden soll. Jede dem Standard genügende AS2-Software beherrscht beide Varianten.

Was Sie für AS2 brauchen

Wenn Sie mit Ihren Partnern Daten via AS2 austauschen wollen, brauchen Sie (und Ihre Partner) zumindest folgendes:

  • Eine AS2-Kennung pro Teilnehmer (die können Sie selbst festlegen, bzw. jeder Teilnehmer legt seine fest).
  • Ein Zertifikat pro Teilnehmer (es können für Signatur und Verschlüsselung auch unterschiedliche verwendet werden, dann wären es zwei Zertifikate pro Teilnehmer). Es geht zwar auch ohne, das ist aber nicht der Sinn von AS2.
  • Die öffentlichen Schlüssel aller Zertifikate, die ihre Partner verwenden.
  • Und natürlich eine AS2-fähige Software.

Zertifikate generiert man selbst, es gibt diverse Software auf dem Markt, und eine gute AS2-Software kann das sicher auch. Allerdings kann es passieren, dass Ihre Partner eine Software einsetzen, die auf signierten (also von Verisign oder ähnlichen Stellen als glaubwürdig abgezeichneten) Zertifikaten besteht. Das Signieren kostet dann. Ausgetauscht werden die Zertifikate im Vorfeld. Da nur die Zertifikate mit dem öffentlichen Schlüssel ausgetauscht werden, kann man sie einfach per E-Mail verschicken.
Bei der Software sollten Sie auf eine sogenannte Drummond-Zertifizierung achten. Die Drummond Group definiert Testaufgaben (Testcases), die alle an einer Testrunde teilnehmenden AS2-Systeme miteinander meistern müssen. Nur, wer mit allen anderen Teilnehmern alle geforderten Aufgaben fehlerfrei durchspielen kann, bekommt das Gütesiegel der Drummond Group. Ein sehr aufwendiges (und kostspieliges) Verfahren. Dabei müssen sogar mehr Testkriterien erfüllt sein, als der RFC 4130 (in dem AS2 beschrieben ist) festlegt. Fragen Sie einfach beim Hersteller der Software an, ob er ein Drummond-Zertifikat vorweisen kann.

Vorteile

  • Durch HTTP haben Sie sofort eine Bestätigung, dass die Übertragung an sich funktioniert hat (zumindest den HTTP Response Code).
  • Die MDN bestätigt darüber hinaus, dass die Daten sauber empfangen werden konnten und normalerweise auch, dass Entschlüsselung und Signaturcheck passten. Je nach Anforderung synchron oder asynchron.
  • Die Daten werden verschlüsselt, was sicherstellt, dass nur der gewünschte Empfänger sie lesen kann.
  • Die Signatur wiederum garantiert, dass weder Inhalt noch Absender manipuliert wurden.
  • HTTPS setzt noch mal ein Stückchen mehr Sicherheit obendrauf.
  • Durch alle vorgenannten Sicherheitsmechanismen kann die Übertragung kostengünstig über das freie Internet erfolgen, es ist weder ISDN noch ein VAN nötig.

Nachteile

  • Eine gute (möglichst Drummond-zertifizierte) AS2-Software kostet Geld.
  • Falls einer der Partner auf signierten Zertifikaten besteht, kosten diese ebenfalls etwas Geld.

Was die Kosten angeht, kann man sagen, dass ab einer nennenswerten Anzahl Übertragungen pro Monat das Geld für die Software (und evtl. die Zertifikate) schnell wieder hereinkommt. Bei ISDN-basierten Verfahren (wie OFTP) oder VANs (wie X.400) kostet jede Übertragung extra, während die AS2-Kommunikation über Ihre ganz normale Internet-Flatrate läuft. Wie hoch diese „nennenswerte Anzahl“ ist, können Sie selbst am besten abschätzen.
Da man sich über Jahre die laufenden Übertragungskosten sparen kann, gibt es aktuell eine starke Wanderung von X.400 zu AS2.