Vad är ett WireGuard-handskakning — protokollet steg för steg

Kortversionen: WireGuard använder inte TLS och har inte en förhandling med flera rundturer som OpenVPN eller IPsec/IKEv2. Det använder en fast, åsiktsstyrd kryptografisk handshake härledd från Noise Protocol Framework — specifikt mönstret Noise_IK — som slutförs i exakt två meddelanden. Båda peers känner till varandras långsiktiga publika nycklar i förväg (konfigurerade statiskt, på samma sätt som SSH-nycklar konfigureras), så handshakens uppgift är inte att upptäcka identiteter utan att ömsesidigt bevisa att man har tillgång till motsvarande privata nycklar och att härleda nya symmetriska sessionsnycklar med forward secrecy. Hela transaktionen är liten nog att få plats i två UDP-datagram på några hundra byte vardera. Det slutförs snabbare än en TLS-handshake vanligtvis gör, och de resulterande sessionsnycklarna roteras var två minut under hela anslutningens livslängd.

Varför en handshake överhuvudtaget behövs

Två datorer vill kommunicera privat över ett nätverk de inte kontrollerar. Det grundläggande kryptografiska problemet: innan de kan kryptera något måste de komma överens om en gemensam hemlighet som en angripare som avlyssnar nätverket inte kan härleda. De måste också verifiera varandras identitet — annars kan en angripare utge sig för att vara den andra sidan och lura en av peers att kryptera data till angriparen istället.

En handshake löser båda problemen i ett strukturerat utbyte:

• Ömsesidig autentisering — varje peer visar att den har en privat nyckel som motsvarar en publik nyckel som den andra sidan redan litar på. Ingen peer sänder aldrig den privata nyckeln i sig; de bevisar bara att de har den genom att utföra kryptografiska operationer som bara den nyckeln kan producera.
• Forward-secret nyckelöverenskommelse — båda peers genererar färska, tillfälliga ("efemära") nyckelpar för just denna session, utbyter de publika halvorna och kombinerar dem med sina långsiktiga nycklar för att härleda en symmetrisk sessionsnyckel. De efemära nycklarna kasseras efter handshaken; även om de långsiktiga nycklarna stjäls senare kan inte tidigare sessionsnycklar rekonstrueras från dem. Denna egenskap kallas forward secrecy och är anledningen till att tidigare trafik förblir skyddad även om framtida nyckelkompromettering inträffar.
• Konfigurering av repelseringsskydd — båda peers initialiserar räknare och nonces som förhindrar att en angripare fångar och spelar upp tidigare trafik vid ett senare tillfälle.

Olika VPN-protokoll implementerar detta på olika sätt. OpenVPN gör det via TLS, med flera rundturer, certifikatvalidering och många konfigurerbara chiffer-sviter. IPsec/IKEv2 har ett eget förhandlingsprotokoll med liknande komplexitet. WireGuard gör det i två paket, utan konfigurerbarhet, utan förhandling om chiffer-svit — varje WireGuard-handshake använder samma fasta uppsättning kryptografiska primitiver. Avvägningen är avsiktlig: mindre komplexitet innebär en mindre attackyta och enklare granskningsbarhet, till priset av noll protokollnivå-smidighet.

Noise-ramverket — vad det är och varför WireGuard använder Noise_IK

Noise Protocol Framework är en specifikation för att bygga kryptografiska handshakes. Det är Trevor Perrins verk, som också designade Signal-protokollet som säkrar Signal, WhatsApp och de flesta moderna meddelandeappar med end-to-end-kryptering. Noise är inte ett enda protokoll — det är en verktygslåda med byggstenar (handshake-"mönster", kryptografiska primitiver, härledningsregler) som låter en protokolldesigner välja exakt den handshake-form de behöver och få en precis specifikation av vad meddelanden innehåller och vilka garantier de ger.

Noise-handshake-mönster namnges med två bokstäver som anger vad varje sida vet i förväg:

