Https

HTTPS (Hypertext Transfer Protocol Secure)
Familie:	Internetprotokollfamilie
Einsatzgebiet:	Verschlüsselte Datenübertragung
Port:	443/TCP
HTTPS im TCP/IP‑Protokollstapel: Anwendung HTTP Transport SSL/TLS TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI …
Standards:	RFC 2818 (HTTP Over TLS, 2000)

HTTPS steht für HyperText Transfer Protocol Secure (dt. sicheres Hypertext-Übertragungsprotokoll) und ist ein Verfahren, um Daten im World Wide Web abhörsicher zu übertragen. Technisch definiert es als URI-Schema eine zusätzliche Schicht zwischen HTTP und TCP. HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 erstmals 1994 mit deren Browser veröffentlicht.

Nutzen

Das HTTPS Protokoll wird zur Verschlüsselung, zur Authentifizierung der Kommunikation zwischen Webserver und Browser im World Wide Web verwendet.

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 S-HTTP.

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:

• Es wird serverseitig ausschließlich HTTPS zugelassen, wie meist bei Online-Banking; teils wird dabei eine angewählte http-Adresse automatisch in https umgesetzt.
• Einwahl wird über https erzwungen, dann wird ein HTTP-Cookie im Browser gesetzt und, um Rechenzeit zu sparen, der weitere Dienst unverschlüsselt abgewickelt; z. B. bei 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. bei 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.

Vorinstallierte Zertifikate

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde 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, kurz danach auch Mozilla mit dem Firefox 3, die Warnung bei nicht eingetragenen Zertifikaten verschärft: Erschien vorher nur ein Pop-up „Sicherheitshinweis“, das nach Name, Quelle und Laufzeit des Zertifikats differenzierte, so wird nun der Inhalt der Webseite ausgeblendet und eine Warnung angezeigt, mit der Empfehlung, die Seite nicht zu benutzen. Um diese sehen zu können, muss der Anwender dann explizit eine „Ausnahme hinzufügen“. 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 CAcert.

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 im Allgemeinen 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. Dazu gehört auch CAcert, wo es bisher jedoch nicht gelang, diese in die Liste der vom Browser automatisch akzeptierten Zertifikate aufnehmen zu lassen (siehe oben). Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

Es ist weiterhin auch möglich, selbst-signierte Zertifikate (self-signed certificate) zu verwenden, die ohne Beteiligung einer gesonderten Instanz 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.

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

Um veraltete oder unsicher gewordene Zertifikate ungültig zu erklären, sind Zertifikatsperrlisten (engl. Certificate Revocation List - CRL) vorgesehen. Die Konzeption sieht vor, dass diese Listen regelmäßig etwa von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden. Das Verfahren ist jedoch nicht durchgängig organisiert und wird praktisch nur wenig genutzt.

Zu Angriffen auf das Zertifikatsystem, siehe unten.

Extended-Validation-Zertifikat

Vor dem Hintergrund zunehmender Phishing-Angriffe auf HTTPS-gesicherte Webanwendungen hat sich 2007 in den USA das CA/Browser Forum gebildet, das aus Vertretern von Zertifizierungs-Organisationen und den Browser-Herstellern Google, KDE, Microsoft, Mozilla und Opera besteht. Im Juni 2007 wurde daraufhin eine erste gemeinsame Richtlinie verabschiedet, das Extended-Validation-Zertifikat, kurz EV-SSL in Version 1.0, im April 2008 dann Version 1.1.

Ein Domain-Betreiber muss für dieses Zertifikat weitere Prüfungen akzeptieren: Während bisher nur die Erreichbarkeit des Admins (per Telefon und E-Mail) zu prüfen war, wird nun die Postadresse des Antragstellers überprüft und bei Firmen die Prüfung auf zeichnungsberechtigte Personen vorgenommen. Damit sind auch deutlich höhere Kosten verbunden, exemplarisch 650 € p.a.

Für den Anwender macht sich das EV-Zertifikat durch eine zusätzliche   weiß auf grün unterlegte Firma   in der Adresszeile des neueren Browsers (ab 2007, also etwa Firefox3 und IE7), rechts vom Site-Logo, bemerkbar. Durch das Ausbleiben der (für diese Site) gewohnten grünen Farbe soll der Anwender dann gefälschte HTTPS-Sites schnell und ggfs. auch intuitiv – also ohne spezielle Schulung – erkennen können.

