Hostnaameigendom bewijzen zonder certificaat

Elk product waarin een klant een hostnaam kan intypen die daarna elke minuut gecontroleerd wordt, heeft twee dingen gebouwd. Het eerste is monitoring. Het tweede is een verspreide verzoekgenerator, gericht op waar de klant maar wil, met de naam van je bedrijf in de user agent en het factuuradres van je klant erachter.

De gebruikelijke tegenwerping is dat het doel een openbaar adres heeft, dus iedereen zou er toch al verkeer heen kunnen sturen. Dat klopt en het is niet waar het om gaat. Een openbaar adres is geen toestemming om iemand te meten, en "iedereen zou dat kunnen" is geen verweer dat de eerste misbruikmelding overleeft, zeker niet als het verkeer periodiek is, aanhoudt en van een herkenbaar commercieel platform komt.

Een hostnaam als doel moet dus verdiend worden. Dit is het ontwerp waar we op uitkwamen, inclusief de delen die minder voor de hand liggen dan ze lijken.

Twee methoden die verschillende dingen bewijzen

Er zijn twee praktische manieren waarop iemand kan aantonen dat een naam van hem is, en het is goed om duidelijk te zijn dat ze niet gelijkwaardig zijn.

Een DNS-TXT-record bewijst zeggenschap over de zone. Wie daar een waarde kan neerzetten, bepaalt waar de naam heen wijst, en dat is de sterkste bewering over een naam die er bestaat.

Een bestand op de webserver bewijst zeggenschap over de machine waar de naam op dit moment naartoe wijst. Dat is zwakker: op gedeelde hosting kunnen meer mensen dat bestand neerzetten dan er de zone kunnen bewerken. Het is ook veel beter haalbaar voor een klant die wel een server heeft maar geen toegang tot de DNS-aanbieder van zijn werkgever.

Dat is dezelfde afweging die certificaatautoriteiten maken met hun twee gangbare challenges, en dezelfde conclusie volgt: bied ze allebei aan, leg vast welke er gebruikt is, en doe niet alsof ze even zwaar wegen.

De vorm van de challenge

Het TXT-record staat onder een eigen label en niet op het domein zelf. Dat is geen netheid. Een record op de apex belandt naast de mailbeleidsrecords van de klant, waar elke extra tekst het antwoord dichter bij de omvang brengt waarbij resolvers het moeilijk krijgen, en waar iemands opruiming van "oude TXT-records" het zonder kwade wil weghaalt. Onder een eigen label staat het op zichzelf.

Het bestand staat onder een gereserveerd pad met het token als bestandsnaam, en het bestand bevat het token en verder niets.

Het token zelf is tweeëndertig hexadecimale tekens, oftewel honderdachtentwintig bits. Het is geen geheim en het is geen sleutel: het gaat in openbare DNS of op een openbare webserver staan. Wat het wel moet zijn is niet te raden, want wie een geldig token kan voorspellen kan een naam claimen die niet van hem is door het eerst op zijn eigen server te zetten. Kleine letters in hex houden het veilig voor een DNS-record, veilig in een URL, en vrij van tekens die verkeerd gelezen kunnen worden als een klant het met de hand overtypt.

Eén structurele regel: precies één stuk code schrijft de challenge uit, en het resultaat reist met het verzoek mee naar wie de controle uitvoert. Zouden beide kanten het voorvoegsel onafhankelijk kennen, dan komt er ooit een dag waarop het paneel het ene label toont en de controleur het andere opzoekt, en dan luidt de melding "het record staat er niet" over een record dat er wel staat. Niets is duurder in ondersteuning dan een correct antwoord op een vraag die niemand stelde.

Waarom de agent het ophalen doet

Dit is de beslissing waar de rest aan hangt.

