Hva er et WireGuard-håndtrykk — protokollen steg for steg

Kortversjonen: WireGuard bruker ikke TLS, og protokollen har ikke en flerveis forhandling slik OpenVPN eller IPsec/IKEv2 har. Den bruker et fast, meningsbærende kryptografisk håndtrykk avledet fra Noise Protocol Framework — nærmere bestemt mønsteret Noise_IK — som fullføres i nøyaktig to meldinger. Begge nodene kjenner hverandres langsiktige offentlige nøkler på forhånd (konfigurert statisk, på samme måte som SSH-nøkler konfigureres), så håndtrykkens oppgave er ikke å oppdage identiteter, men å gjensidig bevise besittelse av tilhørende private nøkler og utlede ferske symmetriske øktsnøkler med fremoverhemmelighet. Hele transaksjonen er liten nok til å passe i to UDP-datagrammer på noen hundre byte hver. Den fullføres raskere enn et TLS-håndtrykk vanligvis gjør, og de resulterende øktsnøklene roteres hvert to minutt så lenge tilkoblingen varer.

Hvorfor et håndtrykk i det hele tatt eksisterer

To datamaskiner ønsker å kommunisere privat over et nettverk de ikke kontrollerer. Det grunnleggende kryptografiske problemet: før de kan kryptere noe som helst, må de bli enige om en felles hemmelighet som en angriper som overvåker nettverket ikke kan utlede. De må også verifisere hverandres identitet — ellers kunne en angriper utgi seg for å være den andre siden og lure en av nodene til å kryptere data til angriperen i stedet.

Et håndtrykk løser begge problemene i en strukturert utveksling:

• Gjensidig autentisering — hver node demonstrerer besittelse av en privat nøkkel som svarer til en offentlig nøkkel den andre siden allerede stoler på. Ingen node overfører noen gang den private nøkkelen i seg selv; de beviser bare at de har den ved å utføre kryptografiske operasjoner som bare den nøkkelen kan produsere.
• Fremoverhemmelig nøkkelavtale — begge nodene genererer ferske, midlertidige («efemere») nøkkelpar for denne spesifikke økten, utveksler de offentlige halvdelene, og kombinerer dem med sine langsiktige nøkler for å utlede en symmetrisk øktsnøkkel. De efemere nøklene forkastes etter håndtrykket; selv om de langsiktige nøklene blir stjålet senere, kan ikke tidligere øktsnøkler rekonstrueres fra dem. Denne egenskapen kalles fremoverhemmelighet, og det er grunnen til at tidligere trafikk forblir beskyttet selv om fremtidige nøkler kompromitteres.
• Oppsett av reproteverbeskyttelse — begge nodene initialiserer tellere og nonces som hindrer en angriper fra å fange opp og spille av tidligere trafikk senere.

Ulike VPN-protokoller implementerer dette på forskjellige måter. OpenVPN gjør det gjennom TLS, med flere tur-retur-utbyttinger, sertifikatvalidering og mange konfigurerbare kryptografiske suiter. IPsec/IKEv2 har sin egen forhandlingsprotokoll med tilsvarende kompleksitet. WireGuard gjør det i to pakker, uten konfigurerbarhet, uten forhandling av kryptografisk suite — hvert WireGuard-håndtrykk bruker det samme faste settet av kryptografiske primitiver. Avveiningen er bevisst: mindre kompleksitet betyr mindre angrepsflate og enklere revisjonsevne, til kostnad av null protokollnivå-smidighet.

Noise-rammeverket — hva det er og hvorfor WireGuard bruker Noise_IK

Noise Protocol Framework er en spesifikasjon for å bygge kryptografiske håndtrykk. Det er arbeidet til Trevor Perrin, som også designet Signal Protocol som sikrer Signal, WhatsApp og de fleste moderne ende-til-ende-krypterte meldingstjenester. Noise er ikke én enkelt protokoll — det er et sett med byggeklosser (håndtrykksmønstre, kryptografiske primitiver, utledningsregler) som lar en protokolldesigner velge nøyaktig den håndtrykkformen de trenger og få en presis spesifikasjon av hva meldinger inneholder og hvilke garantier de gir.

Noise-håndtrykksmønstre er navngitt med to bokstaver som indikerer hva hver side vet på forhånd:

• N — ingen statisk nøkkel for den siden; kun efemere nøkler brukes. Anonym.
• K — den statiske nøkkelen er «kjent» for den andre parten på forhånd.
• X — den statiske nøkkelen sendes under håndtrykket.
• I — den statiske nøkkelen overføres «umiddelbart» i den første meldingen.

Noise_IK betyr: initiativtakeren sender sin statiske nøkkel Umiddelbart (i den første meldingen), og respondentens statiske nøkkel er Kjent for initiativtakeren på forhånd. Dette mønsteret er ideelt for WireGuards brukstilfelle fordi begge nodene faktisk kjenner hverandres statiske nøkler på forhånd — de er konfigurert i WireGuard-konfigurasjonsfilen. «IK»-valget lar hele håndtrykket fullføres i to meldinger, noe som er det minste mulige for gjensidig autentisert fremoverhemmelig nøkkelutveksling.

Noise-rammeverkets fullstendige spesifikasjon er publisert på noiseprotocol.org og er et av de renere stykkene med offentlig kryptografisk ingeniørarbeid — skrevet for å være reviderbar, med formell verifisering av mønstrene i seg selv. WireGuards adopsjon av Noise_IK var et bevisst designvalg for å arve rammeverkets analyse.

Pakke 1: Initiativtaker → Respondent

Håndtrykket begynner når initiativtakeren (telefonen din, den bærbare datamaskinen din, klientsiden) bestemmer seg for å snakke med respondenten (VPN-serveren). Dette skjer enten fordi trafikk er i kø og venter på tunnelen, eller fordi øktsnøkkelen har utløpt og en rekryptering er nødvendig. Initiativtakeren konstruerer en enkelt UDP-pakke som inneholder:

• Avsenderindeks — et tilfeldig valgt 32-bits heltall som identifiserer denne håndtrykkøkten. Brukes til å skille mellom samtidige håndtrykk mellom de samme nodene.
• Efemer offentlig nøkkel — en nylig generert Curve25519 offentlig nøkkel. Den tilhørende private nøkkelen holdes i minnet av initiativtakeren. Dette er «E» i Noise-mønsteret — den nye efemere nøkkelen som introduseres.
• Statisk offentlig nøkkel (kryptert) — initiativtakerens langsiktige Curve25519 offentlige nøkkel, men kryptert med en nøkkel avledet fra den efemere utvekslingen. Dette er en del av «I» i IK — initiativtakerens statiske nøkkel sendes i den første meldingen, men den er beskyttet mot passive observatører.
• Tidsstempel (kryptert) — et tidsstempel i TAI64N-format, kryptert. Dette er reproteverbeskyttelsesankeret: respondenten vil avvise ethvert håndtrykk med et tidsstempel som er eldre enn ett den allerede har akseptert fra denne noden. Hindrer en angriper fra å fange opp og spille av en gyldig håndtrykkmelding senere.
• MAC-felt — to korte autentiseringer (mac1, mac2) som beviser at avsenderen kjenner respondentens offentlige nøkkel. Mac2-feltet brukes også for tjenesteavvisnings-begrensningsmekanismen for cookie-svar beskrevet i WireGuard-papiret.

Hva denne pakken beviser og oppnår: ved å inkludere en fersk efemer nøkkel, forplikter initiativtakeren seg til den ene halvdelen av den endelige øktsnøkkelen. Ved å inkludere tidsstempelet og MAC-en knyttet til respondentens statiske nøkkel, demonstrerer initiativtakeren «Jeg har i det minste respondentens offentlige nøkkel» — noe som betyr at en tilfeldig angriperen uten direkte tilgang ikke trivielt kan sende falske håndtrykksinitieringer og sløse med serverressurser. Hele pakken er 148 byte, passer komfortabelt i et enkelt UDP-datagram, og fragmenteres aldri.

En subtilitet verdt å merke seg: initiativtakerens statiske offentlige nøkkel er inkludert, men kryptert, slik at en passiv observatør som overvåker nettverket ikke kan identifisere hvilken klient som kobler til. De kan se at noen initierer et WireGuard-håndtrykk til denne serveren, men ikke hvem. Dette er en personvernsegenskap kalt skjuling av initiativtakeridentitet, og den er sterkere enn det TLS tilbyr som standard.

Pakke 2: Respondent → Initiativtaker

Respondenten mottar initieringspakken, dekrypterer initiativtakerens statiske offentlige nøkkel, og slår den opp i nodetabellen. Hvis noden er kjent og tidsstempelet er akseptabelt (nyere enn det sist aksepterte), genererer respondenten sitt eget efemere nøkkelpar og konstruerer en responspakke:

