Was ist ein WireGuard-Handshake – das Protokoll Schritt für Schritt

Kurzfassung: WireGuard verwendet kein TLS und hat keine mehrstufige Aushandlung wie OpenVPN oder IPsec/IKEv2. Es nutzt einen festen, meinungsstarken kryptografischen Handshake, der vom Noise Protocol Framework abgeleitet ist – konkret das Noise_IK-Muster – und in exakt zwei Nachrichten abgeschlossen wird. Beide Peers kennen die langfristigen öffentlichen Schlüssel des jeweils anderen im Voraus (statisch konfiguriert, ähnlich wie SSH-Schlüssel), daher besteht die Aufgabe des Handshakes nicht darin, Identitäten zu entdecken, sondern gegenseitig den Besitz der entsprechenden privaten Schlüssel zu beweisen und frische symmetrische Sitzungsschlüssel mit Forward Secrecy abzuleiten. Die gesamte Transaktion ist klein genug, um in zwei UDP-Datagrammen von je einigen hundert Bytes Platz zu finden. Sie läuft schneller ab als ein TLS-Handshake in der Regel, und die resultierenden Sitzungsschlüssel rotieren für die Dauer der Verbindung alle zwei Minuten.

Warum ein Handshake überhaupt nötig ist

Zwei Computer wollen privat über ein Netzwerk kommunizieren, das sie nicht kontrollieren. Das grundlegende kryptografische Problem: Bevor sie irgendetwas verschlüsseln können, müssen sie sich auf ein gemeinsames Geheimnis einigen, das ein Angreifer, der das Netzwerk beobachtet, nicht ableiten kann. Außerdem müssen sie die Identität des anderen verifizieren – sonst könnte ein Angreifer die andere Seite imitieren und einen der Peers dazu bringen, Daten an den Angreifer statt an den echten Kommunikationspartner zu verschlüsseln.

Ein Handshake löst beide Probleme in einem strukturierten Austausch:

• Gegenseitige Authentifizierung – jeder Peer beweist, dass er einen privaten Schlüssel besitzt, der zu einem öffentlichen Schlüssel gehört, dem die andere Seite bereits vertraut. Keiner der Peers überträgt jemals den privaten Schlüssel selbst; sie beweisen seinen Besitz lediglich durch kryptografische Operationen, die nur dieser Schlüssel erzeugen kann.
• Forward-Secret-Schlüsselvereinbarung – beide Peers generieren für diese spezifische Sitzung frische, temporäre („ephemere“) Schlüsselpaare, tauschen die öffentlichen Hälften aus und kombinieren sie mit ihren langfristigen Schlüsseln, um einen symmetrischen Sitzungsschlüssel abzuleiten. Die ephemeren Schlüssel werden nach dem Handshake verworfen; selbst wenn die langfristigen Schlüssel später gestohlen werden, können die vergangenen Sitzungsschlüssel daraus nicht rekonstruiert werden. Diese Eigenschaft heißt Forward Secrecy und ist der Grund, warum vergangener Datenverkehr auch nach einer zukünftigen Schlüsselkompromittierung geschützt bleibt.
• Replay-Schutz-Setup – beide Peers initialisieren Zähler und Nonces, die verhindern, dass ein Angreifer früheren Datenverkehr später erneut einspielen kann.

Verschiedene VPN-Protokolle implementieren dies unterschiedlich. OpenVPN tut es über TLS, mit mehreren Hin- und Rückläufen, Zertifikatsvalidierung und vielen konfigurierbaren Cipher Suites. IPsec/IKEv2 hat sein eigenes Aushandlungsprotokoll mit ähnlicher Komplexität. WireGuard erledigt es in zwei Paketen, ohne Konfigurierbarkeit, ohne Cipher-Suite-Aushandlung – jeder WireGuard-Handshake verwendet denselben festen Satz kryptografischer Primitive. Der Kompromiss ist beabsichtigt: weniger Komplexität bedeutet weniger Angriffsfläche und einfachere Überprüfbarkeit, auf Kosten von keinerlei Protokoll-Agilität.

Das Noise-Framework – was es ist und warum WireGuard Noise_IK verwendet

