HTTPS / HTTP Secure

HTTPS bzw. HTTP Secure ist die Anwendung von HTTP in Verbindung mit Verschlüsselung und Authentifizierung. Wobei in der Regel nur der angefragte Webserver sich mit einem Zertifikat authentisieren muss.

Eine verschlüsselte Verbindung mit einem Browser signalisiert man mit einem "https://" (TCP-Port 443) statt "http://" (TCP-Port 80). Dabei muss sich der Webserver dem Client gegenüber authentisieren, ob er tatsächlich der Webserver ist, der sich unter der eingegebenen Adresse befindet. Zusätzlich wird die Verbindung bzw. Sitzung Ende-zu-Ende-verschlüsselt. Das bedeutet, die Stationen zwischen Client und Server können die Kommunikation nicht entschlüsseln.

Für die Authentifizierung und Verschlüsselung ist SSL/TLS verantwortlich. Es schiebt sich zwischen HTTP und dem Transportprotokoll TCP. Damit steht SSL/TLS auch für andere Anwendungsprotokolle zur Verfügung. Beispielsweise SMTPS, IMAPS und FTPS. SSL arbeitet für den Anwender nahezu unsichtbar.
SSL wurde bis zur Version 3.0 von Netscape entwickelt und dann von der IETF in TLS überführt. Obwohl heute durchgehend TLS zum Einsatz kommt, spricht man immer noch gerne von SSL.

Wie funktioniert HTTPS?

Die folgende Darstellung und Beschreibung des Ablaufs der HTTPS-Authentifizierung mit SSL/TLS ist zum besseren Verständnis vereinfacht.

  1. Der Verbindungsaufbau erfolgt über einen HTTPS-Request vom Client zum Server. Beim Client handelt es sich beispielsweise um einen Webbrowser. Der Server wäre demnach ein Webserver.
  2. Der Server nimmt die Verbindung an und schickt sein Zertifikat mit dem öffentlichen Schlüssel seines Schlüsselpaares zur Authentifizierung an den Client.
  3. Der Client überprüft das Server-Zertifikat (Validierung). Erkennt der Client das Zertifikat als ungültig wird die Verbindung an dieser Stelle abgebrochen.
  4. Erkennt der Client das Zertifikat als gültig erzeugt der Client symmetrische Sitzungsschlüssel.
  5. Mit dem öffentlichen Schlüssel des Servers verschlüsselt der Client den Sitzungsschlüssel und schickt ihn an den Server. Vorher haben sich Client und Server auf ein gemeinsames Verschlüsselungsverfahren geeinigt.
  6. Mit seinem privaten Schlüssel kann der Server den verschlüsselten Sitzungsschlüssel entschlüsseln.
  7. Anschließend verschlüsselt der Server den HTTPS-Response mit dem Sitzungsschlüssel.
  8. Der Client entschlüsselt den HTTPS-Response und stellt den Inhalt dar.
  9. Danach werden alle Requests und Responses verschlüsselt, bis die Verbindung abgebaut wird.

Sitzungsschlüssel

Der Sitzungsschlüssel zum Verschlüsseln der eigentlichen Daten oder Kommunikation wird entweder asymmetrisch verschlüsselt übertragen oder alternativ per Diffie-Hellman-Verfahren auf beiden Seiten generiert.

Durchgängige Verschlüsselung mit HTTPS

Internet-Sicherheitsexperten fordern, dass HTTP-Verbindungen generell verschlüsselt sein sollten. So wird für HTTP 2.0 eine generelle und nicht optionale Verschlüsselung gefordert. Hier kann man sich natürlich die Frage stellen, warum der Abruf von Informationen im Internet verschlüsselt sein soll. Beim Online-Shopping und Online-Banking kann man das verstehen. Hier geht es um die Übertragung personenbezogener Daten und Zahlungsanweisungen. Das diese Verbindungen schützenswert sind, dass haben wir gelernt.

Doch wie sieht es zum Beispiel mit dem Abruf dieser Webseite aus? Warum sollte das verschlüsselt sein?

Nehmen wir einmal an, dass sich ein Journalist über die Verschlüsselungsmöglichkeiten von E-Mails mit GnuPG und Anonymisierungsmöglichkeiten durch Tor informiert. Wird dieser Informationsaustausch abgefangen und der Journalist identifiziert, dann könnte eine zentrale Stelle auf die Idee kommen, dass der Journalist Kontakt zu einem Whistleblower hat. Dann wird man intensiver überwachen und versuchen ihm einen Trojaner unterzuschieben. Wären seine HTTP-Verbindungen verschlüsselt gewesen, hätte niemand von seinem Informationsbedürfnis erfahren.

Die generelle Verschlüsselung macht Sinn, weil man davon ausgehen muss, dass der normale Internet-Nutzer über sein Tun und Handeln und den Konsequenzen nicht Bescheid weiß. Die meisten Internet-Nutzer sind nicht in der Lage zu entscheiden, wann sie Verschlüsselung brauchen, und wann es nicht notwendig ist. Deshalb wird die generelle Verschlüsselung von Internet-Verbindungen gefordert.

Wie sicher ist HTTPS?

Ob eine SSL-Verbindung mit HTTPS sicher ist oder nicht bestimmt in der Hauptsache das Verhalten des Clients bei der Überprüfung des SSL-Zertifikats des Servers. Der Client muss prüfen, ob das vom Server vorgelegte Zertifikat ihm gehört und ob es noch gültig ist. Dazu verwendet der Client OCSP (Online Certificate Status Protocol), um bei der verantwortlichen Zertifizierungsstelle (Certificate Authority, CA) nachzufragen. Diesen Vorgang nennt man Validierung.

Die Implementierung von OCSP im Browser ist allerdings generell defekt. Wenn der Browser nach einer bestimmten Zeit keine Antwort von der Zertifizierungsstelle bekommt, dann muss er das Zertifikat ungeprüft akzeptieren. Das bedeutet, wenn ein Angreifer in der Lage ist, die Validierung in irgendeiner Weise zu behindern, kann er den Verbindungsaufbau manipulieren und sich beispielsweise als Man-in-the-Middle trotz Verschlüsselung in die Verbindung zwischen Client und Server einklinken.
Ein weiterer Knackpunkt, den jede verschlüsselte Verbindung mitbringt, ist wenn der Sitzungsschlüssel übertragen wird. Oder wenn der geheime Schlüssel bekannt wird und man dadurch auf die Sitzungsschlüssel schließen kann und aufgezeichnete, verschlüsselte Übertragungen nachträglich entschlüsseln kann. Mit PFS in Kombination mit Diffie-Hellman kann man HTTPS bzw. SSL/TLS noch sicherer machen. Trotzdem bleibt noch das Problem mit dem Akzeptieren von Zertifikaten, die wegen einer nicht erreichbaren oder kompromittierten Zertifizierungsstelle, trotzdem akzeptiert werden.

Übersicht: HTTP

Übersicht: SSL / TLS