HTTPS

HTTPS steht für HyperText Transfer Protocol Secure und ist ein URI-Schema, das eine zusätzliche Schicht zwischen HTTP und TCP definiert. HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 im August 1994 mit deren Browser veröffentlicht.

HTTPS dient zur Verschlüsselung und zur Authentifizierung der Kommunikation zwischen Webserver und Browser im World Wide Web.

Ohne Verschlüsselung sind alle Web-Daten für jeden, der Zugang zu einem Netz hat, durch das die IP-Pakete laufen, im Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden. Es stellt dabei das einzige Verschlüsselungsverfahren dar, das ohne gesonderte Softwareinstallation auf allen Internet-fähigen Computern unterstützt wird.

Die Authentifizierung dient dazu, dass sich jede Seite der Identität des Verbindungspartners vergewissern kann – ein Problem, das durch Phishing-Angriffe zunehmend Bedeutung bekommt.

Syntaktisch ist HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels SSL/TLS:

Unter Verwendung des SSL Handshake Protokolls findet zunächst eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Anschließend wird mit Hilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht. Dieser wird schließlich zur Verschlüsselung der Nutzdaten verwendet.

Der Standard-Port für HTTPS-Verbindungen ist 443.

Neben den Server-Zertifikaten können auch signierte Client-Zertifikate nach X.509.3 erstellt werden. Dies ermöglicht eine Authentifizierung der Clients gegenüber dem Server, wird jedoch selten genutzt.

Eine ältere Variante des HTTPS-Protokolls war SHTTP.

Als Software zum Betrieb eines HTTPS-fähigen Webservers wird eine SSL-Bibliothek wie OpenSSL benötigt.

Weiterhin ist ein Digitales Zertifikat (auch Cert) für SSL notwendig: Ein Binärdokument, das von einer – selbst wiederum zertifizierten – Zertifizierungsstelle ausgestellt wird, um die Authentizität der Domain zu sichern. Bei der Beantragung werden dazu etwa die Adressdaten und die Firmierung des Antragsstellers geprüft.

Eine Reihe von Zertifizierungsstellen geben kostenlos Zertifikate aus, so CAcert. Diesen liegt jedoch meist kein Vertrag mit den Browser-Herstellern zugrunde, weshalb das Zertifikat bei der Client-Verarbeitung vom Anwender bestätigt werden muss; dieses Verhalten kann aber auch erwünscht sein.

In den registrierten Root-Chains eingetragene Zertifikate werden zu Preisen zwischen 39 und 1.200 US-$ pro Jahr angeboten, wobei teils weitere Services, Siegel oder Versicherungen enthalten sind.

Weiterhin werden teilweise unsignierte dummy-Zertifikate verwendet, die ohne jedes Zertifizierungsverfahren selbst erstellt wurden. Diese müssen ebenfalls manuell bestätigt werden. Damit wird zwar die Verschlüsselung, nicht aber die Authentifizierung erreicht; solche Verbindungen sind damit verwundbar für einen Man-In-The-Middle-Angriff.

Im Januar 2007 berichtet heise.de von einem neuen Zertifizierungsprozess EV-SSL, der u.a. von Microsoft voran getrieben wird und vor allem strengere Regeln für die Vergabe der Server-Zertifikate festlegt; die Akzeptanz und Wirkung des Ansatzes wird jedoch kritisch kommentiert

Weiterhin ist zum Betrieb eines HTTPS-Webservers i.a. eine eigene IP-Adresse notwendig, da das sonst bei einem Virtual Server (etwa beim Apache HTTP Server über den Vhost Mechanismus) mögliche Aushandeln eines abweichenden Domain-Namens nicht per HTTPS möglich ist: Da SSL unter der HTTP-Schicht operiert und keine Informationen der höheren Schicht hat, kann ein SSL-Server nur ein Zertifikat für jede IP/Port Kombination ermitteln. Ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert.

Mit der in Planung befindlichen Spezifikation Transport Layer Security 1.2, die jedoch auch von aktuellen Browsern noch nicht unterstützt wird, soll dies via „Server Name Indication“ ermöglicht werden.

Das Cert bezieht sich normalerweise auf die komplette Domain, also third-, second- und first-level-Segmente, wie https://www.kunde1.com. Um ihren Kunden auch https ohne eigene IP zu ermöglichen, benutzen einige Provider spezielle "shared SSL" oder auch "wildcard certificates", bei denen die third-level-domain kundenspezifisch vergeben werden kann - also etwa https://kunde1.provider.com, während sich das Cert auf *.provider.com bezieht.

Eine weitere Variante besteht darin, eine Weiterleitung auf einen von mehreren Domains genutzten HTTPS-Server vorzunehmen, etwa https://provider.com/ssl/kunde1/.

Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die Client-seitige Software schon früh in den Browser integriert. Damit ist, anders als etwa bei E-Mail (S/MIME oder GnuPG), SSH oder SFTP, die Installation gesonderter Software durch den Anwender nicht notwendig.

Die Entscheidung, ob eine sichere https- statt einer http-Verbindung genutzt wird, kann unterschiedlich erfolgen:

Es wird serverseitig ausschließlich https zugelassen, wie meist bei online-Banking.
Einwahl wird über https erzwungen, dann wird ein HTTP-Cookie im Browser gesetzt und der weitere Dienst unverschlüsselt abgewickelt, um Rechenzeit zu sparen (z. B. sourceforge oder Ebay).
Login per http-Adresse, die aber vom Anwender manuell in „https..“ geändert werden kann, um eine Verschlüsselung zu bewirken (z. B. GMX); teils auch über einen Link „Sicheres Login“ o. ä.
Nach Anwahl der https-Adresse soll der Client-Browser gemäß der ursprünglichen Konzeption dem Anwender zuerst das Zertifikat anzeigen. Dieser entscheidet nun, ggf. nach Prüfung über die angegebenen Links, ob er dem Zertifikat für diese Sitzung oder auch permanent vertraut. Andernfalls wird die HTTPS-Verbindung nicht hergestellt.

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurden mit der Zeit eine Reihe von Root-Zertifikaten in den Browsern eingetragen und werden nun, ebenso wie davon abgeleitete Unter-Zertifikate, bei Aufruf ohne Nachfrage akzeptiert. Ob ein Root-Zertifikat dem Browser bekannt ist, hängt von der Browser-Version ab; zudem wird die Liste der Zertifikate meist online aktualisiert, so bei Windows XP.

Ein Nachteil der automatischen Bestätigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt. Dies wurde in jüngerer Zeit bei Phishing-Angriffen ausgenutzt, die etwa online-Banking Anwendungen simulierten. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-URLs nur manuell oder via Lesezeichen einzugeben.

zurück