Das Noise Protocol Framework ist eine Spezifikation zum Aufbau kryptografischer Handshakes. Es ist das Werk von Trevor Perrin, der auch das Signal-Protokoll entworfen hat, das Signal, WhatsApp und die meisten modernen Ende-zu-Ende-verschlüsselten Messenger absichert. Noise ist kein einzelnes Protokoll – es ist ein Baukasten (Handshake-„Muster“, kryptografische Primitive, Ableitungsregeln), der einem Protokolldesigner ermöglicht, genau die benötigte Handshake-Form auszuwählen und eine präzise Spezifikation zu erhalten, was Nachrichten enthalten und welche Garantien sie bieten.

Noise-Handshake-Muster werden mit zwei Buchstaben benannt, die angeben, was jede Seite im Voraus weiß:

• N – kein statischer Schlüssel für diese Seite; nur ephemere Schlüssel werden verwendet. Anonym.
• K – der statische Schlüssel ist der anderen Partei vorab „bekannt“ (Known).
• X – der statische Schlüssel wird während des Handshakes gesendet.
• I – der statische Schlüssel wird „sofort“ (Immediately) in der ersten Nachricht übermittelt.

Noise_IK bedeutet: der Initiator sendet seinen statischen Schlüssel sofort (in der ersten Nachricht), und der statische Schlüssel des Responders ist dem Initiator vorab bekannt. Dieses Muster ist ideal für WireGuards Anwendungsfall, da beide Peers die statischen Schlüssel des jeweils anderen tatsächlich vorab kennen – sie sind in der WireGuard-Konfigurationsdatei konfiguriert. Die „IK“-Wahl ermöglicht es, den gesamten Handshake in zwei Nachrichten abzuschließen, was das Minimum für einen gegenseitig authentifizierten, forward-secret Schlüsselaustausch ist.

Die vollständige Spezifikation des Noise-Frameworks ist unter noiseprotocol.org veröffentlicht und ist eines der durchdachteren Stücke öffentlicher kryptografischer Ingenieurskunst – geschrieben für Überprüfbarkeit, mit formaler Verifikation der Muster selbst. WireGuards Übernahme von Noise_IK war eine bewusste Designentscheidung, um von der Analyse des Frameworks zu profitieren.

Paket 1: Initiator → Responder

Der Handshake beginnt, wenn der Initiator (dein Smartphone, dein Laptop, die Client-Seite) beschließt, mit dem Responder (dem VPN-Server) zu kommunizieren. Dies geschieht entweder, weil Datenverkehr in der Warteschlange steht und auf den Tunnel wartet, oder weil der Sitzungsschlüssel abgelaufen ist und ein Rekey benötigt wird. Der Initiator konstruiert ein einzelnes UDP-Paket, das enthält:

• Sender-Index – eine zufällig gewählte 32-Bit-Ganzzahl, die diese Handshake-Sitzung identifiziert. Dient zur Unterscheidung gleichzeitiger Handshakes zwischen denselben Peers.
• Ephemerer öffentlicher Schlüssel – ein frisch erzeugter Curve25519-öffentlicher Schlüssel. Der entsprechende private Schlüssel wird im Speicher des Initiators gehalten. Dies ist das „E“ im Noise-Muster – der neue ephemere Schlüssel, der eingeführt wird.
• Statischer öffentlicher Schlüssel (verschlüsselt) – der langfristige Curve25519-öffentliche Schlüssel des Initiators, jedoch mit einem aus dem ephemeren Austausch abgeleiteten Schlüssel verschlüsselt. Dies ist Teil des „I“ in IK – der statische Schlüssel des Initiators wird in der ersten Nachricht gesendet, ist aber gegen passive Beobachter geschützt.
• Zeitstempel (verschlüsselt) – ein TAI64N-formatierter Zeitstempel, verschlüsselt. Dies ist der Replay-Schutz-Anker: Der Responder lehnt jeden Handshake mit einem Zeitstempel ab, der älter ist als einer, den er von diesem Peer bereits akzeptiert hat. Verhindert, dass ein Angreifer eine gültige Handshake-Nachricht einfängt und später erneut einspielt.
• MAC-Felder – zwei kurze Authentifikatoren (mac1, mac2), die beweisen, dass der Sender den öffentlichen Schlüssel des Responders kennt. Das mac2-Feld wird auch für den Cookie-Reply-DoS-Abwehrmechanismus verwendet, der im WireGuard-Paper beschrieben ist.

