Grundlagen/HTTPS und TLS

Aus SELFHTML-Wiki
< Grundlagen(Weitergeleitet von HTTPS)
Wechseln zu: Navigation, Suche

HTTPS (HyperText Transfer Protocol Secure) ist ein Protokoll zur abhörsicheren Übertragung von Dokumenten im WWW. Technisch definiert es als URI-Schema eine zusätzliche Schicht zwischen HTTP und TCP. HTTPS wurde 1994 von Netscape zusammen mit SSL 1.0 entwickelt.

Nutzen[Bearbeiten]

Bei einer normalen HTTP-Verbindung können alle Daten, die in beide Richtungen (Anfrage vom User-Agent, Antwort vom Webserver) übertragen werden, von einem Angreifer gelesen oder geändert werden (sog. Man-in-the-Middle-Angriff). Dieser Angreifer müsste dazu an einer Stelle sitzen, an der die Daten vorbeikommen, z. B. ein WLAN-Router[1], Switch im Netzwerk, beim Provider des Anfragenden oder des Webservers oder irgendwo dazwischen. Weiterhin kann ein User-Agent nicht sehen, woher die Antwort kam, also: Ist das tatsächlich der Webserver meiner Bank mit dem ich hier rede oder ist das jemand der meine Zugangsdaten stehlen will?

HTTPS versucht, diese beiden Probleme zu lösen, indem die HTTP-Daten verschlüsselt werden und die Authentizität der Antwort über Zertifikate sicher gestellt wird.

Im Allgemeinen gibt es heutzutage keinen guten Grund mehr dazu, Kommunikation zwischen verschiedenen Computern nicht zu verschlüsseln; die zusätzliche Last auf Prozessor bzw. Speicher der betroffenen Computer fällt kaum mehr ins Gewicht[2], man kann nicht aus Versehen unverschlüsselte Daten übertragen (z. B. weil man entgegen der üblichen Sicherheitshinweise das eigene Bankpasswort auch auf einer unverschlüsselten Webseite nutzt) und man kann vielleicht sogar andere Menschen schützen, deren verschlüsselte Verbindungen so vielleicht im Rauschen untergehen (siehe z. B. Bruce Schneier: Warum wir verschlüsseln)[3]. Außerdem wird Zensur dadurch erschwert und die Privatsphäre dadurch geschützt, dass für Dritte nur noch die Domain, aber nicht die komplette URL, sichtbar ist – Zensurbehörden können ganze Webpräsenzen sperren, aber nicht mehr einzelne Seiten[4].

Dass verschlüsselte Übertragung wichtig ist, haben auch Mozilla und Google erkannt und erlauben die zweite Version des HTTP-Protokolls, HTTP/2, nur über verschlüsselte Verbindungen[5]. Des Weiteren will Mozilla bestimmte neue Features nur für Webseiten zugänglich machen, die per HTTPS erreichbar sind[6].

Zusammengefasst dient die verschlüsselte Übertragung mittels HTTPS folgenden Zwecken:

  1. Vertraulichkeit: Kein Dritter soll die Daten mitlesen können.
  2. Integrität: Die Daten können während der Übertragung nicht unbemerkt verändert werden
  3. Authentizität: Der Kommunikationspartner ist verifizierbar – dafür braucht man die Zertifikate, die auf die Domain ausgestellt sind

Technik[Bearbeiten]

SSL oder TLS?[Bearbeiten]

Die verwendete Technik im Falle von HTTPS (und auch an diversen anderen Stellen, z. B. SMTPS, IMAPS, SSH) heißt heutzutage TLS (Transport Layer Security). TLS ist eine Weiterentwicklung des ebenfalls immer noch genutzten Protokolls SSL (Secure Sockets Layer). SSL war eine Entwicklung der Firma Netscape und die erste öffentlich genutzte (1995) Version war 2.0[7] und wurde schnell (1996) durch Version 3.0 abgelöst (ebenfalls wegen Sicherheitslücken im Protokolldesign). Im Jahre 1999 wurde dann die nicht kompatible Weiterentwicklung TLS in Version 1.0 veröffentlicht, die inzwischen zwei weitere Updates 1.1 in 2006 und 1.2 in 2009 erhalten hat.

