HTTPS, SSL, TLS

Kurz zusammengefasst - im Internet waren und sind alle Daten in Klarschrift für jeden einsehbar = Prinzip der Postkarte.

• Bereits sehr früh erkannte man, dass mit der weltweiten Nutzung des WWW es einer anderen Art der Sicherheit bedurfte, damit das de facto völlig unsichere Datennetz überhaupt eine kommerzielle Zukunft hatte.
• 1994 führte Netscape für seinen damaligen Browser erstmals das SSL Protokoll V1 ein. SSL steht für secure socket layer = eine weitere separate Schicht. Diese wurde später von TLS (Transport Layer Security) abgelöst.
• Es finden sich zwei Aussagen, welche beide korrekt sind:
  • Zum Schutz legte man eine weitere Schicht unter HTTP (oft als VPN - Virtual Private Network bezeichnet). Das extra für das WWW eingeführte HTTP ist jedoch bereits die oberste Schicht, unter der viele andere viel wichtigere Internet-Schichten liegen.
  • Dieser Layer (Schutzschicht) liegt somit oben auf allen anderen bereits bestehenden Internet-Protokollen - als Schutzdeckel oben drauf.
• In der Folge sprach man auch oft von HTTP über SSL sowie später HTTP über TLS.
• Die drei Ziele waren und sind bis heute interessant. Man wollte Folgendes gewährleisten:
  1. Identität: der Server (Anbieter-Internet-Auftritt) ist wirklich derjenige ist, der er zu sein vorgibt.
  2. Integrität: die Nachrichten dürfen auf dem Übertragungsweg nicht verfälscht werden.
  3. Verschlüsselung: die Nachrichten dürfen auf dem Übertragungsweg nicht abgehört und entziffert werden.
• HTTPS (= Hyper Text Transport Protocol Secure) stellt somit eine Transportverschlüsselung mit Authentifizierung dar. Dazu wurde eine weitere Schicht (layer) direkt unterhalb von HTTP definiert, also unterhalb der eigentlichen Seiteninhalte (Texte, Bilder etc.).
  • Authentifizierung bedeutet, dass sich die beiden Partner (Sender und Empfänger) beim Verbindungsaufbau gegenseitig identifizieren können (aber nicht müssen).
  • Verschlüsselung bedeutet, dass die Daten nicht mehr in Klarschrift für jeden sofort lesbar sind (= Prinzip des verschlossenen Briefumschlages).

Verschlüsselung

• Bei einer Verschlüsselung handelt es sich heute um einen mathematischen Vorgang zur Kodierung und Dekodierung von Informationen.
• Allgemein finden sich zur Verschlüsselung:
  1. symmetrische Schlüssel, bei denen beide Partner denselben Schlüssel verwenden zum Ver- und Entschlüsseln (schnell und einfach zu handhabende Bedienung, aber komplizierte Schlüsselübergabe) und
  2. asymmetrische Schlüssel, bei denen der Versender einen geheimen privaten Schlüssel zum Verschlüsseln verwendet, und der Empfänger einen davon abgeleiteten und überall einsehbaren öffentlichen Schlüssel zum Entschlüsseln verwendet (komplexe und langsame Anwendung, aber einfache Schlüsselübergabe).
• Bei HTTPS werden aus Lastgründen beide Verfahren kombiniert. - Zwei Verfahren sind allerdings immer unsicherer als eines.
• Jedes SSL-Zertifikat beinhaltet ein Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel:
  • Der private Schlüssel mit dem Code und der öffentliche Schlüssel für die Dekodierung.
  • Der private Schlüssel ist auf dem Server des Anbieters (= Internet-Auftritt) installiert und darf nicht weitergegeben werden.
  • Der öffentliche Schlüssel ist hingegen in das SSL-Zertifikat integriert und wird an alle anfragenden Browser gesendet.
  • Ferner liegt der öffentliche Schlüssel auch bei einer sogenannten Zertifizierungsstelle. Dort werden auch alle Daten zum ausgestellten HTTPS-Zertifikat aufbewahrt und für die Öffentlichkeit vorrätig gehalten.
• Die Verschlüsselung kann über zwei Wege / Verfahren durchgeführt werden:
  • die asymmetrische Verschlüsselung oder das Diffie-Hellman-Schlüsselaustausch-Verfahren.
  • Zwei Verfahren kann man immer gegeneinander ausspielen. Bereits die Unfähigkeit resp. der mangelnde Wille, sich auf eine Varianten zu einigen, zeigt die massiven Probleme jenes angeblichen Sicherheitsstandards.
