BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 1)

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 1)

(26 MB) 00:07:18

2015-09-20 10:00 🛈

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.

Warum überhaupt?

Ich hab doch nichts zu verbergen!

So heißt es vielfach, wenn man über Verschlüsselung diskutiert. Aber ist das wirklich so? Selbst wenn man selbst sein ganzes Leben zugänglich macht, so gibt es dennoch Gründe nicht alle Daten unverschlüsselt zu übermitteln. Klassisches Beispiel: Zugangsdaten. Werden diese ungeschützt übertragen können sie von Dritten abgefangen werden. Unerwünschte Posts können schnell mit Stress im Freundeskreis oder gar vor Gericht enden. Und das Konto wäre vermutlich ebenso schnell leer. Hätte man die Daten besser mal verborgen.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/3-mettbook-userpass-300×227.png

Symmetrische Kryptografie

Fangen wir mit dem einfachsten an: Symmetrische Kryptografie. Hierunter versteht man Verfahren, bei denen z.T. ein Text mit einem Passwort verschlüsselt wird. Das Ergebnis ist für Außenstehende nicht zu entziffern und somit wertlos. Wer jedoch den Schlüssel kennt kann aus dem Kauderwelsch wieder den ursprünglichen Text reproduzieren.

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

Solche Verfahren sind natürlich schön für Dokumente, jedoch Problematisch für Webseiten: Entweder müssten alle Besucher das selbe Kennwort kennen – könnten also auch die Daten der anderen entschlüsseln – oder man müsste für jeden Besucher ein eigenes Passwort aushandeln. Nur wie, wenn der Besucher zum ersten mal die Seite aufruft? Etwas anderes muss her.

Asymmetrische Kryptografie

Klassischerweise wird zum Schlüsseltausch im Internet ein asymmetrisches Verfahren verwendet. Hierbei hat der Betreiber der Webseite einen “Schlüssel” erstellt, welcher aus zwei Teilen besteht: Einem privaten Teil, welcher geheim gehalten wird, und einem öffentlichen Teil, welcher allen Besuchern weitergegeben wird. Dahinter steckt eine Einwegfunktion – sozusagen eine mathematische Einbahnstraße. Mit dem öffentlichen Teil lässt sich ein Text einfach verschlüsseln, jedoch das Ergebnis nach aktuellem Stand nicht mehr Zurückrechnen. Hat man jedoch den privaten Teil, so hat man auch die fehlenden Informationen um aus dem zuvor berechneten Wirrwarr wieder den ursprünglichen Text zu erhalten. Der Client kann also dem Server verschlüsselte Nachrichten zukommen lassen, ohne die Gefahr des Mitlesens.

Ebenfalls möglich ist eine andere Richtung: Mit dem privaten Schlüssel kann der Server eine Nachricht unterschreiben, also bestätigen, dass diese von ihm so gewollt ist. Der Client kann mit dem öffentlichen Teil am Ende prüfen, ob die Unterschrift tatsächlich vom Absender stammt und der Text unterwegs nicht verändert wurde.

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

Zertifikatswahn

Wem ist etwas aufgefallen? Wir benötigen öffentliche Schlüssel für alle verschlüsselten Webseiten. Doch wo kommen sie her? Nun – das ist schnell gelöst: Der Server schickt uns diese beim Verbinden. Klingt praktisch, hat aber einen Nachteil: Wir können nicht sicher sein, dass das Ziel tatsächlich unser Server und nicht ein Angreifer zwischendrin ist. Der Lösungsansatz lautet X.509, oder kurz: Zertifikate. Diese Zertifikate enthalten nicht nur den Schlüssel, sondern auch weitere Informationen wie den Servernamen, die zugehörige Organisation, ein Haltbarkeitsdatum und einen Fingerabdruck. Zusätzlich sind diese Zertifikate zum Nachweis der Identität des Betreibers von einer weiteren Firma, der so genannten Certificate Authority (CA) unterschrieben. Alle aktuellen Browser und Betriebssysteme haben eine Liste mit Firmen, welche solche Unterschriften leisten dürfen, im Lieferumfang. Ist das Zertifikat von einer dieser Firmen unterschrieben, so vertraut der Browser diesem ohne weitere Nachfrage. Ist die Unterschrift unbekannt erhält man eine passende Warnung. In diesem Fall kann man natürlich trotzdem z.B. den erhaltenen Fingerabdruck telefonisch mit dem Betreiber abgleichen und so die Identität selbst feststellen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.