• N — ingen statisk nyckel för den sidan; endast efemära nycklar används. Anonym.
• K — den statiska nyckeln är "känd" av den andra parten i förväg.
• X — den statiska nyckeln skickas under handshaken.
• I — den statiska nyckeln sänds "omedelbart" i det första meddelandet.

Noise_IK betyder: initiatorn skickar sin statiska nyckel Omedelbart (i det första meddelandet), och respondentens statiska nyckel är Känd av initiatorn i förväg. Detta mönster är idealiskt för WireGuards användningsfall eftersom båda peers verkligen känner till varandras statiska nycklar i förväg — de är konfigurerade i WireGuards konfigurationsfil. "IK"-valet gör att hela handshaken kan slutföras i två meddelanden, vilket är det minsta möjliga för ett ömsesidigt autentiserat nyckelutbyte med forward secrecy.

Noise-ramverkets fullständiga specifikation publiceras på noiseprotocol.org och är ett av de renare exemplen på offentlig kryptografisk ingenjörskonst — skrivet för att vara granskningsbart, med formell verifiering av mönstren själva. WireGuards antagande av Noise_IK var ett medvetet designval för att ärva ramverkets analys.

Paket 1: Initiator → Respondent

Handshaken börjar när initiatorn (din telefon, din laptop, klientsidan) bestämmer sig för att prata med respondenten (VPN-servern). Detta sker antingen för att trafik köar och väntar på tunneln, eller för att sessionsnyckeln har gått ut och en omnyckeling behövs. Initiatorn konstruerar ett enda UDP-paket som innehåller:

• Sändarindex — ett slumpmässigt valt 32-bitars heltal som identifierar denna handshake-session. Används för att skilja på samtida handshakes mellan samma peers.
• Efemär publik nyckel — en nygenererad Curve25519-publik nyckel. Motsvarande privata nyckel hålls i minnet av initiatorn. Detta är "E" i Noise-mönstret — den nya efemära nyckeln som introduceras.
• Statisk publik nyckel (krypterad) — initiatorns långsiktiga Curve25519-publika nyckel, men krypterad med en nyckel härledd från det efemära utbytet. Detta är en del av "I" i IK — initiatorns statiska nyckel skickas i det första meddelandet men den är skyddad mot passiva observatörer.
• Tidsstämpel (krypterad) — en tidsstämpel i TAI64N-format, krypterad. Detta är ankaret för repelseringsskyddet: respondenten avvisar alla handshakes med en tidsstämpel som är äldre än en den redan accepterat från denna peer. Förhindrar att en angripare fångar och spelar upp ett giltigt handshake-meddelande senare.
• MAC-fält — två korta autentiserare (mac1, mac2) som bevisar att avsändaren känner till respondentens publika nyckel. Mac2-fältet används också för cookie-reply DoS-reduceringsmekanismen som beskrivs i WireGuard-dokumentet.

Vad detta paket bevisar och åstadkommer: genom att inkludera en ny efemär nyckel binder sig initiatorn till ena halvan av den slutliga sessionsnyckeln. Genom att inkludera tidsstämpeln och MAC:en knuten till respondentens statiska nyckel demonstrerar initiatorn "jag har åtminstone respondentens publika nyckel" — vilket innebär att en slumpmässig angripare utanför vägen inte trivialt kan skicka falska handshake-initiationer och slösa serverresurser. Hela paketet är 148 byte, passar bekvämt i ett enda UDP-datagram och fragmenteras aldrig.

En detalj värd att notera: initiatorns statiska publika nyckel inkluderas men är krypterad, så en passiv observatör som tittar på ledningen kan inte identifiera vilken klient som ansluter. De kan se att någon initierar en WireGuard-handshake till denna server, men inte vem. Denna integritetsegenskap kallas initiator identity hiding och är starkare än vad TLS ger som standard.

Paket 2: Respondent → Initiator

Respondenten tar emot initiationspaketet, dekrypterar initiatorns statiska publika nyckel och slår upp den i sin peer-tabell. Om peern är känd och tidsstämpeln är acceptabel (nyare än den senast accepterade), genererar respondenten sitt eget efemära nyckelpar och konstruerar ett svarspaket:

