Web Bot Auth: Wie Agenten-Anfragen signiert werden und was die Signatur belegt

Ein automatisierter Browser kann JavaScript ausführen und dadurch in einer Webanalyse ähnlich wie ein menschlicher Besuch erscheinen. Das ist kein zwingendes Ergebnis: Messaufbau, Bot-Erkennung und ausgeführte Aktionen bestimmen die Erfassung. Web Bot Auth ergänzt solche Indizien um eine kryptografisch prüfbare Kennung für signierte Anfragen.

Die wichtigste Grenze lautet: Eine gültige Signatur belegt die Nutzung eines passenden privaten Schlüssels für bestimmte Nachrichtenbestandteile. Daraus folgen weder eine bestätigte Identität des tatsächlichen Betreibers noch eine Zugriffsberechtigung oder eine Garantie für harmloses Verhalten.

Drei Header mit verschiedenen Aufgaben

Die Grundlage ist RFC 9421, ein veröffentlichter Standard für HTTP-Nachrichtensignaturen. Signature-Agent verweist auf die Quelle des öffentlichen Prüfschlüssels. Signature-Input nennt die abgedeckten Bestandteile und Parameter, etwa Erstellungszeit, Ablaufzeit und Schlüsselkennung. Signature enthält den eigentlichen Signaturwert.

Ed25519 ist ein verwendeter Algorithmus, keine allgemeine Beschränkung von RFC 9421. Ein Prüfer benötigt den zum vereinbarten Profil passenden Algorithmus, einen vertrauenswürdig zugeordneten öffentlichen Schlüssel und exakt dieselbe Signaturbasis. Der Absender signiert mit einem geheimen privaten Schlüssel; der Empfänger prüft das Ergebnis mit dem zugehörigen öffentlichen Schlüssel. Die Signaturbasis ist der exakt zusammengestellte Text aus signierten Bestandteilen und Parametern. Die Prüfung erzeugt keine neue Signatur mit dem öffentlichen Schlüssel.

Entwurf und Produktprofil unterscheiden sich

Stand 24. Oktober 2026 führt die IETF den Arbeitsgruppenentwurf draft-ietf-webbotauth-httpsig-protocol-00 vom 1. September 2026. Damit existiert ein angenommener Arbeitsgruppenentwurf, aber noch kein fertiger RFC für dieses Profil. Der ältere Architekturentwurf ist ersetzt. Der WG-Entwurf verlangt eine Dictionary-Form von Signature-Agent; Cloudflares aktuell dokumentierte Produktprüfung verlangt dagegen weiterhin einen einzelnen strukturierten String und lehnt die Dictionary-Form ab.

Die folgenden Zeilen vergleichen ausschließlich diese Formate. Das Beispiel ist keine vollständige signierte Anfrage: Signaturwert, Zeitparameter und Schlüsselmaterial fehlen bewusst.

IETF-WG-Entwurf 00 — Dictionary-Eintrag:
Signature-Agent: sig="https://agent.example"
Signierter Bestandteil: "signature-agent";key="sig"

Dokumentiertes Cloudflare-Produktprofil — strukturierter String:
Signature-Agent: "https://agent.example"
Signierter Bestandteil: "signature-agent"

Verzeichnismodus:
https://agent.example/.well-known/http-message-signatures-directory
Content-Type: application/http-message-signatures-directory+json

Der feste Pfad gilt für den Verzeichnismodus. Der aktuelle WG-Entwurf beschreibt zusätzlich andere Verfahren zur Schlüsselauflösung. Für eine Integration sind das tatsächlich unterstützte Profil, dessen Version und die Registrierungsvorgaben entscheidend. Cloudflares Verified-Bot-Verfahren verlangt eine Registrierung; ein beliebig veröffentlichter Schlüssel genügt dafür nicht.

Was eine erfolgreiche Prüfung tatsächlich verbindet

Ein sicher aufgelöstes HTTPS-Verzeichnis verbindet eine URL mit einem veröffentlichten Schlüssel. Eine passende Signatur verbindet diesen Schlüssel mit den signierten Bestandteilen. Der Inhaber des Signierschlüssels und die Domainverwaltung müssen nicht dieselbe Person oder Organisation sein. Eine Zuordnung zu einem bekannten Unternehmen benötigt zusätzliche vertrauenswürdige Informationen.

Die Schlüsselkennung allein genügt ebenfalls nicht: Ein Cache muss die verifizierte Zuordnung zwischen URL und Schlüssel erhalten. Das bloße Übernehmen eines bekannten Schlüssels unter einer fremd behaupteten URL darf keine neue Identität erzeugen. Ein Verzeichnisabruf beweist auch keine Absicht und ersetzt keine lokale Zugriffsregel.

Abdeckung und Wiederverwendung

Eine Signatur über nur @authority und den Agent-Verweis bindet keine Methode, keinen Pfad und keinen Nachrichteninhalt. Solange Zeitfenster und weitere Prüfregeln passen, können kopierte Header deshalb zu anderen Anfragen an dieselbe Authority, also denselben Hostnamen samt gegebenenfalls angegebenem Port, passen. Das ist kein Beweis dafür, dass der ursprüngliche Signierer jede dieser Anfragen abgesendet hat.

Zusätzliche Komponenten wie @method und @target-uri begrenzen diesen Spielraum. Für den Inhalt kann ein signierter Content-Digest verwendet werden; der Empfänger muss den Digest zusätzlich mit dem tatsächlich empfangenen Inhalt abgleichen. Der gesamte Inhalt muss dafür nicht zwangsläufig im Arbeitsspeicher gepuffert werden: Eine Hashberechnung kann fortlaufend erfolgen, abgeschlossen ist die Inhaltsprüfung erst nach dem letzten Byte.

expires begrenzt die Dauer einer Wiederverwendung, verhindert aber keine Wiederholung innerhalb des Fensters. Ein nonce-Wert ist für eine einmalige Nutzung gedacht. Gegen kopierte Anfragen hilft dieser Wert nur mit einer passenden serverseitigen Prüfstrategie. Cloudflare dokumentiert derzeit keine Prüfung bereits verwendeter Nonces und empfiehlt kurze Laufzeiten.

Prüfung vor einer Zugriffsentscheidung

1. Header strukturiert nach dem unterstützten Profil parsen; erforderliche Komponenten, Parameter und erlaubte Algorithmen kontrollieren.
2. Schlüsselherkunft sicher auflösen: HTTPS, zulässige Ziele, begrenzte Antwortgröße und Zeitlimits. Clientgesteuerte URLs dürfen keine internen Dienste erreichbar machen. Der aktuelle WG-Entwurf untersagt automatische Weiterleitungen bei der Schlüsselauflösung.
3. URL-Schlüssel-Zuordnung, Signaturbasis und kryptografische Signatur prüfen; Zeitfenster einschließlich Erstellungszeit, Ablaufzeit und zulässiger Uhrabweichung kontrollieren.
4. Inhalts-Digest und Wiederholungsschutz entsprechend dem gewählten Profil prüfen. Erst anschließend lokale Regeln für Zugriff, Rate-Limit und Protokollierung anwenden.

Eine etablierte Bibliothek reduziert Serialisierungsfehler, ersetzt aber weder Profilabgleich noch Schlüsselrotation und sichere Cache-Regeln. Ein ungültiger oder nicht unterstützter Nachweis bleibt ein eigener Zustand; daraus folgt nicht automatisch „Mensch“.