Bootstrap

Hypertext Transfer Protocol Secure

HTTPS im TCP/IP-Protokollstapel:
Anwendung HTTP
Transport SSL/TLS
TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI

HTTPS steht für HyperText Transfer Protocol Secure (engl. sicheres Hyptertext-Übertragungsprotokoll) 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.

Inhaltsverzeichnis

Nutzen

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

Ohne Verschlüsselung sind Web-Daten 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.

Technik

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 eingesetzt.

Eine ältere Protokollvariante von HTTPS war SHTTP.

Client-Verarbeitung

Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die anwenderseitige Client-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.

Eine HTTPS-Verbindung wird durch eine https-URL angewählt und durch das SSL-Logo angezeigt – beim Internet Explorer 6 ein Schloss-Icon in der Statusleiste, bei Mozilla zusätzlich in der Adresszeile, die bei Firefox, aktuellen Opera- und Internet Explorer 7-Browsern zusätzlich gelb hinterlegt wird, bei Apple Safari 3.0 durch ein kleines Schloss-Symbol in der obersten rechten Ecke des Browserfensters.

Varianten der HTTPS-Anwahl

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

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.

Vorinstallierte Zertifikate

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurden mit der Zeit eine Reihe von Root-Zertifikaten von den Browser-Herstellern akzeptiert, die schon bei der Installation eingetragen werden. Webseiten, die entsprechende Zertifikate haben, werden dann, 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 teils auch online im Rahmen der Systemaktualisierung auf den neuesten Stand gebracht, so bei Microsoft Windows.

Mit dem neueren Internet Explorer 7 hat Microsoft die Warnung bei nicht eingetragenen Zertifikate verschärft: Erschien vorher nur ein Pop-up „Sicherheitshinweis“, das nach Name, Quelle und Laufzeit des Zertifikats differenzierte, so wird nun anstatt der Webseite eine Warnung über das ganze Fenster angezeigt, mit der Empfehlung, die Seite nicht zu benutzen. Ein nicht im Browser eingetragenes Zertifikat wird damit für Massenanwendungen zunehmend untauglich.

Die Frage, welche Zertifikate in die Browser aufgenommen werden, hat in der open-source-Community fallweise zu längeren Diskussionen geführt, so zwischen CAcert, einem Anbieter kostenloser Zertifikate, und der Mozilla Foundation, siehe dort.

Phishing und HTTPS

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 per Lesezeichen einzugeben.

Server-Voraussetzungen

Als Software zum Betrieb eines HTTPS-fähigen Webservers wird eine SSL-Bibliothek wie OpenSSL benötigt. Diese wird häufig bereits mitgeliefert oder kann als Modul installiert werden. Der HTTPS-Service wird üblicherweise auf Port 443 bereit gestellt.

Zertifikat

Weiterhin ist ein Digitales Zertifikat für SSL notwendig: Ein Binärdokument, das von einer – selbst wiederum zertifizierten – Zertifizierungsstelle ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und die Firmierung des Antragstellers geprüft.

Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Im Falle CAcert ist es bisher jedoch nicht gelungen, diese in die Liste der vom Browser automatisch akzeptierten Zertifikats aufzunehmen (siehe oben), 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; neuerdings auch als kostenlos beworbene (Startcom.org).

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 [1].

IP-Adresse

Weiterhin ist zum Betrieb eines HTTPS-Webservers im Allgemeinen eine eigene IP-Adresse pro Hostname notwendig. Dies ist beim unverschlüsselten HTTP-Protokoll nicht notwendig: Seitdem Browser den Hostnamen im HTTP-Header mitsenden, können mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden; z. B. bei Apache über den NameVirtualHost Mechanismus. Da bei HTTPS aber der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname jedoch erst nach erfolgtem SSL-Handshake in der höheren HTTP-Schicht übertragen wird, ist dieses Verfahren hier nicht anwendbar. Eine Unterscheidung kann nur anhand der IP/Port-Kombination erfolgen; 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“ (en) ermöglicht werden.

Shared SSL

Das Zertifikat 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-Adresse 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 Zertifikat 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/.

Zusätzlich zu den Wildcard-Zertifikaten gibt es auch die Möglichkeit, mehrere Domain-Namen in ein Zertifikat mittels der zusätzlichen Eigenschaft SubjAlt-Name (alternativer Name) einzusetzen. Unterstützt wird dies bereits von allen aktuellen Browsern.[2]

Leistung

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 benutzt.

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.

Spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und Multi-Core-Systeme der großen CPU-Hersteller Intel und AMD.[3]

Quellen

Weblinks