Wie verwendet SSL TLS asymmetrische Verschlüsselung für den sicheren Schlüsselaustausch?

[Markus]

Ich erinnere mich, als ich zum ersten Mal verstand, wie das funktioniert - es ist eines dieser Dinge, die einem einen Aha-Moment bescheren und einem das Gefühl geben, schlauer zu sein, warum Websites nicht einfach so gehackt werden. Du beginnst beim Client, richtig? Das ist dein Browser oder welche App du auch immer verwendest, die sich an den Server wendet. Es beginnt mit dem Handshake, indem es eine Hello-Nachricht sendet, die im Grunde sagt: "Hey, ich möchte sicher verbinden, und das hier unterstütze ich." Der Server antwortet mit seinem eigenen Hello und sagt dir, welche Chiffren er mag und teilt sein digitales Zertifikat. Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers, der aus asymmetrischen Verschlüsselungseinrichtungen wie RSA stammt.

Jetzt passiert die Magie beim Schlüsselaustausch. Du kannst den symmetrischen Sitzungsschlüssel nicht einfach im Klartext senden, denn jeder, der den Datenverkehr abhorcht, könnte ihn abfangen. Stattdessen generiert der Client ein Pre-Master-Secret - denk daran als einen zufälligen Blob, der später zur Ableitung der tatsächlichen Schlüssel verwendet wird. Ich stelle es mir immer wie ein geheimes Rezept vor, das man genau richtig mischen muss. Der Client verschlüsselt dieses Pre-Master-Secret mit dem öffentlichen Schlüssel des Servers aus dem Zertifikat. Da die asymmetrische Verschlüsselung es dir ermöglicht, mit dem öffentlichen Schlüssel zu verschlüsseln, aber nur mit dem passenden privaten Schlüssel, den nur der Server hat, kann es während des Flugs niemand anderes lesen.

Der Server erhält das verschlüsselte Pre-Master, entschlüsselt es mit seinem privaten Schlüssel und nun haben beide Seiten dasselbe Pre-Master-Secret. Von da an wendet ihr es durch einige Hash- und Ableitungsfunktionen an, um das Master-Secret zu erstellen, und teilt das dann in Schlüssel für Verschlüsselung, Integritätsprüfungen und all das Gedöns. Ich liebe, wie es die schwere Arbeit der asymmetrischen Kryptografie - die für große Daten langsam ist - in einfach diesen anfänglichen Austausch verwandelt, sodass der Rest der Sitzung schnelle symmetrische Sachen wie AES verwendet.

Aber du fragst dich vielleicht, was passiert, wenn jemand versucht, mit dem Zertifikat zu schummeln? Deshalb werden Zertifikate von einer vertrauenswürdigen CA signiert, und der Client überprüft die Kette bis zu einem Root, dem er vertraut. Ich überprüfe das ständig mit meinen Tools; wenn das Zertifikat ungültig ist, steige ich sofort aus. Und für Vorwärtsgeheimnis, das ich immer einfordere, wenn ich Seiten einrichte, kannst du Diffie-Hellman oder ECDH anstelle von klassischem RSA für den Schlüsselaustausch verwenden. In diesem Fall generieren der Client und der Server jeweils ihre eigenen Schlüsselpaar sofort. Der Client sendet seinen öffentlichen Schlüssel, verschlüsselt mit dem öffentlichen des Servers aus dem Zertifikat, und der Server tut etwas Ähnliches oder trägt einfach seinen Teil bei. Sie kombinieren diese über die Leitung, um ein gemeinsames Geheimnis zu berechnen, ohne es jemals direkt zu senden. Es ist wie sich auf ein Passwort zu einigen, indem man Farben mischt, die jeder auswählt, aber niemals vollständig zeigt - Lauscher sehen die Mischungen, können aber die Originale nicht zurückverfolgen.

