Das Handshake-Verfahren kommt in den Bereichen Kom­mu­ni­ka­ti­ons- und Netz­werk­si­cher­heit zum Einsatz. Durch die Be­stä­ti­gung und Au­then­ti­fi­zie­rung von Client-Server-Ver­bin­dun­gen be­stä­ti­gen sich Sender und Empfänger ge­gen­sei­tig einen ver­trau­ens­wür­di­gen Ver­bin­dungs­auf­bau. Hierbei kann es sich sowohl um Hardware- und Software-basierte Hand­shakes als auch um Methoden wie den Drei-Wege- oder Vier-Wege-Handshake handeln.

Was ist ein Handshake?

Genau wie der physische Hand­schlag zur Begrüßung soll der digitale Hand­schlag zwischen Client und Server Ver­trau­ens­wür­dig­keit und Si­cher­heit ver­mit­teln. Hand­shakes kommen vor allem im Netz­werk­be­reich, in der Kom­mu­ni­ka­ti­ons­si­cher­heit und in der Si­gna­li­sie­rungs­tech­nik zum Einsatz. Basierend auf einem Client-Server-Modell er­mög­li­chen Handshake-Verfahren die Ab­si­che­rung der ver­lust­frei­en Da­ten­über­tra­gung zwischen Sender und Empfänger. Hierbei quit­tie­ren sich die be­tei­lig­ten Parteien über­tra­ge­ne In­for­ma­tio­nen mit Software-basierten Hand­shakes wie im TCP/IP-Modell oder als Hardware-basierte Hand­shakes mittels einzelner Leitungen oder Si­gnal­pe­gel.

Wie funk­tio­niert das Handshake-Verfahren?

Der Zweck eines Hand­shakes ist die sichere In­for­ma­ti­ons­über­tra­gung ohne Da­ten­ver­lust oder Kom­pro­mit­tie­rung. Hierzu quit­tie­ren sich Empfänger und Sender zunächst gesendete Daten beim erst­ma­li­gen Ver­bin­dungs­auf­bau. Diese Quit­tie­rung si­gna­li­siert zum einen die Be­reit­schaft zur Kom­mu­ni­ka­ti­on und Da­ten­über­tra­gung und zum anderen die Ver­trau­ens­wür­dig­keit der je­wei­li­gen Kom­mu­ni­ka­ti­ons­in­stanz. Je nach Methode kann die Quit­tie­rung in mehreren Phasen, auch „Wegen“, erfolgen. Das beste Beispiel für einen Drei-Wege-Handshake ist das Protokoll TCP. Ein Vier-Wege-Handshake wiederum kommt beim Protokoll SCTP zum Einsatz.

Im Folgenden erklären wir an den Bei­spie­len TCP, SCTP und TLS, wie ein Handshake funk­tio­niert.

Drei-Wege-Handshake bei TCP

  1. Der Sender schickt zur Si­gna­li­sie­rung eines Kom­mu­ni­ka­ti­ons­wun­sches eine SYN-Nachricht mit Sender-In­for­ma­tio­nen wie der in­di­vi­du­el­len Se­quenz­num­mer.
  2. Der Empfänger sendet ebenfalls eine SYN-Nachricht mit in­di­vi­du­el­ler Se­quenz­num­mer und gleich­zei­tig die erhaltene SYN-Nachricht des Senders mit einer SYN-ACK-Nachricht.
  3. Der Sender bestätigt die erhaltene SYN-Nachricht vom Empfänger mit einer eigenen SYN-ACK-Nachricht.

Mit diesem Handshake si­gna­li­sie­ren sich beide Instanzen die Kom­mu­ni­ka­ti­ons­be­reit­schaft und die ver­lust­freie Da­ten­über­tra­gung.

Vier-Wege-Handshake bei SCTP

Beim ver­bin­dungs­ori­en­tier­ten SCTP-Protokoll wird der Austausch von Da­ten­pa­ke­ten mittels Vier-Wege-Handshake initiiert.

  1. Zunächst schickt der Sender eine INIT-ACK-Nachricht.
  2. Der Empfänger bestätigt die Anfrage mit einer INIT-ACK-Nachricht, die zugleich ein ver­bin­dungs­spe­zi­fi­sches Cookie enthält.
  3. Der Sender überträgt eine COOKIE-ECHO-Request mit dem ver­bin­dungs­spe­zi­fi­schen Cookie an den Empfänger.
  4. Schließ­lich bestätigt der Sender den Ver­bin­dungs­auf­bau mit einer COOKIE-ACK-Nachricht.

TLS-Handshake