Aufgrund von möglichen Angriffen auf SSL 3.0[8] sollte heutzutage eigentlich ausschließlich TLS verwendet werden und sehr häufig ist eigentlich TLS gemeint, wenn der Begriff SSL genutzt wird.


Zertifikate[Bearbeiten]

Um festzustellen, ob der Server mit dem man sich verbindet, tatsächlich der korrekte Ansprechpartner ist, werden bei Verbindungen über TLS Serverzertifikate verwendet um den Server zu authentifizieren (auch eine Clientauthentifizierung via Clientzertifikaten ist möglich, dies wird bei HTTP allerdings selten verwendet). Diese Zertifikate nutzen asynchrone Verschlüsselungstechniken bei denen der Schlüssel (key) zum Verschlüsseln ein anderer ist als der zum Entschlüsseln (sogenannte Public-key Cryptography) und enthalten weiterhin den (oder die) Namen für die sie gültig sind, einen Gültigkeitszeitraum und üblicherweise Signaturen von anderen Zertifikatsbesitzern.

Der User-Agent erhält nun also beim Aufbau der Verbindung das Zertifikat vom Server und kann überprüfen, ob der im Zertifikat genannte Name dem des Servers, mit dem er sich verbinden wollte, entspricht und ob der Server dazu in der Lage ist Texte zu verschlüsseln, die mit dem im Zertifikat enthaltenen Schlüssel entschlüsselt werden können. Zu diesem Zeitpunkt könnte allerdings immer noch jeder einen Server betreiben, der sich für einen anderen ausgibt, indem ein zum gewünschten Servernamen passendes Zertifikat erzeugt wird (sogenannte self-signed certificate). Um das zu verhindern gibt es die bereits genannten Signaturen in den Zertifikaten, damit kann ein Dritter die Identität des Zertifikatsbesitzers bestätigen. Und an dieser Stelle setzt dann im Prinzip ein nicht aufhören wollendes Nachfragen ein — Woher weiß ich, ob die Signatur tatsächlich echt ist? — die den vermutlich problematischsten Punkt am TLS-Verfahren kennzeichnet. Um dieses Henne/Ei-Problem zu lösen, werden User-Agents im Allgemeinen mit einer Liste an vertrauten Zertifikaten (von Zertifizierungsstellen bzw. Certificate Authorities (CA)) ausgeliefert und wenn die Signaturkette an einem dieser Zertifikate endet, wird auch dem vom Server mitgeschickten Zertifikat vertraut.


Certificate Authorities[Bearbeiten]

Certificate Authorities werden diejenigen Organisationen genannt, die Zertifikate besitzen, denen User Agents (blind) vertrauen und die es häufig (darunter sind aber auch z. B. Universitäten und Regierungsorganisationen) als Dienstleistung anbieten, Zertifikate anderer zu unterschreiben, nachdem deren Identität überprüft wurde. Dieser Prüfprozess ist häufig automatisiert, zum Teil leider fehlerbehaftet (siehe z. B. en.wikipedia.org: Certificate authority) und die Anzahl direkt oder indirekt integrierter Zertifikate ist bei den meisten Browsern unübersichtlich groß[9]. Diese Dienstleistung muss allerdings nicht kostenpflichtig sein, einige CAs bieten kostenlose Zertifikate an:

Das Besondere an Let's Encrypt ist, dass die Zertifikate nur eine Laufzeit von 90 Tagen (geplant sind 30 Tage) haben, dafür aber vollautomatisch aktualisiert werden. Vor allem einige kleinere Webhoster haben die Client-Software von Let's Encrypt bereits in ihre Software integriert.[10] Auf dem eigenen Server hat man die Wahl zwischen dem offiziellen Client von Let's Encrypt oder einer der Dritt-Clients.

Früher gehörten zu dieser Reihe auch StartSSL und wosign, allerdings sind diese aufgrund von Verstößen gegen die Richtlinien von den meisten Browsern aus den Listen mit vertrauten Zertifikaten verbannt worden[11].

kompromittierte Zertifikate[Bearbeiten]

