Hypertext Transfer Protocol Secure

Aus Kefk

HTTPS: SSL im TCP/IP-Protokoll

Anwendung	HTTPS
Transport	SSL/TLS
	TCP
Internet	IP
Netzzugang	Ethernet	Token Ring	FDDI	…

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.

Inhaltsverzeichnis 1 Nutzen 2 Technik 3 Server-Voraussetzungen 3.1 Zertifikat 3.2 IP-Adresse 3.2.1 shared SSL 4 Client-Verarbeitung 5 Performance 6 Quellen 7 Weblinks

Nutzen

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.

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

Server-Voraussetzungen

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

Zertifikat

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

IP-Adresse

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.

Mit der in Planung befindlichen Spezifikation TLS 1.2 soll dies via „Server Name Indication“ ermöglicht werden.

shared SSL

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

Client-Verarbeitung

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 die HTTP-Verbindung nicht hergestellt wird.

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.

Eine bestehende HTTPS-Verbindung wird durch das SSL-Logo angezeigt – beim Internet Explorer 6 ein Schloss-Icon in der Status-Leiste, bei Mozilla zusätzlich in der Adresszeile, die bei Firefox, aktuellen Opera und Internet Explorer 7 Browsern zusätzlich gelb hinterlegt wird.

Performance

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 Traffic 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 Performance 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 ^[2].

Quellen

Weblinks

• RFC 2818 – HTTP Over TLS (englisch)
• Wie funktioniert HTTPS?
• Serversniff.de prüft HTTPS-Server auf Zertifikatsinfos, Protokolle und angebotene Verschlüsselungsmethoden
• HTTPS-FAQ und Schlüssel-Sicherheit.
• Wildcard Certs bei Geotrust - und bei CAcert

Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Hypertext_Transfer_Protocol_Secure, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.