• Avsenderindeks — respondentens valgte 32-bits identifikator for denne økten.
• Mottakerindeks — ekkoet tilbake fra initiativtakeren, slik at begge sider er enige om hvilken økt dette er.
• Efemer offentlig nøkkel — respondentens nylig genererte efemere offentlige nøkkel.
• Tom kryptert nyttelast — en autentisert-men-tom chiffertekst som beviser at respondenten kan utlede øktsnøkkelen. Dette er det kryptografiske «Jeg leste meldingen din og beregnet riktig nøkkel»-signalet.
• MAC-felt — samme mønster som i initieringspakken.

Når initiativtakeren mottar dette svaret, utfører den den tilsvarende nøkkelutledningen, verifiserer at den autentiserte tomme nyttelasten dekrypteres riktig med den utledede nøkkelen, og nå har begge sider kommet frem til den samme symmetriske øktsnøkkelen — uavhengig, uten at nøkkelen noen gang passerer nettverket. Øktsnøkkelen har perfekt fremoverhemmelighet fordi den avhenger av begge efemere nøkler (som snart skal destrueres) og begge statiske nøkler.

Responspakken er 92 byte. Det totale håndtrykket — begge pakker kombinert — er 240 byte pluss IP/UDP-hoder, passer i to tur-retur UDP-utvekslinger som fullføres på omtrent én nettverks-RTT (én pakke hver vei), og produserer en fullt autentisert fremoverhemmelig økt klar til å kryptere applikasjonstrafikk. Det er ingen sertifikatkjedevalidering, ingen forhandling av kryptografisk suite, ingen versjonssammenligning, ingen utvidelsesliste — ingen av tingene som gjør TLS-håndtrykk kompliserte.

Økten som følger

Når håndtrykket er fullført, utveksler de to nodene datapakker i et mye enklere format. Hver datapakke inneholder:

• Mottakerindeks — den 32-bits økt-ID-en som mottakeren tildelte under håndtrykket.
• Teller — en 64-bits nonce som øker med hver sendte pakke. Brukes både som AEAD-nonce og for reproteverkdeteksjon.
• Kryptert nyttelast — den opprinnelige IP-pakken, kryptert med ChaCha20-Poly1305 ved bruk av øktsnøkkelen og telleren som nonce.

ChaCha20-Poly1305 er en AEAD (Authenticated Encryption with Associated Data)-konstruksjon: den krypterer både nyttelasten og produserer en autentiseringstag som oppdager eventuell manipulering. Hvis en enkelt bit av chifferteksten er endret, mislykkes dekrypteringen, og mottakeren forkaster pakken. Det er ingen «myk» feilmodus — modifiserte pakker droppes stille, akkurat som pakker med feil teller eller feil mottakerindeks.

Mottakeren opprettholder et glidende vindu av aksepterte tellerverdier. Pakker med tellere som faller innenfor vinduet og ikke er sett tidligere, aksepteres; pakker som faller under vinduet (for gamle) eller er sett, avvises. Dette gir reproteverbeskyttelse uten å kreve at mottakeren husker alle tellere som noen gang er sett — bare de nyeste, i et lite bitmap.

Fra nettverkets perspektiv ser datapakkene identiske ut uavhengig av nyttelastens innhold. De er alle UDP-pakker til samme server-IP og -port, med lignende størrelser (den krypterte nyttelasten bevarer størrelsen på den underliggende IP-pakken pluss 32 bytes overhead), og uten observerbart mønster som skiller dem. Det er ingen SNI, ingen sertifikatutveksling, ingen TLS-håndtrykk-deretter-data-struktur — bare ugjennomsiktig UDP etter det innledende to-pakkers håndtrykket.

Rekrypteringsatferd — hvert 2. minutt ELLER for hver 2^60 pakker

WireGuard roterer øktsnøkler aggressivt. Standard rekrypteringspolicy: et nytt håndtrykk initieres når den nåværende økten har vært aktiv i 2 minutter eller har overført 2^60 pakker, avhengig av hva som kommer først. I praksis er det tidsgrensen som utløser rekryptering for de fleste økter — 2^60 pakker er et astronomisk stort tall som ingen ekte tilkobling noen gang når.

