Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

HTTPS dürften die meisten kennen, TLS (früher SSL genannt) vielleicht auch, wie sieht es mit RSA, DHE oder ECDHE aus? Alle Begriffe sind Techniken um Zugriffe auf Webseiten zu gegen unberechtigtes Mitlesen abzusichern.

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Die Grundlagen wurden bereits in Teil 1 gezeigt, nun schauen wir mal auf die Zahnräder.

RSA

Schauen wir uns den Verbindungsaufbau am Beispiel von RSA nochmal genauer an. Entwickelt wurde dieses Verfahren 1977 von Ron Rivest, Adi Shamir und Leonard Adleman am MIT. An der Stelle einen großen Dank an Vincent Bernat, welcher hier eine sehr anschauliche Erklärung (en) geliefert hat.

1. Der Client baut eine Verbindung auf und sendet die höchste unterstützte TLS-Version, eine Zufallszahl, eine Sitzungsnummer, eine Liste der unterstützten Crypto-Algorithmen und ggf. der Name des Zielservers (Stichwort VHosts, SNI).
2. Der Server antwortet ähnlich – auch er sendet die höchste von ihm unterstützte TLS-Version, eine Zufallszahl, die Sitzungsnummer und eine Liste der von ihm unterstützten Crypto-Algorithmen.
3. Als Nächstes sendet der Server sein Zertifikat, welches den öffenlichen Schlüssel enthält. Etwas mehr zu dem Thema ist im Post „“Vernünftiges” TLS (SSL/HTTPS/…) mit Apache“ zu finden.
4. Nun folgt die Info, dass der Server mit seinem Hello fertig ist. Dies ist nötig, da nach dem Zertifikat noch weitere Informationen folgen können, welche eine Erweiterung des TLS-Protokolls ermöglichen.
5. Der Client erzeugt eine weitere Zufallszahl, das pre-master-secret, und verschlüsselt diese mit dem öffentlichen Schlüssel des Servers. Die erste Nachricht, die theoretisch nicht von dritten mitgelesen werden kann.
6. Nun werden beide Seiten aktiv und berechnen aus dem pre-master-secret sowie den beiden Zufallszahlen aus den Hello-Nachrichten das master_secret, also das „Passwort“, welches für die Verschlüsselung der Verbindung letztendlich verwendet wird
7. Zuletzt senden beide Seiten eine Nachricht mit dem neuen Schlüssel und prüfen, ob die Nachricht der Gegenseite fehlerfrei entschlüsselt werden kann. Ist dies der Fall wird auf den ausgehandelten Algorithmus (z.B. AES) gewechselt, welcher deutlich weniger Ressourcen benötigt.

Der Mann in der Mitte

Was erst mal gut klingt hat einen Nachteil: Der eigentliche Schlüssel bleibt gleich. Die Kommunikation ist nur so lange sicher, wie der private Schlüssel des Servers nicht bekannt wird. Liest ein Angreifer die verschlüsselten Daten mit, so kann er mit diesen erst einmal nicht viel anfangen. Bekommt er in der Zukunft jedoch Zugang zum Server bzw. dessen Key – z.B. weil dieser Entsorgt wird und der Angreifer sich die Festplatte schnappt – so kann er mit dem privaten Schlüssel das pre_master_secret wiederherstellen. Hiermit hat er nun alle Daten um den zur Kommunikation gehörenden master_key zu berechnen und so alle verschlüsselten Nachrichten entschlüsseln und die Kommunikation im Nachhinein nachvollziehen zu können.

Perfekte Sicherheit? DHE!

Der Konter der Kryptologen lautet „Perfect Forward Secrecy„. Hierbei wird der private Schlüssel nur noch verwendet um sich zu authentifizieren, also nachzuweisen, dass man mit dem richtigen Server kommuniziert. Der Schlüsseltausch wird auf andere Weise erledigt, klassischerweise mit der „Diffie-Hellman-Methode“ unter Verwendung diskreter Logarithmen – in diesem Fall auch Diffie-Hellman ephemeral (DHE) genannt.

Vorsicht, es folgt Formelwirrwarr – wer es einfacher haben möchte überspringt besser den nächsten Absatz.