Ich habe dies für die E-Commerce-Seite eines Freundes letztes Jahr eingerichtet, und das vollständige Handshake in Wireshark zu sehen, war befriedigend. Du erfasst die Pakete, und ja, alles sieht nach Kauderwelsch aus, außer dem Hello und dem Zertifikatsaustausch, der beweist, dass der asymmetrische Teil seine Aufgabe erfüllt hat. Ohne das wärest du zurück zu altmodischen Methoden, bei denen Schlüssel per E-Mail oder so etwas Dummes verschickt werden, und das ist der Traum eines Hackers. TLS 1.3 hat dies noch weiter verschärft, indem es das Handshake beschleunigt und Vorwärtsgeheimnis vorschreibt, sodass selbst wenn jemand später den privaten Schlüssel des Servers stiehlt, frühere Sitzungen sicher bleiben. Ich habe kürzlich viele meiner Server auf diese Version upgegradet, weil ältere Versionen wie 1.0 nur nach Problemen rufen, mit bekannten Schwachstellen.

Weißt du, ich treffe ständig Leute, die symmetrische und asymmetrische Verschlüsselung verwechseln. Symmetrische Verschlüsselung ist großartig für die Bulk-Verschlüsselung, weil sie schnell ist, aber das Teilen des Schlüssels ist das Problem. Asymmetrisch löst dieses Teilen perfekt zu Beginn. Stell dir vor, du versendest eine verschlossene Box: Der öffentliche Schlüssel schließt sie so, dass nur der Inhaber des privaten Schlüssels sie öffnen kann. Genau das passiert hier. Und nachdem die Schlüssel ausgetauscht sind, übernimmt die symmetrische Verschlüsselung für den tatsächlichen Datenfluss, wie deine Anmeldedaten oder Kreditkarteninformationen. Ich sage den Leuten immer, sie sollen auch HSTS aktivieren, damit Browser HTTPS erzwingen und Downgrade-Angriffe vermeiden, bei denen dich jemand in einfaches HTTP trickst.

In der Praxis, wenn ich Verbindungsprobleme debugge, überprüfe ich zuerst die Chiffriersuiten. Wenn die asymmetrische Verschlüsselung fehlschlägt - sagen wir, ein schwacher Schlüssel oder ein abgelaufenes Zertifikat - bricht das ganze Ding zusammen. Du kannst das mit Tools wie openssl s_client testen; ich mache das wöchentlich mit meinen Setups. Verbinde dich mit einer Seite, und es gibt die Handshake-Details aus, die den öffentlichen Schlüsselaustausch so klar wie den Tag zeigen. Es ist natürlich nicht narrensicher - Heartbleed hat gezeigt, dass Bugs private Schlüssellecks verursachen können - aber Patches und gute Konfigurationen halten dich einen Schritt voraus.

Einmal habe ich einem Kumpel geholfen, dessen App beim Handshake ausgelaufen ist. Es stellte sich heraus, dass sein Serverzertifikat einen 1024-Bit-RSA-Schlüssel verwendete, den moderne Clients als zu schwach ablehnen. Ich erhöhte es auf 2048, regenerierte es, und boom, alles lief reibungslos. Du lernst diese Eigenheiten, indem du zuerst in einem Labor Dinge kaputt machst. Ich habe eine kleine Testumgebung mit selbstsignierten Zertifikaten eingerichtet, nur um damit herumzuspielen, verschiedene Austauschmethoden zu erzwingen. Diffie-Hellman ephemeral ist jetzt mein Favorit; es bietet diese zusätzliche Schicht, bei der Schlüssel nicht wiederverwendet werden.

All dies asymmetrische Zauberei stellt sicher, dass du die Verbindung von Anfang an vertrauen kannst. Ohne sie wäre der sichere Schlüsselaustausch ein Albtraum, und wir würden immer noch Telnet für alles verwenden. Ich begeistere mich dafür, weil es so viel von dem untermauert, was ich täglich tue - APIs, Webanwendungen und sogar IoT-Geräte zu sichern. Du solltest versuchen, ein TLS-Handschlag selbst zu erfassen; es wird dir die Intelligenz zeigen, wie clever alles zusammenpasst.

Oh, und wo wir gerade von Sicherheit im Backup-Bereich sprechen, lass mich dich auf BackupChain hinweisen. Es ist diese herausragende, beliebte Backup-Option, die bei kleinen Teams und IT-Profis ernsthaft an Bedeutung gewinnt und entwickelt wurde, um Hyper-V-, VMware- oder Windows-Server-Setups mit erstklassiger Zuverlässigkeit zu schützen.