Hvorfor 2 minutter? To grunner. For det første forbedrer hyppig rekryptering fremoverhemmeligheten. Hver økt er kryptert med en nøkkel avledet fra ett spesifikt par efemere nøkler. Jo kortere økten er, jo mindre data flyter gjennom en enkelt nøkkel, slik at selv teoretiske fremtidige kryptanalytiske angrep måtte kompromittere mange nøkler for å lese en meningsfull mengde trafikk. For det andre er rekrypteringen usynlig for applikasjonen — det nye håndtrykket skjer i bakgrunnen mens de gamle øktsnøklene fortsetter å kryptere data, og overgangen er sømløs. Begge nodene opprettholder et lite overlappingsvindu der de aksepterer pakker kryptert med enten den gamle eller den nye nøkkelen.

Rekrypteringen initieres av den noden som merker at timeren utløper først — vanligvis initiativtakersiden. Protokollmeldingen er det samme to-pakkers håndtrykket beskrevet ovenfor. Fra en ekstern observatørs perspektiv ser de et lite knippe ekstra UDP-pakker hvert to minutt, men ingen observerbar endring i selve datastrømmen.

Håndtrykksfaser på ett blikk

Det fullstendige håndtrykket, delt opp etter fase, pakke og den kryptografiske primitiven som utfører arbeidet:

Fem kryptografiske primitiver brukes gjennom hele protokollen, ingen av dem forhandlingsbare: Curve25519 for elliptisk-kurve Diffie-Hellman nøkkelavtale, ChaCha20 for symmetrisk strømkryptering, Poly1305 for autentiseringstagg, BLAKE2s for hashfunksjon og MAC, og HKDF for nøkkelutledning. Dette er «ingen smidighet»-designvalget: ved å hardkode primitivene krymper protokolloverflaten dramatisk og analysen blir mye mer overkommelig. Kostnaden er at hvis en primitiv noen gang brytes, trenger hele protokollen en ny versjon — det er ingen innebygd måte å oppgradere på. Veddemålet WireGuard gjør er at disse primitivene er tilstrekkelig gjennomforsket til at et plutselig brudd er usannsynlig.

Hva kan gå galt

Kryptografiske håndtrykk har kjente feilmodi. Noen gjelder for WireGuard; noen gjør det ikke. Verdt å forstå:

Reprotevertangrep

Det krypterte tidsstempelet i initieringspakken forhindrer reprotevertangrep. Hvis en angriper fanger opp en gyldig initieringspakke og forsøker å spille den av senere, ser respondenten et tidsstempel den allerede har akseptert (eller ett som er eldre enn det sist aksepterte) og avviser pakken. Dette er en av grunnene til at WireGuard opprettholder tilstand per node om det siste håndtrykkstidsstempelet — protokollen er avhengig av det.

Kompromittering av langsiktig nøkkel

Hvis en angriper stjeler en nodes langsiktige private nøkkel, kan de utgi seg for å være den noden i fremtidige håndtrykk. De kan imidlertid ikke dekryptere tidligere økter — de efemere nøklene som utledet disse øktsnøklene ble destruert etter hvert håndtrykk. Dette er fremoverhemmelighetsgarantien. Avbøtingstiltaket for pågående risiko er å rotere den langsiktige nøkkelen (generere et nytt par, distribuere den nye offentlige nøkkelen til noder) — det er ingen protokollnivåmekanisme for å ugyldiggjøre en gammel nøkkel, så dette må gjøres utenfor båndet.

NAT-tidsavbrudd og stille tilkoblingsdød

WireGuard kjører over UDP, som er tilkoblingsfritt. Nettverksadresseoversettere (i hjemmerouteren din eller ISP-nettverket ditt) dropper noen ganger UDP-flyentries etter noen minutters inaktivitet. Når dette skjer, kan respondentens svarspakker ikke lenger nå initiativtakeren — NAT-en har glemt kartleggingen. Avbøtingstiltaket er keepalive-innstillingen (ofte satt til 25 sekunder), som sender en liten hjerteslagspakke fra initiativtaker til respondent for å holde NAT-kartleggingen i live. Uten keepalive kan inaktive tilkoblinger stille dø og kreve et nytt håndtrykk for å gjenopprettes.

Tjenesteavvisning via håndtrykkflom