Zur Durchführung besitzt der Server neben dem bisherigen Schlüsseln einen weiteren Parametersatz: Die DH-Parameter, welche nicht geheim gehalten werden. Diese bestehen aus einer großen Primzahl (p) sowie einer passenden Primitivwurzel (g). Der Server sucht sich nun eine geheime Zahl (a) und berechnet g^a mod p (Ergebnis A). Zwischen Schritt 3 und 4 sendet der Server nun eine weitere Nachricht welche die Zufallszahlen der Hello-Nachrichten, die DH-Parameter und das Ergebnis der letzten Rechnung enthält. Die Nachricht ist mit dem privaten Schlüssel signiert, sodass der Client nachprüfen kann, dass die Nachricht tatsächlich vom gewünschten Server stammt und nicht manipuliert wurde. Der Client selbst erzeugt ebenfalls eine Zufallszahl (b) und führt die selbe Rechnung aus, welches B ergibt. Das Ergebnis wird in Nachricht 5 an den Server gesendet. Zusätzlich berechnet der Client A^b mod p = g^ab mod p, welches das pre-master-secret darstellt. Der Server selbst rechnet B^a mod p, welches ebenfalls g^ab mod p – also dem pre-master-secret – ergibt. Wer mitliest kennt nun war p, g, g^a mod p und g^b> mod p – hieraus das pre-master-secret g^ab mod p zu berechnen ist wegen des „deskreten Logarithmusproblems“ auf absehbare Zeit hoffentlich nicht möglich.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe05-300×169.png

Farbpanschen

Zu schwer? Wikipedia hat eine schöne Analogie im Angebot:

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/Diffie-Hellman_Key_Exchange_de.svg-200×300.png Original schema: A.J. Han Vinck, University of Duisburg-Essen
SVG version: Flugaal
German translation: Chillvie
https://de.wikipedia.org/wiki/Datei:Diffie-Hellman_Key_Exchange_%28de%29.svg

Beide Parteien – der Client (Alice) sowie der Server (Bob) starten mit einer gemeinsamen Farbe. Beide denken sich nun zusätzlich eine geheime Farbe aus. Beide Farben werden nun gemischt und an die jeweilige Gegenstelle gesendet. Diese mischt nun erneut die eigene, geheime Farbe hinzu. Es entsteht auf beiden Seiten wieder eine identische Farbe, welche nie übertragen wurde. Die Sicherheit basiert auf der Annahme, dass das mischen der Farben sehr einfach ist, aus dem gemischten aber wieder die beiden Ursprungsfarben zu erhalten sehr aufwändig ist.

Wo ist der Vorteil gegenüber der vorherigen Lösung? Nunja, das Ergebnis basiert ausschließlich auf den generierten Zufallszahlen, nicht dem privaten Schlüssel des Servers. Da diese Zufallszahlen nicht gespeichert werden ist es nach Abschluss der Verbindung nicht mehr möglich das Verschlüsselungspasswort (master_secret) erneut zu berechnen. Die mitgeschnittenen, verschlüsselten Nachrichten sind also nicht wiederherstellbar und somit wertlos. Ganz umsonst kommt dieser Vorteil jedoch nicht: Die nötigen Rechnungen sind sehr aufwändig – Vincent hat hier beobachtet, dass die Last des Clients um das 20-fache, das des Servers um das 3-fache steigt – für große Serverfarmen ein nicht zu vernachlässigender Kostenfaktor.

…die Sache mit dem „weak DH key“

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe-weak2-300×169.png

Der ein oder andere wird sie schon gesehen haben: Seit einiger Zeit werfen viele Browser beim Besuch einiger Webseiten seltsame SSL-Fehlermeldungen. „ssl_error_weak_server_ephemeral_dh_key“ heißt es so im Firefox, „Server hat eine schwache kurzlebige Diffie-Hellman öffentlichen Schlüssel“ bzw. „Server has a weak ephemeral Dillie-Heffman public key“ oder ERR_SSL_WEAK_EPHEMERAL_DH_KEY in Chrome und auch Safari hat wohl ähnliche Meldungen. Der Hintergrund: Die oben genannten Parameter bestimmen die Sicherheit – weniger als 1024 Bit sollten die DH-Parameter nicht haben, da hier ein Knacken durchaus möglich ist. Empfohlen wird eine Mindestlänge von 2048 Bit. Durch ein historisches Überbleibsel aus einer Zeit, in der starke Verschlüsselung nicht aus den USA in das Ausland gesendet werden durfte, war es möglich solche Verbindungen zwangsweise auf unter 512 Bit herunterzustufen. Die auch als Logjam bekannte Lücke stellte so eine große Gefahr für verschlüsselte Kommunikation dar. Als Gegenmaßnahme begannen Browser Verbindungen mit weniger als 1024 Bit abzulehnen und die oben genannten Fehler zu zeigen.

