Statische sleutel of TLS voor een OpenVPN-verbinding tussen twee peers?

Twee machines die alleen met elkaar praten, kunnen die topologie behouden en toch onderhandelde verkeerssleutels krijgen. De netwerkvorm en de beschermingsmodus zijn onafhankelijke keuzes, en juist het verwarren daarvan zorgt ervoor dat mensen proberen een statisch geheim te roteren door een bestand te vervangen terwijl beide daemons blijven draaien. Het vervangen van het sleutelbestand onder een draaiend paar roteert niets. De statische-sleutelmodus, die OpenVPN 2.6 als verouderd markeert, houdt één sleutel voor de hele levensduur van de tunnel, dus het bestand op schijf en de sleutel in het geheugen komen pas weer overeen nadat beide uiteinden opnieuw zijn gestart. Als automatische vernieuwing de eis is, moet de beschermingsmodus veranderen.

Wat de statische-sleutelmodus niet kan

In de geheime modus delen beide peers een vooraf gedeelde sleutel die de tunnel rechtstreeks versleutelt en authenticeert. Er is geen handshake, dus er is geen mechanisme waarmee een kant nieuwe sleutelmateriaal kan voorstellen, een identiteit kan bewijzen of zonder ingrijpen van de operator van een afwijking kan herstellen. Beide eigenschappen volgen uit het ontbreken van een besturingskanaal en niet uit een ontbrekende optie, en geen configuratievlag voegt er een toe aan deze modus.

De OpenVPN 2.6-handleiding is duidelijk dat de sleutel blijft bestaan totdat een nieuwe wordt gegenereerd. Dat is aanvaardbaar voor een laboratoriumverbinding of een vast paar apparaten met een gedocumenteerde rotatieprocedure, en onaanvaardbaar waar een langdurig geheim een reëel risico is. Een bestandsvervanging maakt geen nieuwe sleutel voor een draaiend paar; ze maakt twee peers die het oneens zijn. Het vervangen van het bestand voegt dus een onderbreking toe zonder rotatie toe te voegen.

Er is ook geen begrip van peer-identiteit buiten het bezit van het bestand. Iedereen die de sleutel heeft, is een peer, en niets in de tunnel legt vast welke kant welke is, dus intrekking is alles of niets.

Overstappen op TLS zonder de verbinding opnieuw te ontwerpen

TLS-modus voegt een besturingskanaal toe, en daarmee de mogelijkheid om sleutels van het gegevenskanaal te onderhandelen. In een punt-tot-punt-implementatie neemt de ene kant de serverrol en de andere de clientrol, maar de topologie blijft een verbinding tussen twee peers: elke kant kent het eindpunt van de andere, en er verschijnt geen pool of multiuserdienst. De rollen zijn een detail van de handshake, geen nieuwe architectuur.

Geef elke machine een eigen identiteit. Elke kant heeft een certificaat en een privésleutel nodig, het vertrouwensanker dat de andere kant valideert, en een peer-verificatieregel die benoemt wie er wordt verwacht. Hergebruik de privésleutel van de ene peer niet op de andere om tijd te besparen; dat maakt van twee identiteiten één en haalt de mogelijkheid weg om elke kant afzonderlijk in te trekken. Inschrijving is de plek om dit goed te doen, want het later herstellen betekent certificaten opnieuw uitgeven.

Houd het netwerkcontract ongewijzigd terwijl de bescherming verandert. Dezelfde tunneladressen, routes en toegestane diensten moeten voor en na gelden, zodat een storing tijdens de migratie een beschermingsprobleem is en geen verklede routeringsverrassing. Schrijf de adressen en routes op vóór de wijziging; ze achteraf vergelijken is sneller dan ze uit het geheugen reconstrueren.

Sommige implementaties beschermen ook het besturingskanaal met een eigen statische sleutel, die niet met het gegevenskanaal meedraait. Die sleutel bewaakt de handshake en niet de payload, dus een compromis ervan legt de onderhandeling bloot en niet het verkeer. Bewaar hem apart van het materiaal van het gegevenskanaal, en geef hem een vervangingsdatum waar een genoemde persoon eigenaar van is. Hem roteren betekent beide peers opnieuw starten in een gecoördineerd venster, daarom verdient hij een agendapunt en niet een herinnering.

Wie vernieuwt wat, en wanneer

In TLS-modus wordt de vernieuwing gestuurd door geconfigureerde grenzen: een tijdsinterval, een byteaantal of een pakketaantal. De gedocumenteerde tijdcontrole is waarop de meeste implementaties vertrouwen, en de laagste effectieve waarde over de twee peers kan de vervanging starten, dus het alleen aan één kant verhogen houdt de gebeurtenis niet tegen. Grenzen op basis van volume bestaan omdat een drukke verbinding een sleutel veel eerder kan uitputten dan de klok. Geen van beide grenzen is een gezondheidscontrole en geen ervan vertelt u dat een vernieuwing is geslaagd.

Daarom is het misleidend om een terugkerende heronderhandeling uit één configuratiebestand te diagnosticeren. Lees de instellingen op beide peers en kijk dan naar de overgang in het logboek in plaats van een fout te veronderstellen. Een vernieuwing die schoon voltooit, ziet eruit als een korte uitbarsting besturingskanaalverkeer, niet als een verbreking.

Houd de objecten gescheiden in uw hoofd. Het certificaat bewijst langetermijnidentiteit en wordt vervangen volgens een schema dat u beheert. De sleutel van het gegevenskanaal wordt automatisch vernieuwd, en een aparte authenticatie-uitwisseling, als de implementatie er een vereist, volgt het accountbeleid en kan eigen afspraken nodig hebben voor latere uitwisselingen.

Vernieuwing volledig uitschakelen door het interval op nul te zetten is geen oplossing voor een lawaaierig logboek. Het verandert een gezond levenscyclusgebeurtenis in een permanente sleutel, wat u terugbrengt bij de eigenschap die u probeerde achter te laten.

De wijziging accepteren

Bouw de nieuwe configuratie uit het ondersteunde voorbeeld van de geïnstalleerde release, niet uit een oud minimaal fragment waarvan de algoritmen en bestandspaden elders zijn overgenomen. Coördineer de omschakeling zodat beide peers samen veranderen, en houd een goedgekeurd herstelpad achter de hand als één kant niet opstart. Haal de verbinding bewust neer in plaats van op een storing te wachten om de terugdraaiing te testen. Een terugdraaiing die u hebt geoefend is meer waard dan een die u hebt beschreven.

Test drie dingen: de eerste identiteitsverificatie slaagt, de bedoelde applicatiestroom werkt, en een gecontroleerde vernieuwing vindt plaats zonder verkeer te verliezen. Lees dan de overgang in het logboek voor wat die werkelijk bewijst: een nieuwe sleutelidentificatie betekent dat de peers een vervanging hebben voltooid, niet dat de tunnel opnieuw is verbonden. Behandel het als bewijs van één stap, en controleer de verkeerstellers voordat u de migratie als voltooid beschouwt.

Wat een belofte van geen onderbreking zou verbergen, is de fout die u nog niet hebt gezien. Een mislukte vernieuwing, een verlopen certificaat of een padstoring kunnen de verbinding nog steeds verstoren, en geen ervan wordt door een schone testloop uitgesloten. De eigenschap waarvoor het de moeite loont te ontwerpen is smaller en nuttiger: routinematige sleutelvervanging houdt op een handmatige bestandsvervanging te zijn.