IP-Adresse

Zum Betrieb eines HTTPS-Webservers ist bisher eine eigene IP-Adresse pro Hostname notwendig.

Dies ist bei unverschlüsselten HTTP 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, zum Beispiel bei Apache über den NameVirtualHost-Mechanismus. Dieses Verfahren wird inzwischen bei der weit überwiegenden Zahl der Domains benutzt, da hier der Domain-Eigner selbst keinen Server betreibt.

Da bei HTTPS jedoch der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname aber erst nach erfolgtem SSL-Handshake in der höheren HTTP-Schicht übertragen wird, ist das Deklarieren des Hostnamen im HTTP-header 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 soll dies via Server Name Indication (SNI) ermöglicht werden. Aktuelle Browser, wie beispielsweise Mozilla Firefox ab Version 2.0 oder der Internet Explorer 7 (jedoch nur ab Windows Vista), unterstützen SNI bereits.

Shared SSL

Das Zertifikat bezieht sich normalerweise auf die komplette Domain, also Third-, Second- und Top-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.^[1]

Einbindung

Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten Varianten der HTTPS-Anwahl:

• Wenn ausschließlich HTTPS zulässig ist, kann dies umgesetzt werden durch:
  • Weiterleitung (HTML-refresh) oder auch ein rewrite der URL
  • Konfiguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung SSLRequireSSL in der .htaccess. Wird eine solche Seite per http aufgerufen, erzeugt der Server einen '403 - Forbidden' HTTP-Fehlercode.
• Der Anwender wird auf die Möglichkeit der SSL-Nutzung durch einen entsprechenden Link hingewiesen. Auf diese Weise wird die Serverlast gering gehalten, während sicherheitsbewußte Nutzer nicht abgewiesen werden.
  • Teils wird auch der Link weggelassen, und der Anwender kann https nutzen, indem er in der URL selbstständig ein "s" hinter "http" eintippt.
• Skript-gesteuerte Erzeugung von HTTPS-Links, um den Anwender bei bestimmten Arbeitsschritten oder Ausgaben auf eine HTTPS-Seite zu lenken. Anschließend kann im Skript geprüft werden, ob dieses per HTTPS aufgerufen wurde, bei PHP etwa durch die Bedingung: $_SERVER['port']==443

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. 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. Der Client wählt dann den ersten von ihm unterstützten Algorithmus aus dieser Liste aus. Um Rechenzeit zu sparen, werden auf Servern mit hohem Datenverkehr bevorzugt Strom-Chiffren wie RC4 (bis 128 Bit) verwendet, da diese weniger rechenintensiv sind als Block-Chiffren wie AES oder Camellia (bis 256 Bit). Anfangs teils noch genutzte 40-Bit-Schlüssel-Algorithmen, die wiederum weniger Rechenlast verursachen, gelten nicht mehr als sicher und werden daher heute i.a. nicht mehr verwendet.

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

Angriffe und Schwachstellen

Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL-gesicherte Verbindungen gehäuft. Daneben sind durch Recherche und Forschungen Lücken in der Umsetzung bekannt geworden.

Dabei ist grundsätzlich zu unterscheiden zwischen Schwachstellen bei der Verschlüsselung selbst und im Zertifikatsystem.

Verschlüsselung

Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig überprüft und gelten als mathematisch sicher, d.h. sie lassen sich schon theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter Kryptologen überprüft.

Im Mai 2008 wurde jedoch ein Fehler in der OpenSSL-Bibliothek der Debian-Linux-Distribution und davon abgeleiteter wie Ubuntu bekannt, der bereits seit September 2006 bestand.^[3][4] Der Fehler bewirkte, dass mit einem solchen OpenSSL erzeugte Schlüssel in einem sehr viel kleineren Bereich liegen, mit überschaubarem Aufwand gebrochen und damit die Daten ggf. auch nachträglich entschlüsselt werden können. Server-Betreiber mussten daraufhin nicht nur ihre SSL-Software prüfen, sondern ggfs. auch die im Laufe der zwei Jahre damit erstellten Schlüssel nachverfolgen und erneuern.

Für die Anwenderseite wurden daraufhin Möglichkeiten entwickelt, über Browser-Plug-ins einerseits "schwache" Zertifikate angezeigt zu bekommen, andererseits erweiterte Prüfungen auf Browser-Seite vorzunehmen; so befragt das "Perspectives"-Plugin mehrere "Notare", welches Zertifikat sie bei der gleichen Site sahen.^[4]