Was kann man tun? Nun die sinnvollste Methode wäre den Betreiber zu informieren, dass er unsichere Verschlüsselungsparameter nutzt und bitte seinen Dienst auf ein aktuelles Level umstellen sollte. Ist dies nicht erfolgreich verschafft der Verzicht auf HTTPS meist Abhilfe – wirklich sicher wäre die Verschlüsselung ohnehin nicht. Wer nicht um TLS herum kommt kann auch die DH-basierten Verschlüsselungen im Browser abschalten und ihn so zu älteren Algorithmen zwingen. Im Firefox gelingt dies in about:config – dort nach DHE suchen und die mit dhe_rsa_… beginnenden Zeilen per Doppelklick auf abgeschaltet (false) ändern.

…und das mit den Kurven?

In letzter Zeit hat sich ein weiteres Verfahren zum Schlüsseltausch breit gemacht: Elliptische Kurven. Deutlich komplexer als DHE, aber nach aktuellem glauben auch weniger anfällig. Die Masse der öffentlichen Parameter ist deutlich größer: Statt Primzahl und Primitivwurzel wird nun eine Kurve (y²=x³+ax+b), eine Primzahl (p) und ein Startpunkt (G) benötigt. Da das Erstellen der Kurven extrem aufwändig ist werden diese üblicherweise nicht selbst berechnet, sondern man greift auf eine öffentliche, vorberechnete Kurve wie z.B. P-256, P-384 oder P-521 des amerikanischen National Institute of Standards and Technology (NIST) zurück. Der Schlüsseltausch ist ähnlich zu DHE:

• Der Server denkt sich eine Zufallszahl (a) aus und berechnet aG, welches in der signiert an den Client gesendet wird.
• Der Client prüft die Signatur, generiert ebenfalls eine Zufallszahl (b) und sendet bG
• Beide Seiten berechnen per b·aG bzw. a·bG abG, welches als pre-master-secret genutzt wird

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/ecdhe11-300×169.png

Wichtig hierbei: Die gezeigten Additionen/Multiplikationen finden auf der Kurve statt und sind nicht mit den Schulrechnungen zu vergleichen. Eine weitere, gute Erklärung in Videoform liefert CSBreakdown. Zur Addition werden die Summanden auf der Kurve markiert, hiervon leitet man eine Linie ab, welche neben den Ursprüngen einen dritten Schnittpunkt ergibt. Dieser wird über die Y-Ache verlängert, der Schnittpunkt am anderen Ende der Kurve stellt das Ergebnis dar.

Rechnen in der Kurve

Zur Addition wird erst eine Punktverdopplung vorgenommen. Hierbei wendet man o.G. Methode an, statt der Summanden ist jedoch der Winkel der Kurve am Punkt (A) der Ursprung. Im Anschluss kann das Ergebnis 2A wieder mit A addiert werden um auf 3A zu kommen, etc.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/curve06-300×169.png

Da – wie schon Erwähnt – viele der hier verwendeten Daten vorberechnet sind ist der Vorgang weniger rechenintensiv, stellt aber trotzdem die zuvor beschriebene „forward secrecy“ bereit. Im Gegensatz zur „normalen“ Verschlüsselung ist hier bei effizienter Nutzung nur die doppelte Zeit am Client und etwa 15% Mehrleistung am Server zu erwarten.

Alle aktuell im Desktop- und Mobil-Bereich genutzten Browser und Systeme unterstützen diese Methode, wer jedoch exotische Geräte oder veraltete Software (Anderoid <4, Windows XP, etc) nutzt muss auf diesen Weg verzichten.