English
Deutsch
PolskiWeb Bot Auth: Wie Agenten-Anfragen signiert werden und was die Signatur belegt
Inhalt
Ein agentischer Browser sieht in einem Analysebericht aus wie ein Mensch, weil er einer echten Browsermaschine gleicht. Die Frage, wer da eigentlich anfragt, lässt sich am Verhalten nur schätzen – oder von der Gegenseite beantworten, indem sie unterschreibt.
Genau das ist Web Bot Auth. Der Mechanismus ist kurz, die Kryptografie unspektakulär, und die interessanteste Aussage darüber ist, was er ausdrücklich nicht belegt.
Was auf der Leitung liegt
Die Grundlage ist RFC 9421, die HTTP-Nachrichtensignaturen. Der Betreiber eines Agenten erzeugt ein Ed25519-Schlüsselpaar, hinterlegt den öffentlichen Teil als JSON-Schlüsselsatz unter einem festen Pfad auf einer Domain, die er kontrolliert, und unterschreibt jede ausgehende Anfrage. Drei Header tragen das Ergebnis.
Signature-Agent: "https://beispiel-agent.de"
Signature-Input: sig=("@authority" "signature-agent");
created=1700000000;
expires=1700011111;
keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
tag="web-bot-auth"
Signature: sig=jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZD…
Verzeichnis /.well-known/http-message-signatures-directory
Inhaltstyp application/http-message-signatures-directory+json
Die Klammer hinter sig= nennt, was unterschrieben ist. Hier sind
es zwei Bestandteile: der Zielhost und die Verzeichnisangabe.Der Prüfer liest Signature-Agent, holt von dort das Verzeichnis, sucht darin den über keyid benannten Schlüssel, baut die Signaturbasis aus den in Signature-Input benannten Bestandteilen nach und rechnet die Unterschrift nach.
Was die Unterschrift belegt
Zwei Dinge, und beide sind stark. Erstens: Wer sie erzeugt hat, besitzt den privaten Schlüssel zu einem öffentlichen, der unter einer bestimmten Domain veröffentlicht ist. Zweitens: Er kontrolliert diese Domain, denn sonst könnte er dort nichts hinterlegen. Zusammen ergibt das eine überprüfbare Herkunft, und die ist mehr, als eine Kennung im User-Agent je war.
Dazu kommt der Ersatz für einen Wiedereinspielungsschutz: expires begrenzt die Gültigkeit, und eine Unterschrift nach diesem Zeitpunkt wird verworfen. Eine mitgeschnittene Anfrage lässt sich damit nicht beliebig lange wiederverwenden.
Was sie nicht belegt
Die Unterschrift deckt benannte Bestandteile ab, im veröffentlichten Beispiel den Zielhost und die Verzeichnisangabe. Den Rumpf der Anfrage deckt sie nicht ab, und über die Absicht sagt sie nichts. Sie belegt Identität, nicht Verhalten.
Damit ist eine gültige Unterschrift keine Erlaubnis. Ein sauber unterschriebener Agent kann denselben Inhalt abgreifen wie ein unsignierter, nur eben nachweisbar. Der Gewinn liegt nicht in der Abwehr, sondern in der Zurechenbarkeit: Wer weiß, welcher Betreiber angefragt hat, kann eine Regel je Betreiber setzen – und im Streitfall belegen, wer da war.
Wie sich das prüfen lässt
Die Prüfung ist überschaubar und lohnt sich als Übung, weil sie die Grenzen des Verfahrens unmittelbar zeigt. Vier Schritte: Signature-Agent lesen und auf eine erwartete Domain prüfen; das Verzeichnis unter dem festen Pfad holen und den Schlüssel zu keyid heraussuchen; die Signaturbasis aus den in Signature-Input genannten Bestandteilen in der genannten Reihenfolge zusammensetzen; die Ed25519-Prüfung rechnen und expires gegen die eigene Uhr halten.
Der dritte Schritt ist der, an dem eigene Umsetzungen scheitern, weil die Signaturbasis zeichengenau stimmen muss. Wer sie einmal von Hand gebaut hat, versteht danach auch, warum der Rumpf nicht mitunterschrieben ist: Er müsste dafür vollständig gepuffert werden, bevor die erste Prüfung beginnt.
Der Stand, ehrlich benannt
Beide Spezifikationen sind Internet-Drafts – die Architektur und das Verzeichnis, letzteres in der fünften Fassung. Eine IETF-Arbeitsgruppe befasst sich seit Anfang 2026 damit, ein verabschiedetes Dokument gibt es nicht, und Entwürfe ändern Header-Namen und Pfade durchaus noch.
Gleichzeitig prüfen mehrere große Netz- und Sicherheitsanbieter diese Unterschriften bereits im Wirkbetrieb. Für einen einzelnen Auftritt heißt das: verstehen ja, darauf verlassen noch nicht. Und der Satz, der beim Lesen der Ankündigungen mitzudenken ist, steht im Bild als gestrichelte Kante – eine Unterschrift beweist, wer anfragt, und niemals, was er vorhat.
Fragen und Antworten
Kann jemand den Header Signature-Agent einfach mit der Domain eines bekannten Betreibers füllen?
Schreiben lässt er sich, nur besteht er die Prüfung nicht. Die Prüfung holt den Schlüssel aus dem Verzeichnis genau dieser Domain, und ohne den passenden privaten Schlüssel geht die Ed25519-Prüfung nicht auf. Weil Signature-Agent selbst zu den unterschriebenen Bestandteilen gehört, lässt er sich auch nicht nachträglich gegen eine andere Domain tauschen.
Lässt sich eine mitgeschnittene, gültige Unterschrift vor Ablauf von expires erneut verwenden?
Innerhalb der Frist grundsätzlich ja. expires ist nur ein Ersatz für einen Wiedereinspielungsschutz: Die Angabe begrenzt, wie lange eine Unterschrift gilt, verhindert aber nicht, dass dieselbe Unterschrift in dieser Zeit mehrmals vorgelegt wird. Im Beispiel liegen zwischen created und expires 11.111 Sekunden, also gut drei Stunden.
Hinzu kommt, was unterschrieben ist. Im Beispiel sind es nur der Zielhost und die Verzeichnisangabe, weder Pfad noch Methode noch Rumpf. Wer die drei Header einer solchen Anfrage kennt, kann sie in dieser Zeit also auch an eine andere Adresse desselben Hosts hängen, und die Prüfung geht trotzdem auf.
Praktisch setzt das voraus, dass die Header überhaupt in fremde Hände geraten. Über HTTPS sind sie auf der Leitung verschlüsselt, sichtbar sind sie aber überall dort, wo TLS endet, etwa bei einem CDN oder einem Reverse Proxy, und in Protokollen, die Header mitschreiben. Für eine Regel je Betreiber heißt das: Eine gültige Unterschrift belegt, dass der Betreiber diese Header erzeugt hat, nicht zwingend, dass er genau diese Anfrage geschickt hat.
Hilft Web Bot Auth dabei, Agenten aus einem Analysebericht herauszurechnen?
Nur dort, wo die Header der Anfrage ankommen. Die Unterschrift steht in den Headern der HTTP-Anfrage, und die sieht der Server, ein vorgeschaltetes CDN oder das Server-Log. Ein Mess-Tag, das als JavaScript im Browser läuft, kann die Header der Anfrage nicht lesen, mit der seine eigene Seite geladen wurde; ein agentischer Browser zählt dort deshalb weiterhin wie ein Mensch.
Wer die Unterscheidung im Bericht haben will, muss sie am Server treffen: die Prüfung dort vornehmen und ihr Ergebnis weitergeben, etwa als Kennzeichen, das die Seite an das Tag übergibt, oder durch eine Messung auf dem Server selbst. Das setzt voraus, dass der Agent überhaupt unterschreibt; Agenten ohne Unterschrift bleiben so unsichtbar wie zuvor.
Passend dazu