En respondent under kraftig angrep kan motta mange falske håndtrykksinitieringer, som hver krever Curve25519-operasjoner for å behandle. WireGuard begrenser dette med cookie-svar-mekanismen: når respondenten er under belastning, kan den kreve at initiativtakeren utfører en liten beregning av bevisarbeid-typen før respondenten forplikter seg til et fullt håndtrykk. Mac2-feltet i håndtrykkspakkene bærer denne mekanismen. Tjenesteavvisningsmotstanden er ikke perfekt — ingen protokoll kan være det — men den er vesentlig vanskeligere å oversvømme enn f.eks. en uautentisert TCP-basert tjeneste.

Hvorfor dette betyr noe for VPN-brukere i praksis

Håndtrykkarkitekturen har konkrete brukersynlige fordeler sammenlignet med eldre VPN-protokoller:

• Ingen TLS-håndtrykk på klientsiden — WireGuard validerer ikke sertifikater, kjeder ikke til en CA, er ikke avhengig av systemets tillitslagring. Dette eliminerer en hel klasse angrep (kompromitterte CA-er, feilutstedte sertifikater) som påvirker TLS-baserte VPN-er.
• Ingen stateful tilkobling — protokollen kjører over UDP og er tilkoblingsfri. Det er ingen TCP-lignende tilstandsmaskin som brytes når nettverket endrer seg. En roamende enhet som bytter fra Wi-Fi til mobilnett trenger ikke å gjenopprette noe; den begynner bare å sende pakker fra den nye IP-adressen, og respondenten aksepterer dem.
• Umiddelbar roaming — fordi tilkoblingen identifiseres av de kryptografiske nøklene snarere enn kilde-IP-adressen, vil respondenten akseptere pakker fra enhver kilde-IP som produserer riktig kryptografisk autentisering. Det er derfor WireGuard håndterer overganger i mobilnett langt bedre enn OpenVPN eller IPsec, som ofte må forhandle på nytt når den underliggende IP-en endres.
• Liten angrepsflate — referanseimplementasjonen er omtrent 4 000 linjer kode. OpenSSL er over 500 000. Dette er ikke en rettferdig sammenligning (de gjør ulike mengder arbeid), men implikasjonen er reell: mindre kode er lettere å revidere, lettere å formelt analysere, og gir færre muligheter for implementasjonsfeil som blir til sårbarheter.
• Forutsigbar ytelse — hvert håndtrykk bruker de samme primitivene ved de samme nøkkelstørrelsene. Det er ingen hurtigrute/langsomrute-divergens basert på forhandlet kryptografisk suite. Håndtrykket tar omtrent samme tid på samme maskinvare uavhengig av hvem du kobler til.

For avveiningssammenligningen med den eldre protokollen den erstattet for de fleste brukere, se vår gjennomgang av WireGuard vs OpenVPN, som dekker de praktiske ytelses- og sikkerhetsforskjellene. For hvorfor en VPN-tunnelvalg betyr noe for hva applikasjoner ser, se hva er delt tunneling.

Casper's Cloak bruker WireGuard for alle klienttilkoblinger, kjører den offisielle kjernemodusimplementasjonen på Linux-endepunkter, og leverer den standard brukermodus-klienten (bygget på wireguard-go-referansen) på iOS, Android og macOS. Håndtrykket beskrevet ovenfor er nøyaktig hva som skjer når du slår på appen. Det samme Noise_IK-mønsteret, det samme Curve25519/ChaCha20-Poly1305/BLAKE2s/HKDF-primitivsettet, den samme 2-minutters rekrypteringen, det samme 240-byte håndtrykket. Trusselsbeskyttelsesfunksjonen legger DNS-nivåfiltrering oppå WireGuard-tunnelen — tunnelen håndterer transport, filteret håndterer destinasjonspolicy.

For den fullstendige protokollspesifikasjonen er det originale WireGuard-hvitboken av Jason Donenfeld den autoritative referansen: wireguard.com/papers/wireguard.pdf. Papiret dekker den kryptografiske konstruksjonen, trusselmodellen, den formelle analysen og implementasjonsrasjonalet. Det er et av de mer lesevennlige stykkene med moderne protokolldesignskriving — verdt timen å skumme gjennom hvis du ønsker å forstå designavveiningene ved kilden.

Bunnlinjen: WireGuard-håndtrykket er to pakker, tar under 100 millisekunder i praksis, autentiserer begge noder gjensidig, utleder fremoverhemmelige øktsnøkler, og motstår alle vanlige angrepsmønstre (reprotevert, nedgradering, identitetsavsløring, tjenesteavvisning) av design. Det er en stram, fast, meningsbærende protokoll, og det er nettopp meningen med den meningsbæringen.