4. Lösungsansätze für Webanwendungen

In den letzten Jahren wurden webbasierte Anwendungen unterschiedlicherster Techniken in allen Wirtschaftszweigen immer beliebter. Der Trend scheint von der Kkompilierten Desktopapplikation weg zur browserbasierten Anwendung (HTML, CSS, JavaScript) zu zeigen, liegen doch die Vorteile klar auf der Hand:

• betriebssystemunabhängig
• einfachstes Deployment
• Sicher durch Verschlüsselung
• einfaches Rechtemanagement

Zu kurz gekommen ist bisher die Kommunikation außerhalb des Systems. Zwar sind Daten in der Online-Verbindung meist und dann relativ gut über https geschützt. Ist hingegen eine Information offline (per eMail) zu übermitteln, schicken alle (mir bekannten) Diensteanbieter die Information unverschlüsselt.

Sensitive Kommunikation (Rechnungen, Bestellbestätigungen, Kontoauszüge, usw.) können prinzipiell von jedermann, zumindest aber von den Systemadministratoren der beteiligten Unternehmen, ungehindert eingesehen werden. Das beste daran: Der Benutzer kann noch nicht einmal feststellen geschweige denn nachweisen, dass seine Post gelesen wurde.

4.1 Feststellen einer Kompromittierung

Weiter oben im Text hatten wir festgestellt, dass Bob nicht bemerkt, dass die Mail nicht von Alice stammt. Hier möchte ich einen neues Verfahren vorstellen, mit dem ein zwischenzeitliches Lesen („Man-in-the-Middle“) erkannt werden kann:

1. Alice signiert die Nachricht an Bob (innere Signatur).
2. Alice verschlüsselt die Nachricht an Bob mit seinem öffentlichen Schlüssel oder was sie dafür hält.
3. Alice signiert die verschlüsselte Nachricht (äußere Signatur).
4. Alice verschickt die Nachricht.

Nehmen wir an, ein Angreifer konnte Alice einen falschen Schlüssel unterschieben und kann nun die Nachricht lesen. Um den Text an Bob zu schicken, muss er diesen nun mit dem richtigen (=Bob’s) Schlüssel verschlüsseln, damit Bob den Text decodieren kann. Dabei wird mit Sicherheit Alice zweite (äußere) Signatur ungültig, da sich das Chiffrat ja ändert. Zwar würde Bob den korrekten Text entschlüsseln, könnte aber immer feststellen, dass die Verschlüsselung nicht von Alice durchgeführt worden sein kann und die Nachricht kompromittiert sein muss.

Voila: ein unbemerktes Mitlesen ist so nicht mehr möglich; das Verfahren ist sogar rückwärtskompatibel. Wird die äußere Signatur nicht benötigt, kann sie ignoriert werden.

4.2 Erweiterung von Webanwendungen

Jetzt gilt es, Webanwendungen für die sichere Kommunikation zu erweitern. Wir richten uns dabei nur an technisch versiertere Benutzer, die nach (bebilderter) Anleitung Schritte ausführen können.

Prinzipiell müssen wir die beiden oben dargestellen Verfahren (X.509 Zertifikate, PGP) unterstützen und zur Auswahl anbieten. Lassen Sie uns annehmen, dass Ihre Anwendung über https geschützt ist.

4.2.1 Erweiterung mit PGP

Ich setze einmal voraus, dass der Anwender seinen Schlüssel bereits auf die öffentlichen Server hochgeladen hat und seine eMail-Adresse stimmt. Das wird unser Entscheidungskriterium.

Nachdem in PGP keine Zertifikate involviert sind, muss der Benutzer auch selbst in der Lage sein, anhand von Key-ID und Fingerprint den richtigen Eintrag auszuwählen. Das Prozedere eines Webformulars gestaltet sich nun wie folgt:

1. Laden der Registrierungsmaske (oder Checkout, usw.) durch den Anwender über https
2. Eingeben der persönlichen Daten inkl. eMail-Adresse
3. Wenn AJAX: Nach Eingabe der Daten ohne Abschicken öffentliche Key-Server nach eMail-Adresse durchsuchen
4. Wenn kein AJAX: Nach Abschicken der Daten öffentliche Key-Server nach eMail-Adresse durchsuchen
5. Auswahl der gefundenen Einträge dem Benutzer präsentieren mit deutlichem Hinweis, den Fingerprint zu prüfen und den richtigen Eintrag auszuwählen
   Achtung: Wird hier der falsche Eintrag ausgewählt, kann ein Man-In-The-Middle mitlesen.
6. Schlüssel vom Server laden und zusammen mit Benutzer-Record abspeichern

Die Bestätigungsmail kann nun bereits verschlüsselt und ggf. signiert versendet werden.

Merke: Die Prüfung der Identität erfolgt hier durch den Anwender.

4.2.2 Erweiterung mit X.509 Zertifikaten

Hier bestehen wesentliche Unterschiede zu PGP:

• PKI muss aufgesetzt und im Internet erreichbar sein, sonst wird der Mailclient in der Regel ein „Signatur kann nicht überprüft werden“-Fehler anzeigen
• Der User muss sein Zertifikat selbst exportiert haben (CER, DER, PKCS.7 oder Base.64 Kodierung)
• Privater Schlüssel darf (!) unter gar keinen Umständen nach außen gelangen

Die Handhabung mit X.509 ist somit einerseits zwar umständlicher und aufwändiger, bereitet andererseits aber Nutzern eventuell weniger Schwierigkeiten, da die meisten Anwenderprogramme eine Unterstützung für X.509 Zertifikate bereits mitbringen und keine zusätzliche Software installiert werden muss.

Die notwendigen Schritte gestalten sich hier etwas anders:

1. Laden der Registrierungsmaske (oder Checkout, usw.) durch den Anwender über https
2. Eingeben der persönlichen Daten inkl. eMail-Adresse und des Benutzer-Zertifikats über ein file-Input-Feld.
   Achtung: Wird hier die falsche Datei hochgeladen, kann ein Man-In-The-Middle mitlesen.
3. Nach Abschicken der Daten die signierende CA über CRL oder OSCP befragen, ob das Zertifikat noch gültig ist
4. Wenn nein oder nicht feststellbar: Registrierung ggf. ablehnen
5. Ansonsten: Zertifikat zusammen mit Benutzer-Record abspeichern

Auch hier kann die Bestätigungsmail nun verschlüsselt und ggf. signiert versendet werden.

Merke: Die Prüfung der Identität erfolgt hier durch die Software bzw. PKI.

4.2.3 Softwarelösung in PHP

Für PHP gibt es hier einen lesenswerten Forumsbeitrag. Beachten Sie bitte, dass die Erweiterung OpenSSL für PHP sowie OpenSSL an sich installiert sein muss. Sobald ich Zeit habe, werde ich einen funktionierenden Prototypen inkl. Quelltext online stellen.