Ein weiteres Problem ist ein kompromittiertes Zertifikat, d. h. ein Zertifikat dessen privater Schlüssel jemandem in die Hände gefallen ist, der diesen nicht haben sollte; die dafür vorgesehenen Techniken sind certification revocation lists und OCSP.

Weil diese Mechanismen allerdings in der Praxis nicht zuverlässig funktionieren, setzt beispielsweise Let's Encrypt auf Zertifikate mit kurzer Laufzeit, da diese im Fall einer Kompromittierung nicht so viel Schaden anrichten können wie welche mit längerer Laufzeit.

Erstellung von Zertifikaten[Bearbeiten]

Das für die Authentifizierung benötigte Zertifikat können Sie von einer Zertifizierungsstelle (CA) erwerben oder auch unter sebst erstellen. Dafür können Sie mit OpenSSL erst einen RSA-Schlüssel und dann ein Certificate Signing Request erzeugen. [12][13]

Ein Certificate Signing Request (engl. für „Zertifikatsregistrierungsanforderung“) ist eine Datei, die sowohl ihren öffentlichen Schlüssel zu ihrem privaten key und weitere Antragsdaten enthält. Diese Anforderung wird dann eingereicht.[14] [15]

Verschlüsselung[Bearbeiten]

TLS (wie SSL zuvor) bietet mehrere verschiedene Möglichkeiten die Nutzdaten zu verschlüsseln und Client und Server einigen sich beim Handshake (Aufbau der Verbindung) darauf, welche der jeweils bekannten Methoden genutzt werden soll. Die definierten Verfahren sind alle Block- oder Stream-Cipher, die die Daten mit einem symmetrischen Schlüssel verschlüsseln, der ebenfalls beim Handshake ausgetauscht wird; symmetrische Techniken haben den Vorteil, dass sie im Allgemeinen weniger Rechenzeit benötigen.


Anwendung und Praxis[Bearbeiten]

Probleme[Bearbeiten]

Es gibt leider veraltete Implementierungen die unter Umständen berücksichtigt werden müssen, z. B. kann der Internet Explorer unter Windows XP aufgrund fehlender Unterstützung für SNI unter jeder IP-Adresse nur genau ein TLS Zertifikat lesen[16]. Der Internet Explorer unterstützt erst ab Version 11 eine TLS-Version jenseits von 1.0. Der Standard Browser des mobilen Betriebssystems Android ist erst ab Version 3.0 mit einer heutzutage als sicher betrachteten TLS-Version ausgestattet.

Serverkonfiguration[Bearbeiten]

https://cipherli.st/ und Mozillas TLS-Config-Generator stellen aktuelle Konfigurationen für Apache, nginx und lighthttpd zur Verfügung, die dem aktuellen Stand der Sicherheit entsprechen; diese sind aus Aktualitätsgründen absichtlich nicht hier ins Wiki übernommen.

Unter https://www.ssllabs.com/ssltest/index.html kann man einen Server auf seine TLS-Qualitäten testen lassen.

Weiterleitung HTTP → HTTPS[Bearbeiten]

Um automatisiert alle Verbindungen von HTTP nach HTTPS weiterzuleiten kann man im Apache-Webserver folgenden Code in den Virtual Host eintragen:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

HTTP Strict Transport Policy[Bearbeiten]

Zusätzlich zur Weiterleitung auf HTTPS wird empfohlen, einen speziellen Header, den HTTP Strict Transport Policy-Header (HSTS) zu senden. Dieser weist die Browser für eine angegebene Zeit an, nur noch mit HTTPS zur Seite zu verbinden und verhindert somit ein Angriffsszenario, bei dem versucht wird, zu HTTP umzuleiten[17]. Der Browser wird dann auf solche Angriffe mit einer Warnmeldung reagieren. Der Header kann bei Apache beispielsweise folgendermaßen festgelegt werden:

Header always set Strict-Transport-Security "max-age=15768000;includeSubdomains"
Beachten Sie: "15768000" sind die Zeit in Sekunden, die ein Browser den Header beachtet. Umgerechnet ist dies ein halbes Jahr. Bevor dieser Header gesetzt wird, sollten Sie also sicherstellen, dass Sie HTTPS auch noch eine lange Zeit unterstützen können. Dabei können Sie die Zeit zunächst kürzer halten und später verlängern. Möchten Sie HTTPS später vollständig entfernen, können Sie max-age zunächst auf 0 setzen und HTTPS eine Weile weiter mit dem neuen Header anbieten. Alle Browser, die den Header jetzt erhalten, aktualisieren die Gültigkeitszeit (auf 0 Sekunden) und entfernen ihn somit. Danach kann HTTPS ohne Probleme entfernt werden.

Damit der HSTS-Header wirksam ist, muss allerdings die erste Verbindung mit der betreffenden Seite über HTTPS erfolgen und nicht manipuliert werden – HSTS schützt erst ab der zweiten Verbindung, da der Browser erst dann von der HTTPS-Präferenz weiß. Diesen Angriffsvektor geht Google mit einer Liste namens HSTS preload an, in die man sich – sofern man die Bedingungen erfüllt – eintragen lassen kann. Nach der Eintragung rufen alle größeren Browser (Chrome, Firefox, Opera, Safari, IE 11 und Edge) die Seite direkt bei der ersten Verbindung über HTTPS auf.

Mixed Content[Bearbeiten]

Wenn Sie in einer mit TLS verschlüsselten Verbindung auf eine HTTPS-Inhalte noch Inhalte mit dem HTTP-Protokoll referenzieren, kommt es zu einem Warnhinweis, dass diese Webseite unsichere Inhalte beinhaltet. Theoretisch kann ein Nachladen unsicherer Inhalte zu einem Man-in-the-Middle-Angriff oder zum Daten-Phishing missbraucht werden.

Dabei wird zwischen passivem und aktivem Inhalt unterschieden:

Passive Inhalte:

  • audio (src-Attribut)
  • img (src-Attribut)
  • video (src-Attribut)
  • object (Ressourcen, die mit einem weiteren HTTP-Request geladen werden)

Aktive Inhalte:

  • script (src-Attribut)
  • link (src-Attribut, auch bei Stylesheets)
  • XMLHttpRequest (Objekt-Anfragen)
  • iframe (src-Attribut)
  • Alle Fälle, in denen in CSS eine URL verwendet wird) (@font-face, cursor, background-image, …)
  • object (data-Attribut)

Dies können Sie verhindern, indem Sie Links auf Ihrer Webseite nach http:// durchsuchen und diese mit https:// ersetzen.

Empfehlung: Referenzieren Sie Links auf interne Resourcen mit protokoll-relativen URIs.

Siehe auch:

Siehe auch[Bearbeiten]

Weblinks[Bearbeiten]

Quellen[Bearbeiten]

  1. Harald Bögeholz / heise online: Hotel-WLAN manipuliert alle abgerufenen Webseiten
  2. istlsfastyet: IsTLSFastYet
  3. netzpolitik: Bruce Schneier: Warum wir verschlüsseln
  4. Russische Provider sperrten zeitweise die Wikipedia
  5. golem.de: Firefox und Chrome erzwingen HTTP/2-Verschlüsselung
  6. Mozilla Security Blog: Deprecating Non-Secure HTTP
  7. Version 1.0 hatte vor der Veröffentlichung entdeckte Sicherheitslücken
  8. wikipedia: POODLE
  9. 2011 waren es bei Firefox z. B. 1482 Zertifikate
  10. golem.de: Deutsche Webhoster: Vorerst keine automatische Unterstützung von Let's Encrypt
  11. Zertifikate: Auch Google wirft Wosign und Startcom raus
  12. Thomas Leister: Eine eigene OpenSSL CA erstellen und Zertifikate ausstellen
  13. Mathias Kettner: Erstellen eines Server-Zertifikates
  14. ssl-trust: CSR erstellen
  15. psw: Wie wird eine Zertifizierungsanforderung (CSR) erstellt (Apache)?
  16. wikipedia: Server Name Indication
  17. Der Angriff nennt sich SSL Stripping. Mehr Infos beispielsweise hier: https://en.wikipedia.org/wiki/Moxie_Marlinspike#SSL_stripping

Spezifikationen[Bearbeiten]

  • RFC 2818 - HTTP Over TLS
  • RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
  • RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Weiterführende Links[Bearbeiten]