Was dieses Paket beweist und leistet: Durch das Einschließen eines frischen ephemeren Schlüssels verpflichtet sich der Initiator zu einer Hälfte des späteren Sitzungsschlüssels. Durch das Einschließen des Zeitstempels und des MAC, der an den statischen Schlüssel des Responders gebunden ist, demonstriert der Initiator: „Ich habe zumindest den öffentlichen Schlüssel des Responders“ – was bedeutet, dass ein zufälliger Off-Path-Angreifer keine gefälschten Handshake-Initiierungen senden und Serverressourcen verschwenden kann. Das gesamte Paket ist 148 Bytes groß, passt problemlos in ein einzelnes UDP-Datagramm und wird niemals fragmentiert.

Eine bemerkenswerte Besonderheit: Der statische öffentliche Schlüssel des Initiators ist zwar enthalten, aber verschlüsselt, sodass ein passiver Beobachter, der die Leitung überwacht, nicht erkennen kann, welcher Client sich verbindet. Er kann sehen, dass jemand einen WireGuard-Handshake mit diesem Server initiiert, aber nicht wer. Diese Datenschutzeigenschaft heißt Initiator-Identitätsverbergung und ist stärker als das, was TLS standardmäßig bietet.

Paket 2: Responder → Initiator

Der Responder empfängt das Initiierungspaket, entschlüsselt den statischen öffentlichen Schlüssel des Initiators und schlägt ihn in seiner Peer-Tabelle nach. Wenn der Peer bekannt ist und der Zeitstempel akzeptabel ist (neuer als der zuletzt akzeptierte), generiert der Responder sein eigenes ephemeres Schlüsselpar und konstruiert ein Antwortpaket:

• Sender-Index – der vom Responder gewählte 32-Bit-Bezeichner für diese Sitzung.
• Receiver-Index – vom Initiator zurückgegeben, damit beide Seiten wissen, um welche Sitzung es sich handelt.
• Ephemerer öffentlicher Schlüssel – der frisch generierte ephemere öffentliche Schlüssel des Responders.
• Leeres verschlüsseltes Payload – ein authentifizierter, aber leerer Chiffretext, der beweist, dass der Responder den Sitzungsschlüssel ableiten kann. Dies ist das kryptografische Signal: „Ich habe deine Nachricht gelesen und den richtigen Schlüssel berechnet.“
• MAC-Felder – dasselbe Muster wie beim Initiierungspaket.

Wenn der Initiator diese Antwort empfängt, führt er die passende Schlüsselableitung durch, verifiziert, dass das authentifizierte leere Payload mit dem abgeleiteten Schlüssel korrekt entschlüsselt wird, und nun sind beide Seiten unabhängig beim selben symmetrischen Sitzungsschlüssel angelangt – ohne dass dieser Schlüssel jemals das Netzwerk durchquert hat. Der Sitzungsschlüssel hat perfekte Forward Secrecy, da er von beiden ephemeren Schlüsseln (die gleich vernichtet werden) und beiden statischen Schlüsseln abhängt.

Das Antwortpaket ist 92 Bytes groß. Der gesamte Handshake – beide Pakete zusammen – beträgt 240 Bytes plus IP/UDP-Header, passt in zwei UDP-Roundtrip-Austausche, die in etwa einer Netzwerk-RTT abgeschlossen werden (ein Paket in jede Richtung), und erzeugt eine vollständig authentifizierte, forward-secret Sitzung, die bereit ist, Anwendungsdaten zu verschlüsseln. Es gibt keine Zertifikatsketten-Validierung, keine Cipher-Suite-Aushandlung, keinen Versionsvergleich, keine Erweiterungsliste – nichts von dem, was TLS-Handshakes kompliziert macht.

Die darauffolgende Sitzung

Sobald der Handshake abgeschlossen ist, tauschen die zwei Peers Datenpakete in einem viel einfacheren Format aus. Jedes Datenpaket enthält:

