OpenVPN auth-nocache: wat er bij de volgende login gebeurt

Zet auth-nocache aan en de waarschuwing over het cachen van het wachtwoord verdwijnt, samen met de kopie van de inloggegevens die OpenVPN voor de volgende heronderhandeling vasthield. Of dat een prompt, een stille nieuwe poging of een weggevallen tunnel wordt, hangt af van waar de inloggegevens de tweede keer vandaan komen. Daarom is dit een vergelijking tussen uitrolvormen en geen oordeel over de optie. Lees de vorm die je werkelijk draait voordat je een profiel bewerkt.

Waar de tweede set inloggegevens vandaan moet komen

OpenVPN past auth-nocache toe op de geheimen die auth-user-pass en askpass verzamelen: zodra ze zijn gebruikt, gooit het proces ze weg in plaats van ze voor de volgende handshake te bewaren. Een heronderhandeling komt op een timer, standaard één keer per uur, dus het tweede verzoek komt lang nadat de persoon die het wachtwoord typte al weg is. Dat gat is het hele verhaal. Met de cache aan speelt de client de opgeslagen kopie af zonder iemand te vragen; met de cache uit moet hij het geheim elders vinden of falen.

Som dus elke plek op waar het geheim op dat moment vandaan kan komen, en wees eerlijk over welke daarvan op de host bestaan. Een persoon bij een terminal, een bestand dat auth-user-pass of askpass kan lezen, of een door de server uitgegeven sessietoken zijn de drie die hier tellen. Als geen van die beschikbaar is, mislukt de heronderhandeling een uur na de wijziging en niet op het moment dat je die maakte.

Drie vormen, drie faalpunten

Een desktopclient met een persoon ervoor is het milde geval: de prompt komt terug, iemand typt het wachtwoord opnieuw, en de prijs is aandacht. Een service, container of router die OpenVPN zonder terminal draait, is het harde geval, want er is niemand om te antwoorden en de verbinding die vroeger stil was, beëindigt nu de tunnel. Een hybride zit tussen beide in en gedraagt zich als het desktopgeval tot de sessie die de prompt kon beantwoorden verdwijnt. Wat ze scheidt is niet of er een GUI is geïnstalleerd, maar of er op het moment van de heronderhandeling een bron van inloggegevens bestaat.

Wijs je uitrol toe aan een van die drie voordat je iets verandert, want het advies dat je online vindt is bijna altijd voor de eerste geschreven. Het desktopantwoord toepassen op een headless service is hoe een tunnel die maanden werkte elk uur begint weg te vallen.

Directief of flag: kies er één en weet welke je hebt gebruikt

Binnen een profiel is auth-nocache een eigen regel; bij een aanroep die een profiel expliciet noemt, is het een flag op die commandoregel, en de OpenVPN-handleiding vermeldt beide vormen. Beide doen hetzelfde met het vasthouden van inloggegevens, en geen van beide raakt het interfacetype aan of repareert een ongerelateerde waarschuwing in hetzelfde log. Het verschil is persistentie: de flag geldt alleen voor die run, dus een service die opnieuw start vanuit een unit-bestand of wrapperscript heeft hem niet, tenzij de wrapper hem ook doorgeeft.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Bepaal welk artefact de instelling bezit, wijzig hem daar en nergens anders. Een profiel dat op een laptop is bewerkt plus een systemd-unit die het met een flag overschrijft, is het paar dat na een herstart tegenstrijdig gedrag oplevert.

Een inloggegevensbestand verplaatst het geheim in plaats van het te wissen

auth-user-pass op een bestand richten geeft elke latere heronderhandeling een bron, en zet het wachtwoord ook op een plek die herstarts overleeft. Vraag wie dat bestand kan lezen, of de daemon het na het afstaan van privileges nog kan lezen, en wat er gebeurt als het bestandssysteem alleen-lezen is aangekoppeld of een containerweergave het pad verbergt. Een geheim op schijf en een geheim in het geheugen zijn verschillende problemen, en het ene oplossen laat het andere op zijn plek. Rotatie is de stap die wordt overgeslagen: een wachtwoord dat op de server is gewijzigd maar niet in het bestand, levert een storing op die als netwerkfout wordt gelezen.

Houd het bestand in eigendom van het account dat de daemon draait, leesbaar voor niemand anders, en buiten back-ups die de host verlaten. De server-side optie auth-gen-token van OpenVPN geeft de client na een geslaagde login een sessietoken, wat een kleiner ding is om te laten slingeren dan het accountwachtwoord. Schrijf de rotatiestap hoe dan ook naast het bestand, want het bestand overleeft meestal de persoon die het heeft gemaakt.

De heronderhandeling oprekken verplaatst de kosten, het haalt ze niet weg

De andere suggestie is reneg-sec te verhogen tot de prompt zeldzaam genoeg is om te negeren. Dat herschrijft het schema voor sleutelrotatie van de sessie en duwt hetzelfde inloggegevensprobleem naar een later, minder voorspelbaar moment; het maakt geen bron van inloggegevens. Een beleid dat sleutels om een reden volgens een schema vernieuwt, moet niet worden versoepeld alleen om te voorkomen dat je een wachtwoord typt.

Test de herverbinding en niet de sessie waarin je zit, want de levende sessie bewijst niets. Laat de tunnel vanaf de serverzijde vallen, of herstart de clientservice, en kijk wat de volgende heronderhandeling doet terwijl er niemand achter het toetsenbord zit. Als hij opnieuw verbindt, benoem dan het mechanisme dat het geheim leverde; zo niet, dan heb je de werkelijke kosten van de optie op deze host gevonden. Elke uitkomst geeft je een antwoord dat tijdens een storing geldt in plaats van een dat tijdens het testen gold.

Op een beheerde vloot moet wie de uitrol bezit drie dingen kunnen noemen: waar de inloggegevens vandaan komen, waar ze worden opgeslagen en wie ze roteert. Als een van die antwoorden de persoon is die de host heeft opgezet, is de optie daar nog niet veilig.