Het platform zoekt de naam niet op en haalt het bestand niet op. Deed het dat wel, dan zou onze eigen infrastructuur verbindingen maken naar een naam die een gebruiker intypte, en dat is server side request forgery met een formulierveld als aanvalsoppervlak. Het klassieke gevolg is een verzoek aan een metadata-endpoint in de cloud vanuit ons eigen netwerk, door ons gedaan, op verzoek.

In plaats daarvan doet de eigen agent van de klant het: dezelfde agent die de controles daarna zal draaien, binnen het eigen netwerk van de klant, en uitsluitend uitgaand verbindend. Liegen over de uitkomst levert niets op, want de beloning is toestemming om iets te meten dat de agent toch al kon bereiken. De verificatie wordt uitgevoerd door de partij die de toegang al heeft, en dat is de enige opstelling waarin de prikkel om vals te spelen verdwijnt.

Er is een gevolg dat het hardop zeggen waard is, want het lijkt op een ontbrekende beveiliging. Richtlijnen voor dit soort functies zeggen meestal dat je privéreeksen, loopback, link-local en metadata-adressen moet blokkeren. Die regel hoort bij gehoste peilingen, dat wil zeggen meetpunten die wij bedienen en die in ons netwerk staan. Voor een agent binnen het eigen netwerk van de klant zijn privéadressen het normale geval: hun hypervisor, hun switch, hun opslag. Ze blokkeren zou de enige meetbron uitschakelen voor precies de situatie waarvoor hij bestaat.

Wat beide paden delen is één functie die beslist welke adressen toegestaan zijn. Hadden verificatie en meting elk hun eigen lijst, dan kwam er een dag waarop ze het oneens waren, en op die dag is de ene lijst een omweg om de andere heen.

Dichtvallen bij gemengde antwoorden

Een naam kan naar meerdere adressen wijzen, en die hoeven niet allemaal even aanvaardbaar te zijn.

Antwoordt een naam met zowel het openbare adres van de klant als een metadata-endpoint, dan is elke uitvoering een nieuwe trekking. Negen uitvoeringen meten het openbare adres en de tiende praat met iets heel anders. Het aantal aanvaardbare antwoorden draagt daarmee helemaal geen informatie: één verboden adres in de verzameling maakt de hele naam onbruikbaar, en de klant krijgt te horen welk adres het was, want een weigering waar hij niets mee kan is niet meer dan een foutmelding.

Hetzelfde geldt tijdens de verificatie en tijdens gewone controles, en dat is opnieuw de reden dat er één adresbeleid is en geen twee.

Details die je alleen leert door het te draaien

Drie hiervan kwamen uit het bouwen van de controleur; het vierde is een ontwerpkeuze die daarbij hoort.

Vergelijk met "bevat" en niet met gelijkheid. Een DNS-aanbieder mag een TXT-waarde met aanhalingstekens eromheen tonen, en sommige controlepanelen voegen aanhalingstekens toe die ze in hun eigen weergave weer weghalen. Het token is lang en ondoorzichtig: het staat er wel of het staat er niet, en een exacte overeenkomst eisen straft alleen de klanten die alles goed deden.

Stuur de naam mee in de hostheader en in de TLS-servernaam. De verbinding gaat naar een adres dat het adresbeleid al doorstaan heeft, maar een webserver met meerdere sites moet te horen krijgen welke er gevraagd wordt. Zonder allebei zakt een correct ingerichte klant voor de verificatie, omdat hij de standaardsite van iemand anders geserveerd kreeg.

Sta precies één omleiding toe. Een webserver die alles naar HTTPS duwt is normaal, en de omleiding weigeren zou het halve internet laten zakken. Er veel toestaan zou het bewijs ergens heel anders kunnen laten eindigen. Eén stap, en alleen naar dezelfde host.

Eis geen HTTPS voor de bestandschallenge. Het bewijs is het token. Een certificaat voegt daar niets aan toe, en er een eisen maakt van een eigendomscontrole een certificaatcontrole, wat een andere vraag is met andere faalbeelden. Dat is dezelfde redenering achter de gewone HTTP-challenge bij certificaatuitgifte. Let op dat deze standaard specifiek voor verificatie geldt: is het schema juist het ding dat gemeten wordt, dan zou raden een groene meting opleveren van iets anders dan wat de klant instelde, en daar is weigeren het juiste gedrag.

