Standardmethode zum statischen Signieren einer Webseite

Question

Angenommen, ich habe ein gültiges kryptografisches Zertifikat (d. H. Von einem der vertrauenswürdigen Autoritäten signiert) auf meinem Server. Ich könnte es natürlich verwenden, um HTTPS-Sitzungen einzurichten und die Inhalte mit Vertraulichkeit (nur die Endpunkte können sie lesen), Authentifizierung (beide Endpunkte wissen, mit wem sie sprechen) und Zuverlässigkeit (die Nachricht kann nicht manipuliert werden) zu liefern.

Nun nehme an, dass mir die ersten beiden eigentlich egal sind, aber stattdessen brauche ich nur die letzte. Nehmen wir zum Beispiel an, ich hätte eine statische Ressource, die ich signieren möchte (a-la PGP), damit ich sie anderen nicht vertrauenswürdigen Hosts geben kann: Wenn mein Zertifikat öffentlich ist und die Ressource damit signiert wurde, sollte jeder Client dies tun in der Lage zu überprüfen, dass die Ressource nicht manipuliert wurde (z. B. durch den nicht vertrauenswürdigen Host).

Die Frage ist nun: Gibt es eine Standardmethode, um eine Webseite statisch zu signieren? (Ich meine natürlich etwas, das in allen Browsern eingebaut ist) Ich kenne jemanden (Unhosted), der versucht, so etwas zu erreichen, indem er viel von der Logik über Javascript implementiert, aber ich frage mich, ob es einen Standard-Weg gibt.

Answer 1

Ich bin nicht bewusst, dass eine solche Standardimplementierung in einem Browser eingebaut ist.

Selbst im Mail-Bereich, wo solches Verhalten lange Zeit "Standard" ist (S/MIME), finden wir jeden zweiten Tag Probleme mit verschiedenen Clients, Relays und Servern.

Für einen Download können Sie zum Senden eines PKCS # 7-Containers zurückkehren und ein Tool zum Entpacken und Verifizieren zuordnen. Zumindest Plugins und Hilfsprogramme sind überall verfügbar.

Answer 2

Ich kenne auch keine Standardimplementierung wie diese in einem Browser. Aber ein bisschen zu sichern ... einige Dinge zu beachten:

1. Für ausführbare Inhalte (wie heruntergeladene EXE-Dateien, ActiveX-Steuerelemente, Windows Installer, etc.), eine gemeinsame/Standardlösung Microsoft Authenticode. Siehe http://www.tech-pro.net/code-signing-for-developers.html. Ähnliche Lösungen für Java, Adobe usw. Die Zertifizierungsstelle, von der Sie das Zertifikat erwerben, verifiziert Ihre Identität. Wenn Sie eine EXE-Datei mit einem Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signieren, zeigt Internet Explorer die Warnmeldung "Unterschriftsinformation/weniger gruselig" an. Gleiches gilt für UAC-Erhöhungsaufforderungen in Windows Vista/7. Du kennst das wahrscheinlich schon?

2. Aber für die statische Inhaltssituation ist die Standardlösung SSL. Darf ich fragen, warum SSL in Ihrer Anwendung keine akzeptable Lösung ist?

   Das Problem, das ich sehe, ist, dass es keine Möglichkeit für den Benutzer gibt, die Identität der Webseite über den Webbrowser zu überprüfen, außer das SSL-Sperrsymbol im Browser zu klicken, um das Zertifikat anzuzeigen. Die neuen SSL-EV-Zertifikate sollten bestätigen, dass Sie die fragliche Domain kontrollieren und dass Sie der sind, von dem Sie sagen, dass Sie es sind (d. H. Kein "PayPal" -Zertifikat für www.paypal.com.hacker.cz erhalten).

Es klingt aus Ihrer Frage, die Sie sich für eine „Authenticode für Webseiten“ Art der Sache suchen: ein Zertifikat mit einem Thema nicht zu einem Domain-Namen gebunden und wo die Web-Seite könnte überall gehen. Leider sind mir solche Standard-HTML-Dateien nicht bekannt. Ich glaube, Sie können Dinge wie Adobe AIR-Anwendungen unterschreiben, die auf HTML/Javascript/etc. basieren können, obwohl ich mit dieser Plattform nicht vertraut bin. Es platziert die Webseite natürlich außerhalb des normalen Webbrowsers des Benutzers.