• Sändarindex — respondentens valda 32-bitars identifierare för denna session.
• Mottagarindex — ekas tillbaka från initiatorn, så att båda sidor är överens om vilken session detta är.
• Efemär publik nyckel — respondentens nygenererade efemära publika nyckel.
• Tom krypterad nyttolast — en autentiserad men tom chiffertext som bevisar att respondenten kan härleda sessionsnyckeln. Detta är den kryptografiska signalen "Jag läste ditt meddelande och beräknade rätt nyckel".
• MAC-fält — samma mönster som i initiationspaketet.

När initiatorn tar emot detta svar utför den den matchande nyckelgenereringen, verifierar att den autentiserade tomma nyttolasten dekrypteras korrekt med den härledda nyckeln, och nu har båda sidor kommit fram till samma symmetriska sessionsnyckel — oberoende av varandra, utan att den nyckeln någonsin passerat nätverket. Sessionsnyckeln har perfekt forward secrecy eftersom den beror på båda efemära nycklarna (som strax ska förstöras) och båda statiska nycklarna.

Svarspaketet är 92 byte. Den totala handshaken — båda paketen sammantaget — är 240 byte plus IP/UDP-huvuden, passar i två tur-och-retur UDP-utbyten som slutförs på ungefär en nätverks-RTT (ett paket varje väg), och producerar en fullt autentiserad forward-secret session redo att kryptera applikationstrafik. Det finns ingen certifikatkedjevalidering, ingen chiffer-svit-förhandling, ingen versionsj ämförelse, ingen utökningslista — ingen av de saker som gör TLS-handshakes komplicerade.

Sessionen som följer

När handshaken är klar utbyter de två peers datapaket i ett mycket enklare format. Varje datapaket innehåller:

• Mottagarindex — det 32-bitars sessions-ID som tilldelats av mottagaren under handshaken.
• Räknare — en 64-bitars nonce som ökar för varje skickat paket. Används både som AEAD-nonce och för repelseringsskydd.
• Krypterad nyttolast — det ursprungliga IP-paketet, krypterat med ChaCha20-Poly1305 med sessionsnyckeln och räknaren som nonce.

ChaCha20-Poly1305 är en AEAD-konstruktion (Authenticated Encryption with Associated Data): den krypterar både nyttolasten och producerar en autentiseringstagg som upptäcker manipulering. Om en enda bit i chiffertexten vänds misslyckas dekrypteringen, och mottagaren kastar paketet. Det finns inget "mjukt" felläge — modifierade paket kasseras tyst, precis som paket med fel räknare eller fel mottagarindex.

Mottagaren upprätthåller ett glidande fönster med accepterade räknarvärden. Paket med räknare som faller inom fönstret och inte setts tidigare accepteras; paket som faller under fönstret (för gamla) eller som setts avvisas. Detta ger repelseringsskydd utan att mottagaren behöver komma ihåg varje räknare som någonsin setts — bara de senaste, i en liten bitmapp.

Från nätverkets perspektiv ser datapaketen identiska ut oavsett nyttolastinnehåll. De är alla UDP-paket till samma server-IP och port, med liknande storlekar (den krypterade nyttolasten bevarar storleken på det underliggande IP-paketet plus 32 bytes overhead), och inget observerbart mönster som skiljer dem åt. Det finns ingen SNI, inget certifikatutbyte, ingen TLS-handshake-sedan-data-struktur — bara ogenomskinlig UDP efter den initiala tvåpaketshandshaken.

Omnyckelningsbeteende — var 2:a minut ELLER varje 2^60 paket

WireGuard roterar sessionsnycklar aggressivt. Standard omnyckelingspolicyn: en ny handshake initieras när den aktuella sessionen har varit aktiv i 2 minuter eller har sänts 2^60 paket, beroende på vad som inträffar först. I praktiken är tidsgränsen det som utlöser omnyckling för de flesta sessioner — 2^60 paket är ett astronomiskt stort antal som ingen verklig anslutning någonsin når.