Bewijs verloopt, want domeinen wisselen van eigenaar

Een geverifieerde naam hoort niet voor altijd geverifieerd te blijven, en de reden is geen achterdocht over onze eigen administratie.

Domeinen wisselen van eigenaar zonder dat iemand het meldt. Een klant laat een registratie verlopen, iemand anders pakt hem op, en vanaf dat moment meten wij elke minuut de machine van een vreemde met de naam van onze klant aan het schema gehangen. Niemand in die keten heeft iets verkeerd gedaan en de uitkomst is toch onaanvaardbaar.

Negentig dagen is de geldigheid die we gekozen hebben, wat van dezelfde orde is als een kortlevend certificaat en om dezelfde reden: kort genoeg dat een overdracht snel opvalt, lang genoeg dat klanten niet elke week papierwerk doen. Herverificatie begint veertien dagen voor het verlopen, wat bewust royaal is, want een mislukte herverificatie betekent meestal dat de agent offline was of dat een resolver traag was, en niet dat het eigendom veranderd is.

Pogingen zijn beperkt tot één per zes uur, en dat staat los van het monitoringinterval. Een verificatie is geen meting: ze zegt niets over beschikbaarheid, ze hoort niet thuis in een beschikbaarheidscijfer, en vaker vragen levert alleen verkeer op tegen de DNS van de klant. Zes uur over veertien dagen is meer dan vijftig pogingen, en dat maakt van "verlopen" een echt signaal in plaats van pech.

De toestanden die hieruit komen zijn in behandeling, geverifieerd, verlopend, verlopen en ingetrokken, en een daarvan is geen poort. "Verlopend" bestaat zodat de interface iemand kan waarschuwen; een bewijs dat over tien dagen afloopt is vandaag geldig, en de controles blijven draaien. Het als aparte poorttoestand behandelen zou een klant zijn monitoring afnemen op een dag waarop er niets veranderde.

De database dwingt het paar af in plaats van de code te vertrouwen: een rij heeft ofwel zowel een verificatietijd als een verlooptijd, ofwel geen van beide. Een geverifieerde rij zonder verloop is een blijvende toekenning die niemand koos, en dat is precies het ding dat dit hele ontwerp moet voorkomen.

Wat we zouden opschrijven

1. 01Bepaal wat de challenge bewijst, zeggenschap over de zone of over de machine, en leg vast welke er gebruikt is.
2. 02Zet de challenge onder een eigen label, nooit op de apex naast iemands mailrecords.
3. 03Maak de partij die de toegang al heeft tot controleur. Haalt je platform een door de gebruiker aangeleverde naam op, dan heb je een functie voor request forgery gebouwd.
4. 04Eén adresbeleid voor verificatie en meting. Twee lijsten worden twee gedragingen.
5. 05Val dicht bij gemengde antwoorden, en noem in de weigering het adres dat het probleem is.
6. 06Geef het bewijs een vervaldatum, en begin ruim daarvoor met vernieuwen, want de fout waartegen je je wapent is van nature stil.

Voor de duidelijkheid over onze eigen stand: dit is een ontwerp dat in code bestaat met eigen tests, monitoring is niet iets wat je vandaag bij ons kunt kopen, en niets van het bovenstaande mag gelezen worden als een productaankondiging. Het is de vorm die we opnieuw zouden bouwen.

Uit het monitoringwerk aan Provibr. De verwante vraag hoe je meet zonder aan te raken, en hoeveel bytes een controle mag sturen, staat in waarom een scanner nul bytes hoort te sturen; hoe een agent kiest welk meetpunt hij van meerdere gebruikt staat in hoe een agent de juiste edge-server kiest.