Netsolution

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 IP-Pakete, für jeden, der Zugang zum entsprechenden Netz hat, als 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.

Die Verschlüsselung auf Serverseite ist rechenaufwändig und belastet die Server-CPU häufig stärker als etwa die Errechnung des HTML-Codes aus einer Skriptsprache inklusive Datenbank-Zugriff. Auch aus diesem Grunde hat sich HTTPS bisher nur bei einem kleinen Teil der Websites durchgesetzt, bei denen es aus Sicht des Datenschutzes sinnvoll ist.

Die Liste der vom Server unterstützten Verschlüsselungs-Algorithmen wird serverseitig konfiguriert. Um bei hohem Datenverkehr Rechenzeit zu sparen, werden neben den möglichen 128-Bit-Schlüsseln teils noch 40-Bit-Schlüssel verwendet. Diese sind aber vergleichsweise einfach zu „knacken“, gelten nicht mehr als sicher und werden daher kaum noch genutzt.

Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (SSL accelerators) angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwändige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun.

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, gegebenenfalls 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.

 Zurück