imported>InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

2025-07-12T06:59:20Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

Neue Seite

{| class="wikitable float-right"
|+ style="background:#C0C0FF"| Hypertext Transfer Protocol Secure
|-
| '''Familie:'''
| [[Internetprotokollfamilie]]
|-
| '''Einsatzgebiet:'''
| verschlüsselte Datenübertragung
|-
| '''Port:''' || 443/TCP
|-
|colspan="2" class="center"|
{{Netzwerk-TCP-IP-Anwendungsprotokoll|HTTP|ssl=1|title=HTTPS}}
|-
| '''Standards:'''
| <nowiki>RFC 9110</nowiki> (HTTP Semantics, 2022)<ref name="rfc9110">{{RFC-Internet |RFC=9110 |Titel=HTTP Semantics |Datum=2022}}</ref>
|}

'''Hypertext Transfer Protocol Secure''' ('''HTTPS;''' {{enS}} 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 [[Transport Layer Security|TLS]] auf, das eine zusätzliche Kommunikationsschicht zwischen [[Hypertext Transfer Protocol|HTTP]] und [[Transmission Control Protocol|TCP]] darstellt. Eine HTTPS-Adresse wird über das [[Uniform Resource Identifier#Aufbau|URI-Schema]] „https“ identifiziert.<ref name="rfc9110" />

HTTPS wurde von [[Netscape Communications|Netscape]] entwickelt und zusammen mit [[Transport Layer Security|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als [[Request for Comments]] <nowiki>RFC 2818</nowiki> veröffentlicht.<ref name="rfc2818">{{RFC-Internet |RFC=2818 |Titel=HTTP Over TLS |Datum=2000}}</ref> Diese wurde im Jahr 2022 durch den [[Internetstandard]] <nowiki>RFC 9110</nowiki> abgelöst.<ref name="rfc9110"/>

== Nutzen ==
[[Datei:HTTPS icon.png|mini|Schloss als Icon der [[Webbrowser#Adressleiste|Adressleiste]]]]
HTTPS wird zur Herstellung von [[Vertraulichkeit]] und [[Integrität (Informationssicherheit)|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 (Kryptographie)|Klartext]] lesbar. Mit der zunehmenden Verbreitung von offenen (d. h. unverschlüsselten) [[Wireless Local Area Network|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-Angriff]]e und teilweise auch [[Phishing]] verhindert werden.

== Technik ==
[[Syntax|Syntaktisch]] ist HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels [[Transport Layer Security|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 [[Asymmetrisches Kryptosystem|asymmetrischer Verschlüsselung]] oder des [[Diffie-Hellman-Schlüsselaustausch]]s ein gemeinsamer [[Symmetrisches Kryptosystem|symmetrischer Sitzungsschlüssel]] ausgetauscht. Dieser wird schließlich zur Verschlüsselung der [[Nutzdaten]] verwendet.

Der Standard-[[Port (Netzwerkadresse)|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.

[[Datei:SSL Symbol.png|rechts|gerahmt]]
Eine HTTPS-Verbindung wird durch eine https-[[Uniform Resource Locator|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.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>
* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z. B. für [[Mozilla Firefox|Firefox]] und [[Google Chrome|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.<ref>{{Internetquelle |url=https://support.mozilla.org/en-US/kb/https-only-prefs |titel=HTTPS-Only Mode in Firefox |werk=support.mozilla.org |sprache=en |abruf=2021-06-18}}</ref> 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 [[Zertifizierungsstelle (Digitale Zertifikate)|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 [[Softwareaktualisierung]]en auf den neuesten Stand gebracht.

Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des [[CA/Browser Forum]]s. 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|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 [[Webserver]]s 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 (Netzwerkadresse)|Port]] 443 bereitgestellt.

=== Zertifikat ===
Das [[Digitales Zertifikat|digitale Zertifikat]] für [[Secure Sockets Layer|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – [[Zertifizierungsstelle (Digitale Zertifikate)|Zertifizierungsstelle]] (CA von {{enS|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)|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 [[#Vertrauensanker|oben]]. Ein solches Zertifikat muss daher bei der [[#Client-Verarbeitung|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 [[Zertifikatsperrliste]]n ({{enS|certificate revocation list}}, ''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.<ref>[https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html#ocspstapling apache.org: Apache 2.5 OCSP Stapling], abgerufen am 23. Juli 2017.</ref>

Zu Angriffen auf das Zertifikatsystem, siehe [[#Zertifikatsystem|unten]].

==== Selbst-signiert ====
Ein Server-Betreiber kann auch selbst-signierte Zertifikate (englisch {{lang|en|''self-signed certificate''}}) 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 ====
{{Hauptartikel|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.<ref>[https://web.archive.org/web/20070202031218/http://www.cabforum.org/forum.html web.archive.org]</ref> 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 [[Hypertext Transfer Protocol#Aufbau|HTTP-Header]] mitsenden, können mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden, zum Beispiel bei [[Apache HTTP Server|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 [[Hosting|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 [[Socket (Software)#Internet-Sockets|IP/Port-Kombination]] möglich; ein anderer Port als 443 wird wiederum von vielen [[Proxy (Rechnernetz)|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 (Internet)|Domain]] gültig sind, in Verbindung mit kundenspezifischen Subdomains. Andere Provider nutzten einen „SSL [[Proxy (Rechnernetz)|Proxy]]“, der die Anfragen über eine von mehreren Kunden genutzte Domain leitete.

Die Lösung dieses Problems kam durch [[Server Name Indication]] (SNI),<ref>{{RFC-Internet |RFC=3546 |Titel=Transport Layer Security (TLS) Extensions |Datum=2003-06 |Abschnitt=3.1 |Abschnittstitel=Server Name Indication}}</ref> 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 HTTP Server|Apache-Servers]] wird die SNI-Verarbeitung z. B. durch eine nur leicht modifizierte Konfigurations-Anweisung gesteuert:<ref>[https://www.digitalocean.com/community/tutorials/how-to-set-up-multiple-ssl-certificates-on-one-ip-with-apache-on-ubuntu-12-04 digitalocean.com: How To Set Up Multiple SSL Certificates on One IP with Apache on Ubuntu 12.04], 19. Oktober 2012, abgerufen am 9. März 2017.</ref><ref>{{Webarchiv|url=http://nickgeoghegan.net/linux/enabling-server-name-includes-on-debian-squeeze |wayback=20170819144503 |text=nickgeoghegan.net: Enabling Server Name Includes on Debian Squeeze |archiv-bot=2025-07-12 06:59:20 InternetArchiveBot }}, abgerufen am 23. Juli 2017.</ref><br /><code><VirtualHost _default_:443></code>

=== Einbindung ===
Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten [[#Varianten der HTTPS-Anwahl|Varianten der HTTPS-Anwahl]]:
* Wenn ausschließlich HTTPS zulässig ist, kann das umgesetzt werden durch:
** Weiterleitung ([[Meta-Tag#refresh - Weiterleitung|HTML-refresh]]) oder auch ein [[Rewrite-Engine|rewrite]] der URL
** Konfiguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung <code>SSLRequireSSL</code> in der [[.htaccess]]. Wird eine solche Seite per HTTP aufgerufen, erzeugt der Server einen '403 – Forbidden' [[HTTP-Statuscode|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: <code>$_SERVER['HTTPS']=='on'</code>

=== Umstellung ===
Mit zunehmender CPU-Leistung sowie Sicherheitsbewusstsein tritt regelmäßig die Anforderung auf, eine bisher auf HTTP basierende Website auf HTTPS umzustellen. Im Falle der Website [[Stack Overflow (Website)|Stack Overflow]] mit einer Vielzahl von Usern und Services zieht sich dieser Prozess über einige Jahre hin<ref>[https://meta.stackexchange.com/questions/292058/network-wide-https-its-time?cb=1 meta.stackexchange.com: Network-wide HTTPS: It’s time], abgerufen am 9. März 2017.</ref> und ist Stand März 2017 nicht abgeschlossen. Dabei wurden u. a. folgende Themen bearbeitet:<ref>[https://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/ nickcraver.com: Stackoverflow.com: the road to SSL], abgerufen am 9. März 2017.</ref>
* Vermeidung von Einbindungen von unverschlüsselten Daten (Mediadaten, Stylesheets etc.) in eine verschlüsselte Seite (sogenannter ''Mixed Content''<ref>[https://www.w3.org/TR/mixed-content/ Beschreibung von Mixed Content.] w3.org</ref>). Andernfalls werden Browserwarnungen wie 'Part of this page is not secure' ausgegeben oder Daten nicht geladen.
* Gesamte Infrastruktur ist auf SSL umzustellen, darunter [[Loadbalancer]] und Proxies
* Organisation der Zertifikate, ggf. für eine Vielzahl von Subdomains
* Umstellung von Code der eigenen [[Webanwendung]], worin HTTP hart codiert ist
* Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet
* Qualitätsprüfung
* Umsetzung laufender Sessions, ohne deren Inhalte zu verlieren (24/7 Betrieb)

=== Leistung ===
Beim Verbindungsaufbau handeln Client und Server im [[Transport Layer Security#TLS Handshake Protocol|TLS-Handshake]] einen Verschlüsselungsalgorithmus aus. Hierbei besteht ein Zielkonflikt zwischen möglichst sicheren und performanten Algorithmen. Dies gilt insbesondere für den Server, da dieser für gewöhnlich mehrere Clients gleichzeitig bedient und somit einen höheren [[Datenverkehr]] als der Client verarbeitet. Früher übliche Verfahren wie die [[Blockverschlüsselung|Blockchiffre]] [[Data Encryption Standard|DES]] und die [[Stromverschlüsselung|Stromchiffre]] [[RC4]] bieten eine gute Leistung, gelten heute jedoch nicht mehr als hinreichend sicher. RC4 wird seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt.<ref>Emil Protalinski: [https://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/ Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year], VentureBeat, 1. September 2015.</ref>

Zur Erhöhung der Server-Performance wird auch Hardware-Beschleunigung eingesetzt. Eine Möglichkeit ist der Einsatz von [[Peripheral Component Interconnect|PCI-Steckkarten]] mit speziellen, optimierten Prozessoren, die aus der TLS-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 Microsystems|Sun]]. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und [[Mehrkernprozessor|Multi-Core]]-Systeme der großen CPU-Hersteller Intel und AMD.<ref name="anant_ssl">[http://www.anandtech.com/show/2143/6 ''Quad Core Intel Xeon SSL Performance''] auf anandtech.com, 27. Dezember 2006.</ref> Moderne Prozessoren enthalten mit [[AES-NI]] eine Hardware-Beschleunigung für den [[Advanced Encryption Standard|AES-Verschlüsselungsalgorithmus]], der einen Teil der für HTTPS notwendigen Rechenoperationen ausmacht.

2010 verursachte die Verschlüsselung beispielsweise bei [[Gmail]] weniger als 1 % der [[Prozessor]]-Last, weniger als 10 KB [[Arbeitsspeicher]]bedarf pro Verbindung und weniger als 2 % des Netzwerk-[[Datenverkehr]]s.<ref name="overclocking-ssl">{{Internetquelle |autor=Adam Langley, Nagendra Modadugu, Wan-Teh Chang |url=https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html |titel=Overclocking SSL |werk=ImperialViolet. Adam Langley’s Weblog |datum=2010-06-25 |sprache=en |abruf=2014-10-23}}</ref> 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.<ref name="overclocking-ssl" />

== 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. 2013 wurde im Zusammenhang mit der [[Globale Überwachungs- und Spionageaffäre|globalen Überwachungs- und Spionageaffäre]] bekannt, dass die [[National Security Agency|NSA]] beide Angriffskanäle nutzte, um Zugang zu verschlüsselten Verbindungen zu erlangen.

=== 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 theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter [[Kryptologie|Kryptologen]] überprüft. Regelmäßig werden in den Spezifikationen und den Implementierungen die Unterstützung veralteter Verschlüsselungsverfahren, die nach dem aktuellen Stand der Technik als nicht mehr sicher gelten, gestrichen und neue Verfahren aufgenommen.<ref>Beispielhaft: {{Internetquelle |autor=Daniel Berger |url=https://www.heise.de/newsticker/meldung/Firefox-39-entfernt-SSLv3-und-RC4-2734444.html |titel=Firefox 39 entfernt SSLv3 und RC4 |werk=[[Heise online]] |datum=2015-07-03 |abruf=2015-10-22}}<br /> {{Internetquelle |autor=Daniel Berger |url=https://www.heise.de/newsticker/meldung/Firefox-27-verschluesselt-mit-TLS-1-2-2105377.html |titel=Firefox 27 verschlüsselt mit TLS 1.2 |werk=[[Heise online]] |datum=2014-02-04 |abruf=2015-10-22}}</ref>

Probleme entstanden in der Vergangenheit mehrfach durch fehlerhafte Implementierung der Kryptologie. Insbesondere Schwachstellen in der weit verbreiten [[OpenSSL]]-Bibliothek wie [[Heartbleed]] haben dabei große öffentliche Aufmerksamkeit erfahren.

Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (''<nowiki>https://</nowiki>'') beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen [[Man-in-the-Middle-Angriff]] ausführen.<ref>{{Internetquelle |autor=Daniel Bachfeld |url=https://www.heise.de/security/meldung/Black-Hat-Neue-Angriffsmethoden-auf-SSL-vorgestellt-198285.html |titel=Black Hat: Neue Angriffsmethoden auf SSL vorgestellt |werk=[[Heise online]] Security |datum=2009-02-19 |abruf=2015-10-25}}</ref>

Speziell zur Abwehr von [[Downgrade-Angriff]]en gegen die Verschlüsselung sowie von [[Session Hijacking]] wurde 2012 das Verfahren [[HTTP Strict Transport Security]] oder HSTS vorgestellt. Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a. http- in https-URLs umgewandelt werden.

=== Zertifikatsystem ===
SSL-Verbindungen sind grundsätzlich gefährdet durch [[Man-in-the-Middle-Angriff]]e, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt, indem dieser sich beispielsweise als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass sich der Angreifer im Netzwerk des Opfers befindet. Beim [[DNS-Spoofing]] wiederum bestehen diese Voraussetzungen nicht.

Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen. Das ist ihm beispielsweise dann möglich, wenn es ihm gelingt, in das System einer Zertifizierungsstelle einzudringen, oder er anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen. Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbehörden, können solche Möglichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren.<ref>[https://www.heise.de/security/meldung/EFF-zweifelt-an-Abhoersicherheit-von-SSL-963857.html ''EFF zweifelt an Abhörsicherheit von SSL.''] heise security; abgerufen am 28. Juni 2013.</ref> [[HTTP Public Key Pinning]] und [[Certificate Transparency]] sollen solche Angriffe erschweren.

==== Phishing und HTTPS ====
Ein Nachteil der automatischen Bestätigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt. Das 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 [[Persönliche Identifikationsnummer|PIN]]/[[Transaktionsnummer|TAN]]-Codes „abzufischen“. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-[[Uniform Resource Locator|URLs]] nur manuell oder per [[Lesezeichen (World Wide Web)|Lesezeichen]] einzugeben.

Wegen der teils oberflächlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browserherstellern das ''extended-validation-Cert'' eingeführt, siehe [[#Extended-Validation-Zertifikat|oben]].

===== Gemischte Inhalte =====
Das Nachladen unverschlüsselter Ressourcen ermöglicht einem Angreifer, mittels eines [[Man-in-the-Middle-Angriff]]s Schadcode in die ursprünglich verschlüsselt übertragene Webseite einzuschleusen. Daher blockieren aktuelle Versionen gängiger Webbrowser das Nachladen unverschlüsselter Ressourcen standardmäßig. Ebenso besteht bei einem sowohl für verschlüsselte als auch unverschlüsselte Verbindungen genutzten [[HTTP-Cookie]] das Risiko eines [[Session Hijacking]], auch wenn die [[Authentifizierung]] über eine verschlüsselte Verbindung erfolgte.

==== Schwachstelle MD5 ====
Auf dem 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 [[Message-Digest Algorithm 5|MD5]]-Algorithmus eine [[Hashtabelle#Kollisionen|Kollision]] zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen könnte.<ref>[https://www.heise.de/security/meldung/25C3-Erfolgreicher-Angriff-auf-das-SSL-Zertifikatsystem-192869.html ''25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem.''] heise.de, 30. Dezember 2008; abgerufen am 3. Januar 2013.</ref> Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten; bei [[#Extended-Validation-Zertifikat|EV-Zertifikaten]] kann er ohnehin nicht verwendet werden. Die meisten Webbrowser akzeptieren schon seit 2011 keine MD5-Zertifikate mehr.<ref>[https://support.apple.com/en-us/HT202349 Apple IOS5], [https://wiki.mozilla.org/CA:MD5and1024 Firefox 16], [http://www.computerworld.com/article/2483686/security0/microsoft-moves-to-block-md5-certificates-and-improve-rdp-authentication.html Microsoft Internet Explorer].</ref> Um ähnliche Probleme zu vermeiden, kündigten die Browser-Hersteller darauf an, auch [[SHA1]]-Zertifikate nur noch eine beschränkte Zeit zu unterstützen.<ref>Ivan Ristic: [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know SHA1 Deprecation: What You Need to Know].</ref>

== Spezifikationen ==
* {{RFC-Internet |RFC=2818 |Titel=HTTP Over TLS |Datum=2000}}
* {{RFC-Internet |RFC=9110 |Titel=HTTP Semantics |Datum=2022}}

== Weblinks ==
* [https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html ''SSL intro.''] Apache.org

== Einzelnachweise ==
<references responsive />

[[Kategorie:HTTP]]
[[Kategorie:Verschlüsselungsprotokoll]]
[[Kategorie:Internet-Anwendungsprotokoll]]
[[Kategorie:Kryptologischer Standard]]
[[Kategorie:Internetstandard]]

Hypertext Transfer Protocol Secure - Versionsgeschichte

imported>InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5