Hypertext Transfer Protocol Secure: Unterschied zwischen den Versionen

Aktuelle Version vom 2. November 2024, 15:37 Uhr

Hypertext Transfer Protocol Secure (HTTPS) - Kommunikationsprotokoll zur sicheren Datenübertragung

Beschreibung

HTTPS im TCP/IP-Protokollstapel

Familie

Internetprotokolle

Einsatzgebiet

Port

443/TCP

Anwendung	HTTP/3	DNS over QUIC		…
Transport	UDP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Standards

RFC 2818 (HTTP Over TLS, 2000)

Sicheres Hypertext-Übertragungsprotokoll

Kommunikationsprotokoll im World Wide Web, mit dem Daten abhörsicher übertragen werden können
Technisch definiert wurde 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

Transportverschlüsselung

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 Kryptografie und Authentifizierung erreicht

Ohne Kryptografie 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 Kryptografie 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 Kryptografie oder des Diffie-Hellmans ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht
Dieser wird schließlich zur Kryptografie der Nutzdaten verwendet
Der Standard-Port für HTTPS-Verbindungen ist 443
Eine ältere Protokollvariante von HTTPS war S-HTTP

Client-Zertifikate

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

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

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

HTTPS-Anwahl

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

Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei Online-Banking; teils wird dabei eine angewählte http-Adresse automatisch auf https weitergeleitet
Der Login 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 eBay
Clientseitig durch HSTS: Wenn der Server nur HTTPS zulässt (wie oben beschrieben), kann der Browser dies speichern und stellt zukünftig immer eine Verbindung über HTTPS her
Steht der Server zusätzlich auf der HSTS Preload Liste, stellt der Browser auch beim ersten Besuch schon direkt eine HTTPS-Verbindung her
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

Gemäß der ursprünglichen Auslegung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das Zertifikat anzeigen

Dieser entscheidet nun, ob er dem Zertifikat für diese Sitzung vertraut, es evtl
auch permanent speichert, gegebenenfalls nach Prüfung über die angegebenen Links
Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw. „Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer)

Vorinstallierte Zertifikate

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde mit der Zeit eine Reihe von Root-Zertifikaten von den Browserherstellern 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 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 (Vertrauenswürdigkeit)

Ende 2015 ging Let’s Encrypt online, gegründet u. a. von Mozilla und der Electronic Frontier Foundation

Hier werden kostenlose Zertifikate für jedermann angeboten mit dem Ziel, die Verbreitung von HTTPS insgesamt zu fördern
Für die Installation und laufende Aktualisierung der Zertifikate ist jedoch eine eigene 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

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 StartCom oder 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

Zu Angriffen auf das Zertifikatsystem, siehe unten

Selbst-signiert

Ein Server-Betreiber kann auch selbst-signierte Zertifikate (englisch Vorlage:Lang) 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

Die Lösung dieses Problems kam durch Server Name Indication (SNI), auf Basis von Transport Layer Security 1.2, da hier der vom Browser gewünschte Hostname bereits beim SSL-Handshake übermittelt werden kann

Damit sind die oben genannten anderen Techniken bedeutungslos geworden
Das Verfahren bedarf entsprechend aktueller Software auf Seiten des Servers und des Browsers und wurde von diesen ab 2006 unterstützt

Im Falle des Apache-Servers wird die SNI-Verarbeitung z. B. durch eine nur leicht modifizierte Konfigurations-Anweisung gesteuert:

<VirtualHost _default_:443>

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 das 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
- Teilweise wird, vor allem während der Einführung von HTTPS, auf eine Bewerbung durch einen Link verzichtet
Der Anwender kann nur manuell auf HTTPS umschalten, indem er in der URL selbstständig das „s“ hinter „http“ hinzufügt
Skriptgesteuerte 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['HTTPS']=='on'

Leistung

Beim Verbindungsaufbau legt der Server einen Kryptografiealgorithmus fest

In der Theorie soll sich der Server dabei an den Wünschen des Clients orientieren
Um Rechenzeit zu sparen, werden jedoch auf Servern mit hohem Datenverkehr bevorzugt Strom-Chiffren eingesetzt, da diese weniger rechenintensiv sind als Block-Chiffren wie AES oder Camellia
Viele der dabei lange Zeit genutzten Verfahren wie RC4 gelten als unsicher und werden daher seit 2016 von den großen Webbrowsern nicht mehr unterstützt

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 aufwendige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun
Diese 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

2010 verursachte die Kryptografie beispielsweise bei Gmail weniger als 1 % der Prozessor-Last, weniger als 10 KB Arbeitsspeicherbedarf pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs.10 Jahre vorher belastete der Rechenaufwand der Kryptografie die Server noch stark

Sicherheit

TLS/Sicherheit

Anhang

Siehe auch

Hypertext Transfer Protocol Secure

Links

RFC

RFC	Titel
2818	HTTP Over TLS

Weblinks

Zertifikate

@@ Zeile 200: / Zeile 200: @@
 ----
 * [[md5]]
+* [[sha]]
+* [[:Kategorie:SSL]]
+* [[SSL-Zertifikat/Format]]
+* [[:Kategorie:SSL-Zertifikat]]
 ==== Links ====
@@ Zeile 224: / Zeile 227: @@
 [[Kategorie:HTTP]]
 [[Kategorie:TLS]]
+[[Kategorie:SSL-Zertifikat]]
 </noinclude>