Um sichere, ver­schlüs­sel­te Ver­bin­dun­gen im Internet her­zu­stel­len, kommt oftmals die Transport Layer Security bzw. Secure Socket Layers zum Einsatz. Be­kann­tes­tes Beispiel hierfür ist die Kom­mu­ni­ka­ti­on zwischen einem Web­brow­ser und einem Webserver über HTTPS. Beim TLS-Handshake tauschen Client und Server meist in vier Phasen spe­zi­fi­sche In­for­ma­tio­nen und Si­cher­heits­pa­ra­me­ter aus, um die Ver­bin­dung zu au­then­ti­fi­zie­ren.

Welche Phasen umfasst ein TLS-Handshake?

TLS, das Nach­fol­ge­pro­to­koll von SSL, kommt im Netz für einen ver­schlüs­sel­ten, ver­trau­ens­wür­di­gen Da­ten­aus­tausch zwischen Client und Server zum Einsatz. Dadurch lassen sich Anmelde- und Kon­to­da­ten von Nut­ze­rin­nen und Nutzern, Zah­lungs­in­for­ma­tio­nen, über­tra­ge­ne Dokumente und Dateien sowie Ein­ga­be­for­mu­la­re ver­schlüs­seln. Besonders für Un­ter­neh­men im E-Commerce ist also nicht nur eine TLS-Ver­schlüs­se­lung, sondern auch ein TLS-Handshake wichtig. Um eine ver­trau­ens­wür­di­ge Ver­bin­dung zwischen Web­brow­ser und Webserver inklusive Si­cher­heits­pa­ra­me­ter aus­zu­han­deln und zu au­then­ti­fi­zie­ren, kommt das TLS-Handshake-Protokoll zum Einsatz.

Das TLS-Handshake-Protokoll erfüllt folgende Funk­tio­nen:

  • Au­then­ti­fi­zie­rung der be­tei­lig­ten Kom­mu­ni­ka­ti­ons­part­ner
  • Aus­hand­lung von zu ver­wen­den­den kryp­to­gra­fi­schen Ver­schlüs­se­lungs­ver­fah­ren
  • Aus­hand­lung der kryp­to­gra­fi­schen Schüssel

Der Ablauf eines TLS-Hand­shakes erfolgt meist in folgenden Phasen:

Phase 1: Client Hello

Zunächst über­mit­telt der Client, z. B. der Web­brow­ser, ein Client Hello mit In­for­ma­tio­nen wie der Sit­zungs­num­mer, Session-ID oder Cipher Suites, der TLS-Version und weiteren Zu­falls­in­for­ma­tio­nen an den Server.

Phase 2: Server Hello

Der Server antwortet mit einem Server Hello, das ebenfalls In­for­ma­tio­nen wie eine Session-ID, Sit­zungs­num­mer, die Cipher Suite enthält.

Phase 3: Server Cer­ti­fi­ca­te

Zur Ge­währ­leis­tung des Schlüs­sel­aus­tau­sches sendet der Server direkt an­schlie­ßend an das Server Hello eine Server-Cer­ti­fi­ca­te-Nachricht. Anhand des Zer­ti­fi­kats sind Clients in der Lage, die Ver­trau­ens­wür­dig­keit eines Servers anhand des echten, gültigen Zer­ti­fi­kats zu über­prü­fen.

Phase 4: Server Key Exchange

Zum Server Key Exchange kommt es nur, wenn die Server-Cer­ti­fi­ca­te-Nachricht nicht alle nötigen In­for­ma­tio­nen für die Be­rech­nung der Schlüssel bzw. des Pre-Master-Secrets enthält.

Phase 5: Cer­ti­fi­ca­te Request

Obwohl nicht in jedem TLS-Handshake er­for­der­lich, kann auch der Server ein ent­spre­chen­des Client Cer­ti­fi­ca­te zur Be­stä­ti­gung anfordern. Die An­for­de­rung erfolgt un­mit­tel­bar an­schlie­ßend an das Server-Key-Exchange-Signal bzw. un­mit­tel­bar nach dem Server Cer­ti­fi­ca­te.

Phase 6: Server Hello Done

Die Server-Hello-Done-Nachricht schließt den Austausch der Server- und Client-Schlüssel sowie die Au­then­ti­fi­zie­rung ab. Falls gefordert erfolgt die Antwort in Form des Client Cer­ti­fi­ca­tes an den Server, nachdem der Client die Gül­tig­keit des Server Zer­ti­fi­kats überprüft hat.

Phase 7: Client Cer­ti­fi­ca­te

Liegt eine ser­ver­sei­ti­ge Auf­for­de­rung vor, sendet der Client ein zur Cipher Suite passendes Client Cer­ti­fi­ca­te. Sendet der Client keine be­stä­ti­gen­de Nachricht, besteht die Mög­lich­keit, dass die Ver­bin­dung auf Seiten des Servers gekappt oder der TLS-Handshake ohne Client-Au­then­ti­fi­zie­rung fort­ge­setzt wird.