Varför 2 minuter? Två skäl. Först förbättrar frekvent omnyckling forward secrecy. Varje session krypteras med en nyckel härledd från ett specifikt par efemära nycklar. Ju kortare sessionen är, desto mindre data flödar genom en enskild nyckel, så även teoretiska framtida kryptanalytiska attacker skulle behöva kompromissa med många nycklar för att läsa en meningsfull mängd trafik. För det andra är omnyckling osynlig för applikationen — den nya handshaken sker i bakgrunden medan de gamla sessionsnycklarna fortsätter att kryptera data, och övergången är sömlös. Båda peers upprätthåller ett litet överlappsfönster där de accepterar paket krypterade med antingen den gamla eller nya nyckeln.

Omnyckling initieras av vilken peer som märker att timern löper ut först — vanligtvis initiatorsidan. Protokollmeddelandet är samma tvåpaketshandshake som beskrivs ovan. Från en utomstående observatörs perspektiv ser de en liten skur av extra UDP-paket var två minut, men ingen observerbar förändring i dataströmmen i sig.

Handshake-faserna i korthet

Den fullständiga handshaken, uppdelad efter fas, paket och den kryptografiska primitiv som utför arbetet:

Fem kryptografiska primitiver används genomgående, ingen av dem förhandlingsbar: Curve25519 för elliptisk kurva Diffie-Hellman nyckelöverenskommelse, ChaCha20 för symmetrisk strömkryptering, Poly1305 för autentiseringstaggen, BLAKE2s för hashfunktionen och MAC, och HKDF för nyckelgenerering. Detta är designvalet "ingen smidighet": genom att hårdkoda primitiverna krymper protokollytan dramatiskt och analysen blir mycket mer hanterbar. Kostnaden är att om någon primitiv någonsin bryts behöver hela protokollet en ny version — det finns inget sätt att uppgradera i bandet. Vadslagningen WireGuard gör är att dessa primitiver är tillräckligt väl studerade för att ett plötsligt brott är osannolikt.

Vad som kan gå fel

Kryptografiska handshakes har kända fellägen. Vissa gäller WireGuard; andra gör det inte. Värt att förstå:

Repelseringsattacker

Den krypterade tidsstämpeln i initiationspaketet förhindrar repelseringar. Om en angripare fångar ett giltigt initiationspaket och försöker spela upp det senare, ser respondenten en tidsstämpel den redan accepterat (eller en som är äldre än den senast accepterade) och avvisar paketet. Det är ett av skälen till att WireGuard upprätthåller per-peer-tillstånd om den senaste handshake-tidsstämpeln — protokollet beror på det.

Kompromittering av långsiktig nyckel

Om en angripare stjäl en peers långsiktiga privata nyckel kan de utge sig för den peern i framtida handshakes. De kan dock inte dekryptera tidigare sessioner — de efemära nycklar som härledde dessa sessionsnycklar förstördes efter varje handshake. Det är forward-secrecy-garantin. Begränsningen för pågående risk är att rotera den långsiktiga nyckeln (generera ett nytt par, distribuera den nya publika nyckeln till peers) — det finns ingen protokollnivå-mekanism för att ogiltigförklara en gammal nyckel, så detta måste göras utanför bandet.

NAT-timeout och tyst anslutningsdöd

WireGuard körs över UDP, som är anslutningslöst. Nätverksadressöversättare (i din hemrouter eller ditt internetleverantörsnätverk) släpper ibland UDP-flödesposter efter några minuters inaktivitet. När detta händer kan respondentens svarspaket inte längre nå initiatorn — NAT:en har glömt mappningen. Begränsningen är keepalive-inställningen (ofta inställd på 25 sekunder), som skickar ett litet hjärtslagspaket från initiatorn till respondenten för att hålla NAT-mappningen vid liv. Utan keepalive kan inaktiva anslutningar tyst dö och kräva en ny handshake för att återupprättas.

Denial-of-service via handshake-översvämning