• Receiver-Index – die 32-Bit-Sitzungs-ID, die der Empfänger während des Handshakes zugewiesen hat.
• Zähler – ein 64-Bit-Nonce, der mit jedem gesendeten Paket inkrementiert wird. Dient sowohl als AEAD-Nonce als auch zur Replay-Erkennung.
• Verschlüsseltes Payload – das ursprüngliche IP-Paket, verschlüsselt mit ChaCha20-Poly1305 unter Verwendung des Sitzungsschlüssels und des Zählers als Nonce.

ChaCha20-Poly1305 ist eine AEAD-Konstruktion (Authenticated Encryption with Associated Data): Sie verschlüsselt nicht nur das Payload, sondern erzeugt auch ein Authentifizierungs-Tag, das jede Manipulation erkennt. Wenn ein einziges Bit des Chiffretextes geändert wird, schlägt die Entschlüsselung fehl, und der Empfänger verwirft das Paket. Es gibt keinen „weichen“ Fehlermodus – manipulierte Pakete werden stillschweigend verworfen, genau wie Pakete mit falschem Zähler oder falschem Receiver-Index.

Der Empfänger pflegt ein gleitendes Fenster akzeptierter Zählerwerte. Pakete mit Zählern, die in das Fenster fallen und noch nicht gesehen wurden, werden akzeptiert; Pakete, die unterhalb des Fensters liegen (zu alt) oder bereits gesehen wurden, werden abgelehnt. Dies bietet Anti-Replay-Schutz, ohne dass der Empfänger jeden jemals gesehenen Zähler speichern muss – nur die jüngsten, in einer kleinen Bitmap.

Aus Netzwerkperspektive sehen die Datenpakete unabhängig vom Payload-Inhalt identisch aus. Es sind alles UDP-Pakete an dieselbe Server-IP und denselben Port, mit ähnlichen Größen (das verschlüsselte Payload bewahrt die Größe des zugrunde liegenden IP-Pakets plus 32 Bytes Overhead), und es gibt kein beobachtbares Muster, das sie unterscheidet. Es gibt kein SNI, keinen Zertifikatsaustausch, keine TLS-Handshake-dann-Daten-Struktur – nur undurchsichtiges UDP nach dem anfänglichen Zwei-Paket-Handshake.

Rekey-Verhalten – alle 2 Minuten ODER alle 2^60 Pakete

WireGuard rotiert Sitzungsschlüssel aggressiv. Die Standard-Rekey-Richtlinie: Ein neuer Handshake wird initiiert, wenn die aktuelle Sitzung seit 2 Minuten aktiv ist oder 2^60 Pakete übertragen hat, je nachdem, was zuerst eintritt. In der Praxis ist die Zeitbindung das, was für die meisten Sitzungen das Rekey auslöst – 2^60 Pakete ist eine astronomisch große Zahl, die keine echte Verbindung jemals erreicht.

Warum 2 Minuten? Zwei Gründe. Erstens verbessert häufiges Rekey die Forward Secrecy. Jede Sitzung ist mit einem Schlüssel verschlüsselt, der aus einem spezifischen Paar ephemerer Schlüssel abgeleitet wird. Je kürzer die Sitzung, desto weniger Daten fließen durch einen einzigen Schlüssel, sodass selbst theoretische zukünftige kryptoanalytische Angriffe viele Schlüssel kompromittieren müssten, um eine bedeutende Datenmenge zu lesen. Zweitens ist das Rekey für die Anwendung unsichtbar – der neue Handshake findet im Hintergrund statt, während die alten Sitzungsschlüssel weiterhin Daten verschlüsseln, und der Übergang ist nahtlos. Beide Peers pflegen ein kleines Überlappungsfenster, in dem sie Pakete akzeptieren, die entweder mit dem alten oder dem neuen Schlüssel verschlüsselt sind.

Das Rekey wird von dem Peer initiiert, der zuerst bemerkt, dass der Timer abgelaufen ist – normalerweise die Initiator-Seite. Die Protokollnachricht ist derselbe Zwei-Paket-Handshake wie oben beschrieben. Aus der Perspektive eines externen Beobachters sehen sie alle zwei Minuten eine kleine Häufung zusätzlicher UDP-Pakete, aber keine beobachtbare Änderung im Datenstrom selbst.

Handshake-Phasen auf einen Blick

Der vollständige Handshake, aufgeteilt nach Phase, Paket und dem kryptografischen Primitiv, das die Arbeit erledigt:

Fünf kryptografische Primitive werden durchgehend verwendet, keines davon verhandelbar: Curve25519 für elliptische-Kurven-Diffie-Hellman-Schlüsselvereinbarung, ChaCha20 für symmetrische Stromverschlüsselung, Poly1305 für das Authentifizierungs-Tag, BLAKE2s für die Hashfunktion und MAC sowie HKDF für die Schlüsselableitung. Dies ist die „No-Agility“-Designentscheidung: Durch die Festcodierung der Primitive schrumpft die Protokolloberfläche dramatisch und die Analyse wird viel handhabbarer. Der Preis ist, dass wenn ein Primitiv jemals gebrochen wird, das gesamte Protokoll eine neue Version benötigt – es gibt keine In-Band-Methode zum Upgrade. Die Wette, die WireGuard eingeht, ist, dass diese Primitive hinreichend gut untersucht sind, dass ein plötzlicher Bruch unwahrscheinlich ist.

Was schiefgehen kann

Kryptografische Handshakes haben bekannte Fehlermodi. Einige gelten für WireGuard; andere nicht. Es lohnt sich, sie zu verstehen:

Replay-Angriffe

Der verschlüsselte Zeitstempel im Initiierungspaket verhindert Replays. Wenn ein Angreifer ein gültiges Initiierungspaket einfängt und später erneut einspielt, sieht der Responder einen Zeitstempel, den er bereits akzeptiert hat (oder einen, der älter als der zuletzt akzeptierte ist), und lehnt das Paket ab. Dies ist einer der Gründe, warum WireGuard einen Pro-Peer-Zustand über den letzten Handshake-Zeitstempel pflegt – das Protokoll hängt davon ab.

Kompromittierung langfristiger Schlüssel

Wenn ein Angreifer den langfristigen privaten Schlüssel eines Peers stiehlt, kann er diesen Peer bei zukünftigen Handshakes imitieren. Er kann jedoch keine vergangenen Sitzungen entschlüsseln – die ephemeren Schlüssel, die diese Sitzungsschlüssel abgeleitet haben, wurden nach jedem Handshake vernichtet. Dies ist die Forward-Secrecy-Garantie. Die Minderung für laufende Risiken besteht darin, den langfristigen Schlüssel zu rotieren (ein neues Paar zu generieren, den neuen öffentlichen Schlüssel an die Peers zu verteilen) – es gibt keinen protokollseitigen Mechanismus zur Ungiltigmachung eines alten Schlüssels, daher muss dies out-of-band erfolgen.

NAT-Timeout und stiller Verbindungstod

WireGuard läuft über UDP, das verbindungslos ist. Network Address Translators (in deinem Heimrouter oder dem Netzwerk deines ISPs) verwerfen manchmal UDP-Flow-Einträge nach einigen Minuten Inaktivität. Wenn dies geschieht, können die Antwortpakete des Responders den Initiator nicht mehr erreichen – der NAT hat das Mapping vergessen. Die Minderung ist die Keepalive-Einstellung (oft auf 25 Sekunden gesetzt), die ein kleines Heartbeat-Paket vom Initiator zum Responder sendet, um das NAT-Mapping am Leben zu erhalten. Ohne Keepalive können idle Verbindungen stillschweigend sterben und erfordern einen neuen Handshake zur Wiederherstellung.

Denial-of-Service durch Handshake-Flut

Ein Responder unter schwerem Angriff könnte viele gefälschte Handshake-Initiierungen empfangen, von denen jede Curve25519-Operationen zur Verarbeitung erfordert. WireGuard mindert dies mit dem Cookie-Reply-Mechanismus: Wenn der Responder unter Last steht, kann er verlangen, dass der Initiator eine kleine Proof-of-Work-ähnliche Berechnung durchführt, bevor der Responder sich zu einem vollständigen Handshake verpflichtet. Das mac2-Feld in den Handshake-Paketen trägt diesen Mechanismus. Die DoS-Resistenz ist nicht perfekt – kein Protokoll kann das sein – aber sie ist deutlich schwieriger zu überfluten als z. B. ein nicht authentifizierter TCP-basierter Dienst.

Warum das für VPN-Nutzer praktisch relevant ist

Die Handshake-Architektur hat konkrete, für den Nutzer sichtbare Vorteile gegenüber älteren VPN-Protokollen:

