Wat 'n vooraf gedeelde sleutel in IPsec, OpenVPN en WireGuard doen

Die woorde vooraf gedeelde sleutel kom in die dokumentasie van IPsec, OpenVPN en WireGuard voor, maar beskryf drie verskillende objekte. Een is ’n verifikasiemgeheim, een beskerm ’n beheerkanaal, en een voeg materiaal by ’n handdruk wat reeds identiteite het. Om hulle as uitruilbaar te behandel lewer ’n verbinding wat in ’n fase misluk wat niemand verwag het nie. Lees wat die veld in daardie protokol doen voordat jy ’n waarde daarin kopieer.

Drie protokolle, drie betekenisse

Elke protokol bepaal die sleutel se taak in sy eie spesifikasie, en die take oorvleuel nie. ’n Verifikasiemgeheim bewys dat twee kante dieselfde waarde ken. ’n Sleutel vir die beheerkanaal beskerm die onderhandeling wat volg. ’n Byvoeging by die handdruk verander die sleutelskedule sonder om te verander wie die kante is.

Nie een van daardie rolle verifieer ’n mens nie, en juis daardie verwarring kos die meeste tyd. ’n Vooraf gedeelde sleutel word voor die uitruiling op toestelle of poorte geplaas, so elke houer lyk dieselfde vir die ander kant. Daardie eienskap is ’n voordeel vir ’n skakel tussen twee routers en ’n reële risiko vir ’n diens vir afstandtoegang met genoemde werknemers. Hou die rekeningbewys en die kriptografiese geheim in aparte kolomme van die dokument wat die ontplooiing beskryf.

IPsec en OpenVPN gebruik die woord anders

IKEv2 kan ’n eweknie met ’n vooraf gedeelde geheim in plaas van sertifikate verifieer, en die waarde moet aan beide kante ooreenstem. Omdat dieselfde geheim gewoonlik vir ’n groep kante opgestel word, kan enige houer hom as die ander voordoen, en die uitruiling wen geen vooruitwaartse geheimhouding uit identiteitsleutels wat dit nooit gehad het nie.

OpenVPN se tls-auth en tls-crypt opsies heg ’n statiese sleutel aan die beheerkanaal, deur ’n HMAC-handtekening by te voeg of die onderhandeling self te versleutel. Daardie sleutel is nie ’n gebruikerswagwoord nie en vervang nie die kliëntsertifikaat nie. Om die twee te onderskei maak saak by hernuwing, wanneer ’n wagwoordverandering die beheerkanaal se sleutel onaangeraak laat.

WireGuard se PSK voeg by, dit identifiseer nie

WireGuard-kante het reeds Curve25519-openbare en private sleutels, en die handdruk verifieer daardie identiteite. ’n Opsionele vooraf gedeelde sleutel word in die kettingleutel gemeng en dra simmetriese materiaal bo-op die uitruiling van openbare sleutels by.

Dit verskaf geen eie identiteit en geen gebruikersrekening nie, so ’n operateur kan twee houers nie aan hul PSK onderskei nie. Beide kante moet dieselfde waarde dra, anders misluk die handdruk sonder ’n nuttige foutboodskap. Daarom moet rotasie vir beide kante gelyktydig beplan word en nie as die wysiging van een lêer nie.

Kontroleer verspreiding, rotasie en verwydering

Verspreiding is die swak punt in elke ontwerp wat een geheim op baie plekke gebruik. ’n Waarde wat in ’n chatvenster geplak, in ’n bewaarplek gestoor of tussen omgewings hergebruik word, versamel afskrifte wat niemand kan opsom nie, en elke afskrif vergroot stil die skade.

Base64-teks is nie versleuteling nie. ’n Geheim wat langs ’n openbare sertifikaat in dieselfde gids gehou word, is steeds ’n geheim in klarteks.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Roteer volgens ’n skedule en ná enige vermoede blootstelling, en werk elke beoogde kant by voordat jy die ou waarde herroep. Toets daarna die skakel van beide kante, want ’n sleutel wat nie pas nie misluk by die handdruk en lyk presies soos ’n brandmuurprobleem.

Dokumenteer watter geheim watter fase beskerm, sodat ’n wagwoordherstel nooit met die hernuwing van ’n kriptografiese sleutel verwar word nie. Daardie een reël spaar ’n uur elke keer wanneer iemand die ontplooiing geëvalueer het.