Hypertext Transfer Protocol Secure Familie: Internetprotokollfamilie Einsatzgebiet: verschlüsselte Datenübertragung Port: 443/TCP Standards: RFC 9110 (HTTP Semantics, 2022)
Hypertext Transfer Protocol Secure (HTTPS; für „sicheres Hypertext-Übertragungsprotokoll“) ist ein Netzwerkprotokoll im World Wide Web, mit dem Daten abhörsicher übertragen werden können. Es stellt ein Verschlüsselungsprotokoll für die Transportverschlüsselung dar. Technisch baut HTTPS auf TLS auf, das eine zusätzliche Kommunikationsschicht zwischen HTTP und TCP darstellt. Eine HTTPS-Adresse wird über das URI-Schema „https“ identifiziert.
HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 erstmals 1994 mit deren Browser veröffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als Request for Comments RFC 2818 veröffentlicht. Diese wurde im Jahr 2022 durch den Internetstandard RFC 9110 abgelöst.
Nutzen mini|Schloss als Icon der Adressleiste HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet. Dies wird unter anderem durch Verschlüsselung und Authentifizierung erreicht.
Ohne Verschlüsselung sind Daten, die über das Internet übertragen werden, für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von offenen (d. h. unverschlüsselten) WLANs nimmt die Bedeutung von HTTPS zu, weil damit die Inhalte unabhängig vom Netz verschlüsselt werden können.
Die Authentifizierung dient dazu, dass beide Seiten der Verbindung beim Aufbau der Kommunikation die Identität des Verbindungspartners überprüfen können. Dadurch sollen Man-in-the-Middle-Angriffe und teilweise auch Phishing verhindert werden.
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. Das 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 Webbrowser integriert. Damit ist meist keine weitere Installation gesonderter Software notwendig.
rechts|gerahmt Eine HTTPS-Verbindung wird durch eine https-URL angewählt und durch das SSL-Logo angezeigt. Dies wird bei allen geläufigen Browsern als kleines Schloss-Symbol in der Adresszeile dargestellt.
Varianten der HTTPS-Anwahl Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen: Serverseitig wird ausschließlich HTTPS zugelassen; eine aufgerufene HTTP-Adresse wird automatisch auf HTTPS weitergeleitet. Dies entspricht dem Stand der Technik im Internet. Der Login wird über HTTPS erzwungen, bei dem ein HTTP-Cookie im Browser gesetzt wird, während die anderen Seitenaufrufe im Klartext gesendet werden. Dies war eine früher übliche Vorgehensweise, um sensible Informationen wie das Passwort oder Zahlungsdaten zu schützen, und ansonsten Rechenzeit zu sparen. HTTP Strict Transport Security (HSTS): Der Server signalisiert beim ersten Seitenaufruf, dass der Client für alle zukünftigen Aufrufe HTTPS verwenden muss. Der Client speichert diese Information und stellt bei zukünftigen Besuchen immer eine Verbindung über HTTPS her. Dies entspricht dem Sicherheitsmodell Trust on First Use. Einige Browser-Hersteller liefern eine vorinstallierte Liste von HSTS-Einträgen aus, mit der der Browser auch schon beim ersten Besuch die Verwendung von HTTPS erzwingt.Preloading HSTS. Clientseitige Eingabe der HTTPS-Variante oder Browser-Plug-in (z. B. für Firefox und Chrome „HTTPS Everywhere“), welches HTTP-Anfragen durch HTTPS-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen. Seit 2020 (Version 83) kann Firefox so eingestellt werden, dass es nur HTTPS verwendet. Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.
Vertrauensanker Die Authentizität einer aufgerufenen HTTPS-Adresse ergibt sich durch ein Digitales Zertifikat des Webservers. Das Zertifikat ist Teil einer Public-Key-Infrastruktur (PKI) nach dem X.509-Standard. Serverzertifikate werden von Zertifizierungsstellen ausgestellt, deren Wurzelzertifikate dem Browser bekannt sein müssen und als Vertrauensanker dienen. Ist das Serverzertifikat authentisch, so zeigt der Browser die Verbindung als sicher an.
Ist das Wurzelzertifikat dem Browser nicht bekannt, so führt das zu einer Sicherheitswarnung beim Seitenaufruf. Je nach Einstellung der Browser und des Servers (HSTS, siehe oben) kann der Anwender die Seite entweder gar nicht aufrufen oder explizit auf eigenes Risiko eine „Ausnahme hinzufügen“. Eine Website ohne ein im Browser eingetragenes Zertifikat ist damit für Massenanwendungen untauglich.
Je nach Browser und Betriebssystem liefern die Browser-Hersteller entweder eine Liste von vertrauenswürdigen Stammzertifikaten mit oder greifen auf den Zertifikatsspeicher des Betriebssystems zurück. Ob ein Wurzelzertifikat dem Browser bekannt ist, hängt somit von der Version des Browsers und des Betriebssystems ab. Die Liste der vertrauenswürdigen Wurzelzertifikate wird durch den Hersteller mit Softwareaktualisierungen auf den neuesten Stand gebracht.
Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des CA/Browser Forums. Die Zertifizierungsstelle muss hierbei durch einen externen Audit nachweisen, mit den Sicherheitsvorgaben konform zu sein. Da dies mit Kosten verbunden ist, stellt es eine Aufnahmehürde dar. Das in der Open-Source-Community verbreitete CAcert, ein früher Anbieter kostenloser Zertifikate, ist eine prominente Zertifizierungsstelle, das nicht in den Browsern mitgeliefert wird. Anwender, die eine Seite mit CAcert-Zertifikat besuchen, müssen das Wurzelzertifikat händisch installieren.
Um die Verbreitung von HTTPS zu fördern, ging Ende 2015 die gemeinnützige Zertifizierungsstelle Let’s Encrypt in Betrieb. Let’s Encrypt stellt für jeden kostenlose Zertifikate aus, die von den gängigen Browsern als vertrauenswürdig akzeptiert werden. Für die Installation und laufende Aktualisierung der Zertifikate ist eine Software auf dem Server notwendig.
Server-Betrieb 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 bereitgestellt.
Zertifikat Das digitale Zertifikat für SSL, das die Authentifizierung ermöglicht, ist vom Server bereitzustellen. Das Zertifikat ist ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – Zertifizierungsstelle (CA von ) ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.
In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von Let’s Encrypt ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt CAcert, wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe oben. Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.
Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind Zertifikatsperrlisten (, CRL) vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.
Mit dem OCSP (Online Certificate Status Protocol) kann, ergänzt um SCVP (Server-based Certificate Validation Protocol), serverseitig die Unterstützung für Zertifikats-Prüfungen umgesetzt werden.apache.org: Apache 2.5 OCSP Stapling, abgerufen am 23. Juli 2017.
Zu Angriffen auf das Zertifikatsystem, siehe unten.
Selbst-signiert Ein Server-Betreiber kann auch selbst-signierte Zertifikate (englisch ) kostenlos erstellen, ohne Beteiligung einer dritten Instanz. Diese müssen vom Browser-Anwender manuell bestätigt werden ('Ausnahme hinzufügen'). In diesem Fall garantiert kein Dritter die Authentizität des Anbieters. Ein solches Zertifikat kann wiederum dem Anwender vorab auf einem sicheren Weg zugestellt und in seine Client-Anwendung importiert werden, um Authentizität auf anderem Wege abzubilden.
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 Zertifizierungsorganisationen und den Browser-Herstellern besteht. Zum Gründungszeitpunkt waren die Browser-Hersteller KDE, Microsoft, Mozilla und Opera beteiligt. 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 Administrators (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.
IP-Adressen bei mehreren Domains Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene IP-Adresse pro Hostname notwendig.
Bei unverschlüsseltem HTTP ist das nicht erforderlich: 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 Hostnamens im HTTP-Header hier nicht anwendbar. Dadurch war eine Unterscheidung nur anhand der IP/Port-Kombination möglich; ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert.
Vor diesem Hintergrund nutzten einige Provider einen Workaround, um ihren Kunden auch HTTPS ohne eigene IP-Adresse zu ermöglichen, etwa „shared SSL“. Sie nutzten Wildcard-Zertifikate, die für alle Subdomains einer Domain gültig sind, in Verbindung mit kundenspezifischen Subdomains. Andere Provider nutzten einen „SSL Proxy“, der die Anfragen über eine von mehreren Kunden genutzte Domain leitete.