• Beide Verfahren tauschen einen gemeinsamen symmetrischen Sitzungs-Schlüssel zwischen Empfänger und Sender aus. Dieser wird vom Browser des Endnutzers erzeugt und ist nur für diese eine Sitzung gültig.
• Von den zahlreichen Schlüssel-Austauschverfahren gelten derzeit nur noch zwei als relativ sicher (Elliptic-curve Diffie–Hellman und Diffie–Hellman key exchange - DH).
• Mit diesem symmetrischen Schlüssel werden die Inhalte selbst (Seitentexte, Fotos etc.) verschlüsselt.
• Die Schlüssellänge ist jedoch für die Sicherheit entscheidend:
  • SHA-1 verlangt nur 128 Bit-Verschlüsselung. Diese wird zusätzlich noch durch ressourcensparende Mechanismen (z.B. Stromverschlüsselung) weiter aufgeweicht und unsicherer gemacht.
  • Ferner wird der Empfänger / Nutzer meist nicht mit Zertifikat geprüft.
  • Aktuell sind Schlüssellängen von 2048 Bit im Angebot, wobei die meisten eher nur 1024 Bit als Standard verwenden, da dies Rechenzeit spart.
  • Warum verwendet jedoch PGP (Pretty Good Privacy für E-Mails) seit 2007 bereits eine wesentlich aufwändigere Verschlüsselung, die man 2012 nochmals drastisch verschärfte? Und selbst an der Technologie von PGP gibt es ernstzunehmende Kritik in Sicherheitsfragen.
  • Schwache Schlüssel mit kurzer Schlüssellänge haben schwache Zertifikate zur Folge. So dürfen SSL-verschlüsselte Internet-Auftritte mit schwachen Zertifikaten eine abhörbare Datenübertragung aufbauen, obwohl Ihr Browser in grüner Farbe eine vermeintlich nicht abhörbare HTTPS-Verbindung anzeigt.
  • Um abwärtskompatibel zu sein (d.h. nicht fast alle Nutzer auszusperren), müssen die Server sogar zahlreiche Schlüssel-Verfahren resp. Sicherheitsstufen anbieten. So bieten mein Zertifikat hier und mein Server 22 Verfahren an, die selbstredend nicht alle gleichwertig sicher sind. Ähnlich sieht es bei TLS aus: So unterstützt fast jeder Server heute TLS 1.0, 1.1 und 1.2. Das letzte ist von den dreien am sichersten. Aber man benötigt die anderen für ältere Browser - vor allem alle mobilen Android-Systeme bis einschließlich 4 oder Internet-Explorer bis V 10.

Zertifizierung

• Eine vertrauenswürdige Zertifizierungsinstanz = Certificate Authority = CA bestätigt den öffentlichen Schlüssel, der vom Anbieter aus seinem privaten Schlüssel hergestellt wurde.
• Hierzu kombiniert die CA den öffentlichen Schlüssel des antragstellenden Servers mit weiteren den Server identifizierenden Angaben und erzeugt daraus eine digitale Signatur.
• Diese Signatur wird von der CA an den antragstellenden Server geschickt. Das ist das digitale Zertifikat. Im Prinzip handelt es sich beim Zertifikat nur um eine relativ kleine Datei mit für den Laien unverständlichen Zeichen.
• Der Antragsteller (= Internet-Auftritt) schickt dann diese CA-Signatur mit seinem öffentlichen Schlüssel beim Aufbau einer gesicherten Verbindung an den Nutzer (Client, Browser).
• Ein digitales Zertifikat soll dadurch einen öffentlichen Schlüssel eindeutig einem Server (= Anbieter) zuordnen. Dafür betreibt die Zertifizierungsstelle auch Datenbanken mit Nummern und Laufzeit etc. der vergebenen Schlüssel.
• Zertifizierungsstellen können allerdings nicht nur Zertifikate für Internet-Auftritte (Server) und Nutzer ausstellen, sondern auch andere Zertifizierungsstellen autorisieren. Dadurch entsteht eine Kette von Zertifizierungsstellen = Zertifizierungskette = Certificate Chain.
• Vertraut ein Client (Browser, Nutzer) der obersten Zertifizierungsstelle, vertraut er auch allen Zertifikaten, die von den einzelnen Zertifizierungsstellen der Kette ausgestellt worden sind.
• Die oberste Zertifizierungsstelle einer Kette wird auch Wurzelzertifizierungsstelle = Root CA genannt.
• Root-Zertifikate vieler Anbieter sind bereits in Betriebssystemen und den Browsern integriert.
• Es wäre jedoch unmöglich, alle anderen (untergeordneten) Zertifizierungsstellen oder sogar deren Zertifikate beim Nutzer zu speichern. Deshalb werden von den Zertifizierungsstellen sogenannte OCSP-Responder betrieben. Dort kann der Browser des Nutzers nachfragen, ob das Zertifikat des Servers (Internet-Auftrittes) korrekt ist.

Wenn man kurz innehält und diese Punkte durchdenkt, dann fällt sicher auf, wo man überall betrügerisch ansetzen kann.