Was in der Praxis einfach klingt, ist in der Realität komplizierter. Das Grundproblem liegt darin, dass der Server dem Client den Schlüssel mitteilen muss – und zwar, bevor die Kommunikation mit TLS gesichert ist. Wer verschlüsselte Mailanhänge versendet, kennt dieses Problem: Man verschlüsselt eine Datei und muss dem Empfänger das geheime Passwort mitteilen, z. B. per Telefon.
Das TLS-Protokoll wendet das folgende Verfahren an, um dieses Problem zu lösen:
- Wenn der Client – beispielsweise ein Webbrowser – den Webserver kontaktiert, sendet dieser ihm zuerst sein Zertifikat zu. Dieses SSL-Zertifikat beweist, dass der Server authentisch ist und nicht etwa eine falsche Identität vortäuscht.
- Der Client prüft das Zertifikat auf Gültigkeit und sendet dem Server eine Zufallszahl, verschlüsselt mit dem öffentlichen Schlüssel (Public Key) des Servers.
- Der Server erzeugt aus dieser Zufallszahl den Sitzungsschlüssel (Session Key), mit dem die Kommunikation verschlüsselt werden soll. Da die Zufallszahl vom Client stammt, kann dieser sicher sein, dass der Sitzungsschlüssel tatsächlich vom adressierten Server stammt.
- Der Server sendet den Sitzungsschlüssel dem Client zu, und zwar in verschlüsselter Form. Diese Verschlüsselung erfolgt mithilfe des Diffie-Hellmann-Schlüsselaustauschs.
- Nun können beide Parteien ihre Daten mit dem Sitzungsschlüssel gesichert versenden.
Der Grund, weshalb die asymmetrische Verschlüsselung nur für das Übertragen des Sitzungsschlüssels (aber nicht für die Verschlüsselung der Datenströme selbst) verwendet wird, ist der Geschwindigkeitsvorteil; die asymmetrische Verschlüsselung ist relativ langsam und würde die Datenkommunikation verzögern.