• Kein clientseitiger TLS-Handshake – WireGuard validiert keine Zertifikate, kettet nicht zu einer CA und hängt nicht vom System-Truststore ab. Dies eliminiert eine ganze Klasse von Angriffen (kompromittierte CAs, falsch ausgestellte Zertifikate), die TLS-basierte VPNs betreffen.
• Keine zustandsbehaftete Verbindung – das Protokoll läuft über UDP und ist verbindungslos. Es gibt keine TCP-artige Zustandsmaschine, die beim Netzwerkwechsel abbricht. Ein roamendes Gerät, das von WLAN zu Mobilfunk wechselt, muss nichts neu aufbauen; es sendet einfach Pakete von der neuen IP-Adresse, und der Responder akzeptiert sie.
• Sofortiges Roaming – da die Verbindung durch die kryptografischen Schlüssel und nicht durch die Quell-IP-Adresse identifiziert wird, akzeptiert der Responder Pakete von jeder Quell-IP, die die korrekte kryptografische Authentifizierung erzeugt. Deshalb handhabt WireGuard mobile Netzwerkwechsel deutlich besser als OpenVPN oder IPsec, die bei Änderung der zugrunde liegenden IP oft neu verhandeln müssen.
• Winzige Angriffsfläche – die Referenzimplementierung umfasst etwa 4.000 Codezeilen. OpenSSL über 500.000. Dies ist kein fairer Vergleich (sie leisten unterschiedlich viel), aber die Implikation ist real: kleinerer Code ist einfacher zu prüfen, einfacher formal zu analysieren und bietet weniger Möglichkeiten für Implementierungsfehler, die zu Schwachstellen werden.
• Vorhersehbare Leistung – jeder Handshake verwendet dieselben Primitive bei denselben Schlüsselgrößen. Es gibt keine Fast-Path/Slow-Path-Divergenz basierend auf der ausgehandelten Cipher Suite. Der Handshake dauert auf derselben Hardware ungefähr gleich lang, unabhängig davon, mit wem du dich verbindest.

Für den Vergleich mit dem älteren Protokoll, das es für die meisten Nutzer abgelöst hat, lies unseren Artikel über WireGuard vs OpenVPN, der die praktischen Leistungs- und Sicherheitsunterschiede behandelt. Warum die Tunneling-Entscheidungen eines VPNs für das relevant sind, was Apps sehen, erklärt was ist Split Tunneling.

Casper’s Cloak verwendet WireGuard für alle Client-Verbindungen, betreibt die offizielle Kernel-Mode-Implementierung auf Linux-Endpunkten und liefert den Standard-Userspace-Client (basierend auf der wireguard-go-Referenz) auf iOS, Android und macOS aus. Der oben beschriebene Handshake ist genau das, was passiert, wenn du die App einschaltest. Dasselbe Noise_IK-Muster, dasselbe Curve25519/ChaCha20-Poly1305/BLAKE2s/HKDF-Primitivset, dasselbe 2-Minuten-Rekey, derselbe 240-Byte-Handshake. Das Bedrohungsschutz-Feature schichtet DNS-basiertes Filtern oben auf den WireGuard-Tunnel – der Tunnel übernimmt den Transport, der Filter die Zielpolitik.

Für die vollständige Protokollspezifikation ist das originale WireGuard-Whitepaper von Jason Donenfeld die maßgebliche Referenz: wireguard.com/papers/wireguard.pdf. Das Paper behandelt die kryptografische Konstruktion, das Bedrohungsmodell, die formale Analyse und die Implementierungsbegründung. Es ist eines der besser lesbaren Stücke modernen Protokolldesigns – es lohnt sich, es eine Stunde lang zu überfliegen, wenn du die Design-Kompromisse aus erster Hand verstehen möchtest.

Fazit: Der WireGuard-Handshake besteht aus zwei Paketen, dauert in der Praxis unter 100 Millisekunden, authentifiziert beide Peers gegenseitig, leitet forward-secret Sitzungsschlüssel ab und widersteht durch Design jedem gängigen Angriffsmuster (Replay, Downgrade, Identitätsenthullung, DoS). Es ist ein kompaktes, festes, meinungsstarkes Protokoll – und genau diese Meinungsstärke ist der Punkt.