Web Bot Auth Sleutelgenerator voor HTTP Signatures

Het identificeren van geautomatiseerde webbezoekers, zoals zoekmachinecrawlers en AI-agents, steunt traditioneel op twee mechanismen: de User-Agent header en IP-adreslijsten. Beide methoden vertonen fundamentele zwaktes. Een User-Agent kan door elke willekeurige client worden nagebootst, terwijl IP-reeksen continu veranderen, duur zijn om te onderhouden en kwetsbaar blijven voor configuratiefouten.

Web Bot Auth introduceert een cryptografische standaard om dit probleem op te lossen. Het protocol is gebaseerd op de standaarden voor HTTP Message Signatures (RFC 9421). In plaats van blind te vertrouwen op niet-gecontroleerde tekstvelden, ondertekent de crawler elk HTTP-verzoek met een asymmetrische privésleutel (standaard Ed25519). De ontvangende webserver controleert de meegestuurde handtekening aan de hand van een openbare sleutel die wordt gepubliceerd op het HTTPS-domein van de bot-operator.

Het protocol bevindt zich in de IETF Internet-Draft fase, maar wordt breed omarmd door zoekmachines, AI-platforms en hostingproviders. Doordat de cryptografische identiteit rechtstreeks aan een geverifieerde domeinnaam is gekoppeld, kunnen websites betrouwbare bots direct onderscheiden van kwaadwillige scrapers zonder complexe IP-filters.

De Web Bot Auth Sleutelgenerator levert een compleet pakket met alle benodigde configuratiebestanden en voorbeelden om Web Bot Auth direct te implementeren. De generator maakt gebruik van de Web Crypto API in de browser om een Ed25519-sleutelpaar aan te maken en berekent alle afgeleide waarden:

1. Sleutel-ID (Key ID): De SHA-256 JWK-thumbprint van de openbare sleutel volgens RFC 7638 en RFC 8037, gecodeerd in base64url. Dit ID identificeert de sleutel uniek in het sleuteloverzicht.
2. Sleuteloverzicht (Directory JSON): Het JSON-bestand dat gepubliceerd dient te worden op het pad /.well-known/http-message-signatures-directory. Dit bestand bevat uitsluitend de openbare sleutelgegevens, inclusief optionele geldigheidsdata.
3. Directory response headers: Een voorbeeld van de HTTP-headers waarmee het sleuteloverzicht moet worden geserveerd, inclusief een handtekening met een geldigheid van 24 uur.
4. Sleutelbestanden: De privésleutel in JWK- en PKCS#8 PEM-formaat voor gebruik in bot-software, plus de openbare sleutel in SPKI PEM-formaat.
5. Voorbeeldverzoek en handtekeningbasis: Een compleet curl-commando met de headers Signature-Input, Signature en Signature-Agent, samen met de exacte handtekeningbasis (signature base) voor debugging.

Om ontvangende webservers in staat te stellen handtekeningen te valideren, moet de beheerder van de bot het sleuteloverzicht publiceren op een vastgesteld pad: /.well-known/http-message-signatures-directory onder het HTTPS-domein van de bot.

Het sleuteloverzicht bevat een verzameling openbare sleutels (JWKS). Elke sleutel in het overzicht kan worden voorzien van parameters voor levenscyclusbeheer:

• nbf (Not Before): Unix-tijdstempel in seconden vanaf wanneer de sleutel als geldig mag worden beschouwd.
• exp (Expires): Unix-tijdstempel waarop de sleutel verloopt.

Volgens de Web Bot Auth specificatie moet de respons van het sleuteloverzicht zelf ook cryptografisch ondertekend zijn. Dit voorkomt dat aanvallers het overzicht manipuleren of oude sleutelbestanden cachen.

Het ondertekenen van een HTTP-verzoek volgens RFC 9421 vereist een strikte opbouw van headers. De bot voegt drie centrale headers toe aan elk uitgaand verzoek:

1. Signature-Agent: Het basis-HTTPS-domein van de bot-operator waar het sleuteloverzicht te vinden is.
2. Signature-Input: Bevat de metadata van de handtekening, waaronder de gedekte headers (@authority, signature-agent), het sleutel-ID (keyid), het algoritme (ed25519), de aanmaaktijd (created), de vervaltijd (expires, doorgaans na 5 min) en de tag web-bot-auth.
3. Signature: De daadwerkelijke cryptografische Ed25519-handtekening, gecodeerd als binaire gegevens in gestructureerde velden.

De ondertekening gebeurt over de zogeheten handtekeningbasis (signature base). Dit is een genormaliseerde tekststring waarin de geselecteerde componenten en hun waarden regel voor regel worden geformatteerd:

"@authority": example.com
"signature-agent": https://bot.example.nl
"@signature-params": ("@authority" "signature-agent");created=1710000000;expires=1710000300;keyid="...";alg="ed25519";tag="web-bot-auth"

Elke afwijking in spaties, hoofdletters of regeleinden tussen de client en de server resulteert in een ongeldige handtekening. Voor het coderen en decoderen van meegestuurde tokens kan een Base64 encoder nuttig zijn tijdens het ontwikkelproces.

De betrouwbaarheid van Web Bot Auth staat of valt met de geheimhouding van de privésleutel. De Web Bot Auth Sleutelgenerator voert alle cryptografische berekeningen lokaal uit via de Web Crypto API van de browser. Er worden geen sleutels, domeinen of metadata naar een externe server verzonden.

Omdat de sleutels uitsluitend in het tijdelijke werkgeheugen van de browser bestaan, gaan alle gegenereerde gegevens definitief verloren zodra de pagina wordt vernieuwd of gesloten. Volg daarom direct na het genereren deze stappen voor veilig sleutelbeheer:

• Sla de privésleutel (PKCS#8 PEM of JWK) direct op in een beveiligde kluis of Secret Manager (zoals HashiCorp Vault, AWS Secrets Manager of Azure Key Vault).
• Publiceer onder geen enkele voorwaarde de parameter d uit het JWK-formaat. Dit veld bevat het geheime sleutelmateriaal en hoort uitsluitend thuis in de runtime-omgeving van de bot.
• Gebruik in het openbare bestand /.well-known/http-message-signatures-directory uitsluitend het openbare deel (met parameters kty, crv en x).
• Hanteer een geautomatiseerd rotatieschema waarbij nieuwe sleutels worden gepubliceerd voordat de oude sleutels verlopen.

Cryptografische authenticatie via Web Bot Auth beantwoordt uitsluitend de vraag wie het verzoek verstuurt, niet wat de bot mag bezoeken. De identificatie vormt de eerste stap in een bredere beheerstructuur voor webcrawlers.

Nadat een webserver de handtekening van een crawler heeft geverifieerd via het sleuteloverzicht, kan de server bepalen welke toegangsregels van toepassing zijn. Deze regels worden traditioneel vastgelegd in het robots.txt-bestand op de server. Met een robots.txt generator voor AI-crawlers kunnen beheerders specifieke instructies opstellen voor geverifieerde agents.

Om te controleren of de ingestelde restricties en paden correct functioneren voor verschillende user-agents, kan een robots.txt tester worden ingezet. Door cryptografische verificatie met Web Bot Auth te combineren met duidelijke richtlijnen in robots.txt, ontstaat een robuust ecosysteem waarin legitieme bots gegarandeerde toegang krijgen en ongewenste scrapers effectief worden geweerd.