En respondent under kraftig attack kan ta emot många falska handshake-initiationer, var och en kräver Curve25519-operationer för att behandlas. WireGuard begränsar detta med cookie-reply-mekanismen: när respondenten är under belastning kan den kräva att initiatorn utför en liten proof-of-work-liknande beräkning innan respondenten förbinder sig till en fullständig handshake. Mac2-fältet i handshake-paketen bär denna mekanism. DoS-motståndet är inte perfekt — inget protokoll kan vara det — men det är väsentligt svårare att översvämma än t.ex. en oautentiserad TCP-baserad tjänst.

Varför detta praktiskt taget spelar roll för VPN-användare

Handshake-arkitekturen har konkreta användarsynliga fördelar jämfört med äldre VPN-protokoll:

• Ingen TLS-handshake på klientsidan — WireGuard validerar inte certifikat, kedjar inte till en CA, beror inte på systemets förtroendelager. Detta eliminerar en hel klass av attacker (komprometterade CA:er, felutfärdade certifikat) som drabbar TLS-baserade VPN:er.
• Ingen tillståndsfull anslutning — protokollet körs över UDP och är anslutningslöst. Det finns ingen TCP-liknande tillståndsmaskin att bryta när nätverket ändras. En roaming-enhet som växlar från Wi-Fi till mobilnät behöver inte återetablera något; den börjar bara skicka paket från den nya IP-adressen och respondenten accepterar dem.
• Omedelbar roaming — eftersom anslutningen identifieras av de kryptografiska nycklarna snarare än källans IP-adress accepterar respondenten paket från vilken käll-IP som helst som producerar korrekt kryptografisk autentisering. Det är därför WireGuard hanterar mobilnätövergångar mycket bättre än OpenVPN eller IPsec, som ofta behöver omförhandla när den underliggande IP:n ändras.
• Liten attackyta — referensimplementationen är ungefär 4 000 kodrader. OpenSSL är över 500 000. Detta är inte en rättvis jämförelse (de gör olika mängder arbete), men implikationen är verklig: mindre kod är lättare att granska, lättare att formellt analysera och ger färre möjligheter för implementeringsfel som blir sårbarheter.
• Förutsägbar prestanda — varje handshake använder samma primitiver med samma nyckelstorlekar. Det finns ingen snabb-väg/långsam-väg-divergens baserat på förhandlad chiffer-svit. Handshaken tar ungefär samma tid på samma hårdvara oavsett vem du ansluter till.

För jämförelsen av avvägningar med det äldre protokollet det ersatte för de flesta användare, se vår genomgång om WireGuard vs OpenVPN, som täcker praktiska prestanda- och säkerhetsskillnader. För varför en VPN:s tunnelval spelar roll för vad appar ser, se vad är split tunneling.

Casper's Cloak använder WireGuard för alla klientanslutningar, kör den officiella kernel-mode-implementationen på Linux-slutpunkter och levererar den vanliga userspace-klienten (byggd på wireguard-go-referensen) på iOS, Android och macOS. Handshaken som beskrivs ovan är exakt vad som händer när du slår på appen. Samma Noise_IK-mönster, samma Curve25519/ChaCha20-Poly1305/BLAKE2s/HKDF-primitivuppsättning, samma 2-minuters omnyckling, samma 240-byte-handshake. Funktionen hotskydd lägger DNS-nivåfiltrering ovanpå WireGuard-tunneln — tunneln hanterar transporten, filtret hanterar destinationspolicyn.

För den fullständiga protokollspecifikationen är det ursprungliga WireGuard-vitboken av Jason Donenfeld den auktoritativa referensen: wireguard.com/papers/wireguard.pdf. Dokumentet täcker den kryptografiska konstruktionen, hotmodellen, den formella analysen och implementeringsrationalen. Det är ett av de mer lättlästa exemplen på modern protokolldesignsskrivning — värt en timme att skumma igenom om du vill förstå designavvägningarna vid källan.

Slutsats: WireGuard-handshaken är två paket, tar under 100 millisekunder i praktiken, autentiserar båda peers ömsesidigt, härleder forward-secret sessionsnycklar och motstår varje vanligt attackmönster (repelseringar, nedgradering, identitetsavslöjande, DoS) av design. Det är ett stramt, fast, åsiktsstyrt protokoll, och den åsiktsstyrningen är precis poängen.