Hypertext Transfer Protocol Secure: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „Kategorie:Web“ durch „Kategorie:Netzwerke:Web“
Keine Bearbeitungszusammenfassung
 
(91 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''Hypertext Transfer Protocol Secure''' (HTTPS) - [[Kommunikationsprotokoll]] zur sicheren Datenübertragung
 
== Beschreibung ==
== Beschreibung ==
== Installation ==
{| class="float wikitable"
== Anwendungen ==
|+ HTTPS im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]
=== Fehlerbehebung ===
== Syntax ==
=== Optionen ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
== Konfiguration ==
=== Dateien ===
== Sicherheit ==
== Dokumentation ==
=== RFC ===
=== Man-Pages ===
=== Info-Pages ===
== Siehe auch ==
== Links ==
=== Projekt-Homepage ===
=== Weblinks ===
=== Einzelnachweise ===
<references />
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
 
[[Kategorie:Entwurf]]
 
= Wikipedia =
{| class="wikitable float-right"
|-
! colspan="2" style="background:#C0C0FF;"| HTTPS (Hypertext Transfer Protocol Secure)
|-
|-
| '''Familie:'''
| '''Familie''' || [[Internetprotokolle]]
| [[Internetprotokollfamilie]]
|-
|-
| '''Einsatzgebiet:'''
| '''Einsatzgebiet''' || verschlüsselte Datenübertragung|
| verschlüsselte Datenübertragung
|-
|-
| '''Port:''' || 443/TCP
| '''Port''' || 443/TCP
|-
|-
|colspan="2" class="center"|
|colspan="2" class="center"|
{{Netzwerk-TCP-IP-Anwendungsprotokoll|HTTP|ssl=1|title=HTTPS}}
{| class="float"
|- style="background:#DDDDFF;"
|style="background:#FFEEBB"| '''Anwendung'''
| [[HTTP/3]]
|colspan="2"| [[DNS over QUIC]]
|colspan="2"| …
|- style="text-align:center"
|style="background:#FFEEBB"| Transport
|colspan="5" style="background:#EEEEFF"| [[User Datagram Protocol|UDP]]
|- style="text-align:center"
|style="background:#FFEEBB"| Internet
|colspan="5" style="background:#EEEEFF"| [[Internet Protocol|IP]] ([[IPv4]], [[IPv6]])
|- style="text-align:center"
|rowspan="2" style="background:#FFEEBB"| Netzzugang
|rowspan="2" style="background:#EEEEEE"| [[Ethernet]]
|rowspan="2" style="background:#EEEEEE"| [[Token Bus|Token<br />Bus]]
|rowspan="2" style="background:#EEEEEE"| [[Token Ring|Token<br />Ring]]
|rowspan="2" style="background:#EEEEEE"| [[Fiber Distributed Data Interface|FDDI]]
|rowspan="2" style="background:#EEEEEE"| …
|}
|-
|-
| '''Standards:'''
| '''Standards''' || RFC 2818 (HTTP Over TLS, 2000)
| RFC 2818 (HTTP Over TLS, 2000)
|}
|}


'''Hypertext Transfer Protocol Secure''' ('''HTTPS''', {{enS}} für „sicheres Hypertext-Übertragungsprotokoll“) ist ein [[Kommunikationsprotokoll]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können.
; Sicheres [[Hypertext]]-[[Übertragungsprotokoll]]
* Es stellt eine ''Transportverschlüsselung'' dar.
* [[Kommunikationsprotokoll]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können
* Technisch definiert wurde es als [[Uniform Resource Identifier#Aufbau|URI-Schema]], eine zusätzliche Schicht zwischen [[Hypertext Transfer Protocol|HTTP]] und [[Transmission Control Protocol|TCP]]
* HTTPS wurde von [[Netscape Communications|Netscape]] entwickelt und zusammen mit [[Transport Layer Security|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht


HTTPS wurde von [[Netscape Communications|Netscape]] entwickelt und zusammen mit [[Transport Layer Security|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht.
== Transportverschlüsselung ==
[[File:2024-03-01_17-49.png|mini|200px]]
[[File:2024-03-01_17-48_1.png|mini|200px]]
[[File:2024-03-01_17-48.png|mini|200px]]
[[File:2024-03-01_17-49_1.png|mini|200px]]
[[File:2024-03-01_17-49_2.png|mini|200px]]
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 [[Kryptografie]] und [[Authentifizierung]] erreicht


Technisch definiert wurde es als [[Uniform Resource Identifier#Aufbau|URI-Schema]], eine zusätzliche Schicht zwischen [[Hypertext Transfer Protocol|HTTP]] und [[Transmission Control Protocol|TCP]].
Ohne Kryptografie sind Daten, die über das Internet übertragen werden, für jeden, der Zugang zum entsprechenden Netz hat, als [[Klartext (Kryptografie)|Klartext]] lesbar
* Mit der zunehmenden Verbreitung von offenen (d.&nbsp;h.&nbsp;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


== Nutzen ==
Die Authentifizierung dient dazu, dass beide Seiten der Verbindung beim Aufbau der Kommunikation die Identität des Verbindungspartners überprüfen können
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.
* Dadurch sollen [[Man-in-the-Middle-Angriff]]e und teilweise auch [[Phishing]] verhindert werden
* 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 (Kryptografie)|Klartext]] lesbar.
* Mit der zunehmenden Verbreitung von offenen (d.&nbsp;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 ==
== 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.
[[File:https.png|mini|400px]]
* 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.
[[Syntax|Syntaktisch]] ist HTTPS identisch mit dem Schema für HTTP
* Dieser wird schließlich zur Verschlüsselung der [[Nutzdaten]] verwendet.
; Die zusätzliche Kryptografie 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
Der Standard-[[Port (Protokoll)|Port]] für HTTPS-Verbindungen ist 443.
* Anschließend wird mit Hilfe [[Asymmetrisches Kryptosystem|asymmetrischer Kryptografie]] oder des [[Diffie-Hellman]]s ein gemeinsamer [[Symmetrisches Kryptosystem|symmetrischer Sitzungsschlüssel]] ausgetauscht
 
* Dieser wird schließlich zur Kryptografie der [[Nutzdaten]] verwendet
Neben den Server-Zertifikaten können auch signierte Client-Zertifikate nach [[X.509]].3 erstellt werden.
* Der Standard-[[Port (Protokoll)|Port]] für HTTPS-Verbindungen ist 443
* Das ermöglicht eine Authentifizierung der Clients gegenüber dem Server, wird jedoch selten eingesetzt.
* Eine ältere Protokollvariante von HTTPS war [[S-HTTP]]


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 ==
== Client-Verarbeitung ==
Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die anwenderseitige Client-Software schon früh in Webbrowser integriert.
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.
* 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
Eine HTTPS-Verbindung wird durch eine https-[[Uniform Resource Locator|URL]] angewählt und durch das SSL-Logo angezeigt.  
[[Datei:SSL Symbol.png]]
* Dies wird bei allen geläufigen Browsern als kleines Schloss-Symbol in der Adresszeile dargestellt.
* Dies wird bei allen geläufigen Browsern als kleines Schloss-Symbol in der Adresszeile dargestellt


=== Varianten der HTTPS-Anwahl ===
=== HTTPS-Anwahl ===
Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:
Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:
* Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei [[Electronic Banking|Online-Banking]]; teils wird dabei eine angewählte http-Adresse automatisch auf https weitergeleitet.
* Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei [[Electronic Banking|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.&nbsp;B.  
* 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.&nbsp;B.&nbsp;bei [[eBay]]
* 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
* 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
* Steht der Server zusätzlich auf der HSTS Preload Liste, stellt der Browser auch beim ersten Besuch schon direkt eine HTTPS-Verbindung her.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>
* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z.&nbsp;B.&nbsp;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
* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z.&nbsp;B.  
* 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
* 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.


Gemäß der ursprünglichen Auslegung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das [[Digitales Zertifikat|Zertifikat]] anzeigen.
Gemäß der ursprünglichen Auslegung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das [[Digitales Zertifikat|Zertifikat]] anzeigen
* Dieser entscheidet nun, ob er dem Zertifikat für diese Sitzung vertraut, es evtl.
* 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.
* 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).
* Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw.&nbsp;„Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer)


=== Vorinstallierte Zertifikate ===
=== 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.
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.
* 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.
* 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#Version 7|Internet Explorer&nbsp;7]] hat Microsoft, kurz danach auch Mozilla mit dem [[Mozilla Firefox|Firefox&nbsp;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.
Mit dem [[Internet Explorer#Version 7|Internet Explorer&nbsp;7]] hat Microsoft, kurz danach auch Mozilla mit dem [[Mozilla Firefox|Firefox&nbsp;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“.
* 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.
* 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|CAcert (Vertrauenswürdigkeit)]].
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|CAcert (Vertrauenswürdigkeit)]]


Ende 2015 ging [[Let’s Encrypt]] online, gegründet u.&nbsp;a. von [[Mozilla]] und der [[Electronic Frontier Foundation]].
Ende 2015 ging [[Let’s Encrypt]] online, gegründet u.&nbsp;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.
* 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.
* Für die Installation und laufende Aktualisierung der Zertifikate ist jedoch eine eigene Software auf dem Server notwendig


== Server-Betrieb ==
== Server-Betrieb ==
Als Software zum Betrieb eines HTTPS-fähigen [[Webserver]]s wird eine SSL-Bibliothek wie [[OpenSSL]] benötigt.
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.
* Diese wird häufig bereits mitgeliefert oder kann als Modul installiert werden
* Der HTTPS-Service wird üblicherweise auf [[Port (Protokoll)|Port]] 443 bereitgestellt.
* Der HTTPS-Service wird üblicherweise auf [[Port (Protokoll)|Port]] 443 bereitgestellt


=== Zertifikat ===
=== 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 –&nbsp;selbst wiederum zertifizierten&nbsp;– [[Zertifizierungsstelle]] (CA von {{enS|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)|Domain]] eindeutig identifiziert.
Das [[Digitales Zertifikat|digitale Zertifikat]] für [[Secure Sockets Layer|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen
* Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.
* Ein Binärdokument, das im Allgemeinen von einer –&nbsp;selbst wiederum zertifizierten&nbsp;– [[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&nbsp;€ pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind.
In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600&nbsp;€ pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind
* Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus.
* Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus
* Die etwa von <!--[[StartCom]]<ref>{{Internetquelle |url=https://www.heise.de/security/meldung/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten-129472.html |titel=Mozilla vertraut kostenlosen StartCom Zertifikaten |hrsg=Heise-Online |datum=2006-06-03 |zugriff=2010-03-04}}<br />Vgl.
* Die etwa von [[StartCom]] oder [[Let’s Encrypt]] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert
* dazu auch ''[[:en:Comparison of SSL certificates for web servers|Comparison of SSL certificates for web servers]]'' in der englischsprachigen Wikipedia.</ref> 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 [[#Vorinstallierte Zertifikate|oben]]
* Ebenfalls kostenlose Zertifikate erstellt [[CAcert]], wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe [[#Vorinstallierte Zertifikate|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
* 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.
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.
* 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.
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
* Juli 2017.</ref>


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


==== Selbst-signiert ====
==== Selbst-signiert ====
Ein Server-Betreiber kann auch selbst-signierte Zertifikate (englisch {{lang|en|''self-signed certificate''}}) kostenlos erstellen, ohne Beteiligung einer dritten Instanz.
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').
* Diese müssen vom Browser-Anwender manuell bestätigt werden ('Ausnahme hinzufügen')
* In diesem Fall garantiert kein Dritter die Authentizität des Anbieters.
* 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.
* 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 ====
==== Extended-Validation-Zertifikat ====
{{Hauptartikel|Extended-Validation-Zertifikat}}
[[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.
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.
* 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.
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.
* Damit sind auch deutlich höhere Kosten verbunden


=== IP-Adressen bei mehreren Domains ===
=== IP-Adressen bei mehreren Domains ===
Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene [[IP-Adresse]] pro [[Hostname]] notwendig.
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.
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]].
* 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.
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.
* 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-Server|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“.
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.
* 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.
* Andere Provider nutzten einen „SSL [[Proxy-Server|Proxy]]“, der die Anfragen über eine von mehreren Kunden genutzte Domain leitete


Die Lösung dieses Problems kam durch [[Server Name Indication]] (SNI),<ref>[https://tools.ietf.org/html/rfc3546#section-3.1 Internet Engineering Task Force: RFC 3546], Juni 2003, abgerufen 10.
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
* März 2017.</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
* 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
* 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.&nbsp;B.  
Im Falle des [[Apache HTTP Server|Apache-Servers]] wird die SNI-Verarbeitung z.&nbsp;B.&nbsp;durch eine nur leicht modifizierte Konfigurations-Anweisung gesteuert:
* 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.
<code><VirtualHost _default_:443></code>
* Oktober 2012, abgerufen 9.
* März 2017.</ref><ref>[http://nickgeoghegan.net/linux/enabling-server-name-includes-on-debian-squeeze nickgeoghegan.net: Enabling Server Name Includes on Debian Squeeze], abgerufen am 23.
* Juli 2017.</ref><br /><code><VirtualHost _default_:443></code>


=== Einbindung ===
=== Einbindung ===
Zeile 202: Zeile 169:
* Wenn ausschließlich HTTPS zulässig ist, kann das umgesetzt werden durch:
* 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
** 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]].
** 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]].
* 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.
* 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.
** 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.
* 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.
* 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>
* 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.&nbsp;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] bei www.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 ===
=== Leistung ===
Beim Verbindungsaufbau legt der Server einen Verschlüsselungsalgorithmus fest.
Beim Verbindungsaufbau legt der Server einen Kryptografiealgorithmus fest
* In der Theorie soll sich der Server dabei an den Wünschen des Clients orientieren.
* 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 [[Stromverschlüsselung|Strom-Chiffren]] eingesetzt, da diese weniger rechenintensiv sind als [[Blockverschlüsselung|Block-Chiffren]] wie [[Advanced Encryption Standard|AES]] oder [[Camellia (Algorithmus)|Camellia]].
* Um Rechenzeit zu sparen, werden jedoch auf Servern mit hohem [[Datenverkehr]] bevorzugt [[Stromverschlüsselung|Strom-Chiffren]] eingesetzt, da diese weniger rechenintensiv sind als [[Blockverschlüsselung|Block-Chiffren]] wie [[Advanced Encryption Standard|AES]] oder [[Camellia (Algorithmus)|Camellia]]
* Viele der dabei lange Zeit genutzten Verfahren wie [[RC4]] gelten als unsicher und werden daher 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.
* Viele der dabei lange Zeit genutzten Verfahren wie [[RC4]] gelten als unsicher und werden daher seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt
* September 2015.</ref>


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.
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.
* 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]].
* 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.
* 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
* Dezember 2006.</ref>


2010 verursachte die Verschlüsselung beispielsweise bei [[Gmail]] weniger als 1 % der [[Prozessor]]-Last, weniger als 10&nbsp;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.
2010 verursachte die Kryptografie beispielsweise bei [[Gmail]] weniger als 1 % der [[Prozessor]]-Last, weniger als 10&nbsp;KB [[Arbeitsspeicher]]bedarf pro Verbindung und weniger als 2 % des Netzwerk-[[Datenverkehr]]s.10&nbsp;Jahre vorher belastete der Rechenaufwand der Kryptografie die Server noch stark
* Adam Langley’s Weblog |datum=2010-06-25 |sprache=en |abruf=2014-10-23}}</ref> 10&nbsp;Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.<ref name="overclocking-ssl" />


== Angriffe und Schwachstellen ==
== Sicherheit ==
Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL-gesicherte Verbindungen gehäuft.
[[TLS/Sicherheit]]
* 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 ===
<noinclude>
Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig überprüft und gelten als mathematisch sicher, d.&nbsp;h., sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen.
* Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter [[Verschlüsselung|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 Verschlüsselung.
== Anhang ==
* Insbesondere Schwachstellen in der weit verbreiten [[OpenSSL]]-Bibliothek wie [[Heartbleed]] haben dabei große öffentliche Aufmerksamkeit erfahren.
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
* [[md5]]
* [[sha]]
* [[:Kategorie:SSL]]
* [[SSL-Zertifikat/Format]]
* [[:Kategorie:SSL-Zertifikat]]
==== Links ====


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>
=== RFC ===
 
{| class="wikitable sortable options big"
Speziell zur Abwehr von Downgrade-Attacken 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.&nbsp;a.
! RFC !! Titel
* http- in https-URLs umgewandelt werden.
|-
 
| [https://www.rfc-editor.org/info/rfc2818 2818] || HTTP Over TLS
=== 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''] auf 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 –&nbsp;einem Cluster aus 200 Playstation-3-Spielkonsolen&nbsp;– 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''.] Auf 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 2818 – HTTP Over TLS (englisch)


== Weblinks ==
===== Weblinks =====
* [https://www.softed.de/blog/wie-funktioniert-https/ Wie funktioniert HTTPS?]
# https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure
* [https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html Apache.org: SSL intro]
# https://www.instagram.com/codewithbrij
# https://www.softed.de/blog/wie-funktioniert-https
# https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html


== Einzelnachweise ==
=== Zertifikate ===
<references responsive />
[[Datei:Https Certificate Warning.png|alternativtext=Https Certificate Warning|mini|400px|Https Certificate Warning]]
[[File:httpsCertificateWarningDetails.png|alternativtext=Https Certificate Warning Details|mini|400px|Https Certificate Warning Details]]
[[File:httpsCertificateView.png|alternativtext=Https Certificate View|mini|400px|Https Certificate View]]


[[Kategorie:HTTP]]
[[Kategorie:HTTP]]
[[Kategorie:Verschlüsselung]]
[[Kategorie:TLS]]
[[Kategorie:Netzwerke:Web:Protokolle]]
[[Kategorie:SSL-Zertifikat]]
 
 
 
[[Datei:Https Certificate Warning.png|alternativtext=Https Certificate Warning|mini|Https Certificate Warning]]
 
[[File:httpsCertificateWarningDetails.png|alternativtext=Https Certificate Warning Details|mini|Https Certificate Warning Details]]


[[File:httpsCertificateView.png|alternativtext=Https Certificate View|mini|Https Certificate View]]
</noinclude>

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

Transportverschlüsselung

HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet

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

Technik

Syntaktisch ist HTTPS identisch mit dem Schema für HTTP

Die zusätzliche Kryptografie der Daten geschieht mittels SSL/TLS
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

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

Links

RFC

RFC Titel
2818 HTTP Over TLS
Weblinks
  1. https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure
  2. https://www.instagram.com/codewithbrij
  3. https://www.softed.de/blog/wie-funktioniert-https
  4. https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html

Zertifikate

Https Certificate Warning
Https Certificate Warning
Https Certificate Warning Details
Https Certificate Warning Details
Https Certificate View
Https Certificate View


Abgerufen von „https://wiki.foxtom.de/index.php?title=Hypertext_Transfer_Protocol_Secure&oldid=113638“