Signaturen für kritische WWW-Elemente

Die ganze Aktion hat natürlich nur dann überhaupt einen Sinn, wenn man davon ausgehen darf (was leider keine technische Kategorie und der sicheren Bestimmung von außen prinzipiell nicht zugänglich ist), dass der Signaturschlüssel des Betreibers des Webangebots sicher verwahrt wird.

Technische Voraussetzung ist, dass der Schlüssel auf einem anderen Rechner liegt, durch den die Inhalte auf den Webserver geschleust werden, die per Signatur freigegeben werden sollen. Das ist nicht immer leicht möglich.

Dieser Rechner sollte zudem so konfiguriert sein, dass die Gefährdung minimal wird, also etwa (auf Dienstebene) nicht von außen zugänglich sein (was schwierig ist, wenn mehrere Leute Inhalte für die Webseite bereitstellen, die nicht problemlos physisch auf den Rechner zugreifen können).

Bei einer theorielastigen Betrachtung der Sicherheit der vorgeschlagenen Maßnahme muss man fragen, wie verhindert werden soll, dass der Anbieter – unbewusst natürlich – kompromittierte Dateien signiert. In der Praxis wird er sich auf einen Virenscanner verlassen müssen, denn wenn der Angriff so subtil ist, dass nicht wenigstens der Bildbetrachter abstürzt, wird der Prüfer keinen Verdacht schöpfen und die Datei durchwinken. Trösten kann man sich allerdings damit, dass es sehr viel schwieriger ist (vor allem bei einer großen Zahl von Webservern quasi unmöglich), auf diese Weise eine kompromittierte Datei auf einen Webserver zu bekommen, als ihn zu hacken und sie selber dort zu platzieren.

Der dynamischen Generierung von Seiten sind durch diese Technik natürlich Grenzen gesetzt. Die Dynamik darf sich nicht auf signierte Elemente selber auswirken, nur auf deren Verwendung (Anordnung). Ausnahme sind reguläre Ausdrücke (für URLs und eventuell Code).

Positiv in bezug auf dynamische Inhalte ist, dass das CMS (oder, eine Nummer kleiner, der generierende Code) nichts von dieser Technik wissen muss; es können also problemlos alle bestehenden Systeme prinzipiell damit verwendet werden. Lediglich die signierte Datei muss das System unangetastet lassen. Der Webmaster muss natürlich wissen, welche URLs und Codesequenzen sein System (legitim) produzieren kann, damit er alle diese in die Signaturliste aufnehmen kann.

Man kann aber ein CMS (oder, unter Inkaufnahme des Verheizens einer Menge Rechenleistung, den Webserver – das wäre dann CMS-unabhängig, quasi als Notlösung) dahingehend an dieses System anpassen, dass es die generierten URLs und Codesequenzen (Javascript) mit der Signaturliste abgleicht und dadurch Konfigurationsfehler aufdecken und Alarm schlagen kann.

Man könnte es den Nutzern einer Seite erleichtern, den Webmaster auf Fehler (also v.a. fehlende Signaturen) hinzuweisen, indem in der Signatur die Kontaktadressen dafür vermerkt werden. Das sollte man nicht nur per E-Mail, sondern auch über ein "internes Formular" des Add-ons machen können, das dieses auch gleich selber ausfüllt, so dass der Nutzer nur noch Benachrichtigen: ja/nein? anklicken muss. In dem Formular wären dann die URL der Seite, ggf. die abweichende URL des Objekts, der Hash des Objekts und – um der Versionierung der Signaturdatei Rechnung zu tragen – auch der Hash der Signaturdatei enthalten.

Manchmal bindet man externe Inhalte ein, die man nicht alle vorher prüfen kann. Das beste Beispiel sind Werbebanner. Natürlich haben weder die Webmaster noch die Werbetreibenden ein Interesse an einem System, das als Nebeneffekt die Werbung ausblendet (weil sie nicht signiert ist).

ein spezieller, besonders schwieriger Spezialfall externer Inhalte sind Daten (also vor allem Dateien: Bilder, Videos), die von den Usern eines Webdienstes bereitgestellt werden. Die können naturgemäß nicht vom Betreiber erfasst werden. Und sie von den Usern signieren zu lassen, ist aus formalen Gründen heikel: Privatleute haben im allgemeinen nicht die Infrastruktur, um die Signaturerzeugung von ihrem Arbeitsrechner zu trennen. Ein kompromittierter Rechner bedeutet damit automatisch, dass die Integrität des Schlüssels zumindest gefährdet ist. Es sollte also in den Schlüsseln vermerkt werden, welchen "Status" der Schlüssel hat (ähnlich den Nutzungsbeschränkungen in X.509-Zertifikaten), damit der Browserbenutzer sein Add-on entsprechend konfigurieren kann (private Inhalte ignorieren, akzeptieren, davor warnen – wie auch immer). Der Webserverbetreiber könnte allerdings das Alter der Datei garantieren. Je älter eine Datei, desto besser stehen die Chancen für einen (aktuellen) Virenscanner, falls sie kompromittiert ist, und für die angegriffene Anwendung, bereits gepatcht zu sein. Der Browserbenutzer könnte also Warnungen auf neue Inhalte beschränken. Davon gibt es zwar immer noch mehr als genug, aber so haben die User wenigstens die Wahl. Man könnte von geeigneten Anbietern auch das Alter seines gesamten (öffentlichkeitsrelevanten) Bilder-/Dateibestands bestätigen lassen, so dass eine gerade hochgeladene Datei nicht alleine deswegen als neu gilt, wenn sie nachweislich schon lange unverändert existiert.

Die Signatur allein ist natürlich wertlos, wenn die Authezität des Schlüssels nicht gesichert ist. Die könnte durch ein web of trust der Webseitenbetreiber geleistet werden. Jeder signiert fünf andere Betreiber ähnlicher Bedeutung und zehn kleinere. Ideal für die "erste Ebene" sind Unternehmen, die auch per Papier mit ihren Kunden kommunizieren: Zeitungen, Zeitschriften und Rechnungen können dann mit dem Hash des jeweiligen Schlüssels versehen werden. Das sollte hinreichend sicher sein.

Jeder Webseitenbetreiber sollte in der Signaturdatei für seine eigenen Seiten oder (zur Trafficreduktion) unter einer von mehreren festlegenten Adressen (innerhalb seiner Domain, also Pfad oder Subdomain) angeben, welche Keyserver seine "revocation list" füren, also die Liste seiner Signaturen für andere Schlüssel, die er zurückgezogen hat. Das Prüf-Add-on sollte solche Signaturen nicht anerkennen, zu deren Aussteller kein solcher Keyserver gefunden wird. Wenn man ein System dieser Art einfürt, dann sollte es von Anfang an Brauchbar sein und das CRL-Desaster bei SSL/X.509 nicht wiederholen.