Phase 8: Client Key Exchange

Anders als die Server-Key-Exchange-Nachricht ist das Client-Key-Exchange-Signal stets er­for­der­lich. Mit diesem lässt sich das Pre Master Secret de­fi­nie­ren.

Phase 9: Cer­ti­fi­ca­te Verify

Mit dieser op­tio­na­len Be­stä­ti­gung lässt sich das Client Cer­ti­fi­ca­te quit­tie­ren. Der Client bestätigt mit dem Signal die eigene Echtheit und den Besitz der privaten Schlüssel. Hierfür muss das Client Cer­ti­fi­ca­te si­gnier­fä­hig sein.

Phase 10: Change Cipher Spec

In dieser Phase wird über den TLS Record Layer die erste ge­schütz­te Nachricht mit den aus­ge­han­del­ten Al­go­rith­men und kryp­to­gra­fi­schen Schlüs­seln versendet. Die ge­si­cher­te Da­ten­über­tra­gung wird somit bestätigt.

Phase 11: Finished

Der letzte Schritt umfasst eine Nachricht, die den Schlüs­sel­aus­tausch sowie die Au­then­ti­fi­zie­rung quittiert und ab­schließt. Die Kor­rekt­heit des Finished-Signals muss noch auf Seiten des Emp­fän­gers überprüft werden. Diese Über­prü­fung erfolgt mittels Hashing und er­rech­ne­te Hashwerte für alle Nach­rich­ten. Auf diese Weise lassen sich auch Downgrade-Angriffe vorbeugen, die in der Lage sind, Cipher Suites des Client-Hello-Signals zu löschen.

Software-Handshake vs. Hardware-Handshake: Un­ter­schied

Beim Handshake-Verfahren lässt sich zwischen Software- und Hardware-basierten Hand­shakes un­ter­schei­den. Wie oben be­schrie­ben, kommen vor allem Software-Hand­shakes besonders häufig zum Einsatz und in­te­grie­ren die Au­then­ti­fi­zie­rung der Instanzen, die Quit­tie­rung ver­lust­lo­ser Da­ten­über­tra­gun­gen sowie die Aus­hand­lung kryp­to­gra­fi­scher Schlüssel. Dieses Be­stä­ti­gungs­ver­fah­ren ist direkt in die Kom­mu­ni­ka­ti­on und die Da­ten­strö­me in­te­griert.

Hardware-basierte Hand­shakes kommen im Rahmen serieller Schnitt­stel­len und der Da­ten­fluss­steue­rung zum Einsatz. Hierbei wird der Da­ten­strom so gelenkt, dass ver­lust­lo­se In­for­ma­ti­ons­über­tra­gun­gen bzw. Da­ten­über­tra­gun­gen ohne große Ver­zö­ge­run­gen zwischen End­ge­rä­ten erfolgen. Dazu erfolgt u. a. eine Si­gnal­pe­gel­steue­rung, um Delays in Form von Jitter vor­zu­beu­gen. Auch Handshake-Signale wie Ready to Send (RTS) und Clear to Send (CTS) er­mög­li­chen über serielle Schnitt­stel­len die Be­stä­ti­gung einer ver­lust­frei­en Kom­mu­ni­ka­ti­on.

Die Da­ten­fluss­steue­rung auf Hardware-Ebene findet im OSI-Modell auf der Schicht der Bit­über­tra­gung statt. Besonders für die Da­ten­über­tra­gung zwischen End­ge­rä­ten und Pe­ri­phe­rie­ge­rä­ten wie Modems, Druckern oder Terminals er­mög­li­chen Hand­shakes zu­ver­läs­si­ge Ar­beits­ab­läu­fe.

Wo kommt ein Handshake zur Anwendung?

Zu den wich­tigs­ten An­wen­dungs­ge­bie­ten von Handshake-Verfahren zählen die Si­gna­li­sie­rungs- und Netz­werk­tech­nik sowie die Au­then­ti­fi­zie­rung von Instanzen in Client-Server-Modellen. Besonders häufig kommen bei TCP- und STCP-Ver­bin­dun­gen Software-basierte Drei-Wege-Hand­shakes und Vier-Wege-Hand­shakes zum Einsatz, um einen sicheren TCP/IP-Ver­bin­dungs­auf­bau und eine konstante Da­ten­über­tra­gung zu be­stä­ti­gen. Darüber hinaus werden Handshake-Verfahren für asyn­chro­ne Bus­sys­te­me, kryp­to­gra­fi­sche Ver­schlüs­se­lungs­ver­fah­ren/-pro­to­kol­le wie TLS oder für serielle Schnitt­stel­len zwischen End­ge­rä­ten und Pe­ri­phe­rie­ge­rä­ten verwendet.

Zum Hauptmenü