Der Vorgang führte auch zu Kritik an den Prozessen bei Debian und am Open Source-Entwicklungsmodell im Ganzen, etwa bei heise.de: "Das offensichtliche Fehlen von wirksamen Qualitätssicherungsmechanismen bei der Pflege von sicherheitskritischen Programmpaketen (...) wird es Verfechtern von Open-Source-Software nicht unbedingt leichter machen, diese im professionellen Umfeld einzusetzen." ^[5]

Zertifikatsystem

SSL-Verbindungen sind grundsätzlich gefährdet durch Man-in-the-middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt bzw. sich als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass er sich im gleichen LAN befindet, andere im gleichen WLAN, was mit dessen Verbreitung wahrscheinlicher wird. Beim DNS-Spoofing wiederum bestehen diese Voraussetzungen nicht.

Um sich als (anderer) Server auszugeben, muss der Angreifer freilich auch ein Zertifikat vorweisen:

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 simulieren und dem Anwender eine sichere Verbindung vortäuschen, um eingegebene PIN/TAN-Codes „abzufischen“. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-URLs nur manuell oder per Lesezeichen einzugeben.

Wegen der teils oberflächlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browser-Herstellern das extended-validation-Cert eingeführt, siehe oben.

Warnungen bei Gemischtbetrieb

Im Rahmen der immer ausgeklügelteren Phishing-Angriffe wurde ein weiteres Problem erkannt: Der Wechsel einer https-verschlüsselten Seite zu einer unverschlüsselten sowie das Nachladen von unverschlüsselten Inhalten aus einer per HTTPS übertragenen Seite. Während es – aus Performance-Gründen – seitens des Anbieters durchaus sinnvoll sein kann, nur einzelne Elemente einer Seite HTTPS-gesichert auszugeben, stellt dies auch eine mögliche Sicherheitslücke dar. Daher blenden die gängigen Browser in solchen Fällen Warnhinweise ein. Damit diese auf Dauer nicht stören, können sie i. a. durch eine Checkbox direkt bleibend abgeschaltet werden – womit aber auch der Warneffekt bei tatsächlichen Angriffen entfällt.

Angriffe auf das Zertifikatsystem

Im Rahmen des 25. Chaos Communication Congress in Berlin wurde im Dezember 2008 ein erfolgreicher Angriff auf das SSL-Zertifikatsystem veröffentlicht. In internationaler Zusammenarbeit von Kryptologen und mit Einsatz speziell programmierter Hardware - einem Cluster aus 200 Playstation-3-Spielkonsolen - war es gelungen, im MD5 Algorithmus eine Kollision zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen könnte. ^[6] Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten, bei EV-Zertifikaten kann er ohnehin nicht verwendet werden.

Anlässlich dieser Veröffentlichung wurde unter Experten auch die neuerdings scharfe Trennung der Browser zwischen eingetragenen und unbekannten Zertifikaten (siehe oben) kritisch hinterfragt. ^[7]

Einzelnachweise

1. ↑ CaCert.org: CAcert Wiki VhostTaskForce, 3. Way: Certificate with 1 Common Name + 2 Subject Alt Names, 4. Oktober 2007
2. ↑ anandtech.com: Quad Core Intel Xeon SSL Performance, 27. Dezember 2006
3. ↑ debian.org:DSA-openssl -- predictable random number generator, 13. Mai 2008
4. ↑ ^{a b} heise.de: Konsequenzen der erfolgreichen Angriffe auf MD5, 6. Januar 2009
5. ↑ heise.de: Die Bedeutung der Zufallszahlen beim OpenSSL-Debakel, 27. Mai 2008
6. ↑ heise.de: 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem, 30. Dezember 2008
7. ↑ heise security news-Foren: Vertrauenswürdigkeit von Zertifikaten, 30. Dezember 2008

Weblinks

• RFC 2818 – HTTP Over TLS (englisch)
• Wie funktioniert HTTPS?
• Serversniff.de prüft HTTPS-Server auf Zertifikatsinfos, Protokolle und angebotene Verschlüsselungsmethoden
• HttpTea, zeigt HTTPS im Klartext an. (englisch)
• Wildcard-Zertifikate bei Geotrust – und bei CAcert