Kan jy ’n VPN-openbare sleutel deel? Kyk na hierdie drie dinge

Jy kan jou VPN-openbare sleutel aan ’n eweknie, ’n verskaffer of ’n forum gee, en die tonnel hou steeds. Jy kan nie die private sleutel oorhandig nie, selfs nie aan ondersteuningspersoneel nie, sonder om die identiteit oor te dra wat daardie sleutel bewys. Die besluit bly selde so skoon, want mense verwar watter helfte van die paar hulle bekyk, en omdat sommige ontplooiings die openbare waarde as ’n naam behandel. Drie kontroles beslis dit: watter helfte jy het, waaraan die ontplooiing dit bind, en wat vervanging kos.

Kontrole een: watter helfte van die paar is in jou knipbord

Asimmetriese sleutels kom in pare, en die rigting van afleiding is die hele punt. In WireGuard is die private sleutel 32 ewekansige grepe en die openbare sleutel word daaruit bereken; jy kan nie die ander kant toe nie. wg genkey skryf die private waarde, wg pubkey lei die openbare een af, en net die tweede hoort in ’n boodskap aan ’n eweknie.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

Die sertifikaatwêreld gebruik dieselfde splitsing met meer bewegende dele. ’n Bediener-sertifikaat dra ’n openbare sleutel plus name, en dit word deur ’n CA-private sleutel onderteken wat nooit die CA verlaat nie. ’n Kliënt wat daardie bediener verifieer, het die CA-sertifikaat nodig, wat openbaar is, en het geen nut vir die CA se private ondertekeningsleutel nie.

As jy onseker is watter waarde jy vashou, kyk na die merker eerder as die lêernaam. ’n PEM-blok wat begin met -----BEGIN PRIVATE KEY-----, of die ouer BEGIN RSA PRIVATE KEY-vorm, is die geheime helfte. ’n Waarde wat jy sonder daardie merker kan plak, is ’n kandidaat om te deel, onderworpe aan die volgende twee kontroles.

Kontrole twee: waaraan die ontplooiing daardie openbare waarde bind

Kriptografiese veiligheid en anonimiteit is verskillende eienskappe. ’n WireGuard-eweknie se openbare sleutel is ’n stabiele identifiseerder binne die ontplooiing: die bedienerkonfigurasie lys dit, die handdruk noem dit, en ’n administrateur wat logs lees, sien elke keer dieselfde string wanneer daardie eweknie verbind. Plaas die sleutel langs ’n vraag oor jou opstelling, en jy het daardie string aan alles anders in die plasing gekoppel.

Sertifikate lek identiteit by ontwerp. Subject- en subject alternative name-velde is leesbaar, en vir publiek-vertroude TLS-sertifikate word die sertifikaat self na Certificate Transparency-logs gepubliseer, wat deursoekbaar is. Niks daarvan stel ’n private sleutel bloot nie, en dit alles stel ’n verhouding bloot.

Dit is waar ontplooiings verskil, en dit beslis die antwoord. ’n Weggooi-toets-eweknie op ’n laboratoriumbediener is ’n ander objek as die sleutel wat ’n maatskappy se werf-tot-werf-eindpunt identifiseer, al lyk die grepe identies.

Kontrole drie: wat jy kan herroep, en hoe vinnig

Die derde kontrole skei die twee helftes heeltemal. ’n Openbare sleutel wat gepubliseer is, kan volgens jou skedule vervang word. ’n Private sleutel wat gepubliseer is, kan nie teruggeroep word nie: om jou kopie te skrap raak nie kopieë wat reeds geneem is nie, en elke eweknie wat dit vertrou het, vertrou nou iets wat ’n buitestaander hou.

Herroeping is ’n konfigurasie-aksie, nie ’n kriptografiese een nie. WireGuard lewer geen herroepingslys nie, so jy verwyder die eweknie:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN-ontplooiings wat op sertifikate gebou is, herroep die sertifikaat en publiseer ’n CRL wat die bediener werklik deur crl-verify nagaan. Sonder daardie richtlijn is die herroepingslys versiering. Hoe dit ook al sy, die volgorde is dieselfde: reik ’n vervanging uit, versprei dit deur die ondersteunde kanaal en trek dan die ou identiteit terug.

Die foute wat uit die ineenstorting van die drie kontroles kom

Die meeste werklike lekke is nie ’n persoon wat besluit om ’n private sleutel te publiseer nie. Dit is ’n hele profiel wat in ’n forum geplak is: ’n WireGuard .conf met ’n PrivateKey-reël, ’n .ovpn-bondel met ’n inline sleutelblok, of ’n skermkiekie van ’n kliëntvenster wat toevallig die sleutelveld insluit. Die openbare waarde was waarskynlik reg; dit het saam met die deel gereis wat nie reg was nie.

Ondersteuningswerksvloei is die tweede bron. Geen wettige verifiëringstap het jou private sleutel nodig nie, want die ander kant lei wat dit nodig het uit die openbare helfte af. Wanneer ’n vorm of ’n persoon na die private waarde vra, is die korrekte antwoord die openbare een plus die plaaslike opdrag wat dit produseer.

Logs en skermkiekies hoort in dieselfde kategorie. Diagnostiese uitsette kan sleutelmateriaal, sessie-identifiseerders en interne adresse dra, en om dit alles te plaas om een vraag beantwoord te kry, ruil ’n klein gerief vir ’n groter blootstelling.

Nadat ’n private waarde gelek het, trek die identiteit terug

As ’n private waarde wel uitgekom het, beskou daardie identiteit as afgetree. Genereer ’n nuwe paar, installeer die openbare helfte waar eweknieë dit verwag, verwyder die ou eweknie of herroep die ou sertifikaat, en gaan na die plekke waar jy dit gepubliseer het. Jy kan nie kopieë wat jy nie beheer nie, uitvee nie, so verwydering gaan oor die toekoms, nie die verlede nie.

Skryf dan die verspreiding neer: watter sleutel aan watter toestel behoort, wie ’n kopie hou, hoe ’n vervanging gelewer word, en wie ’n afgetrede eweknie verwyder. Dit is die dele wat mense vergeet, en dit bepaal hoe lank ’n lek nuttig bly.