HTTPS und TLS

Aus SELFHTML-Wiki
(Weitergeleitet von TLS)
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, aus dem das heutige Transport Layer Security hervorgegangen ist, dessen aktuellste Version 1.2 ist.

Da TLS auf der Transport-Schicht im TCP/IP-Referenzmodell arbeitet, lassen sich auch andere unverschlüsselte Protokolle wie SMTP oder IMAP analog zu HTTP absichern, ohne das Rad neu erfinden zu müssen.

Nutzen

Bei einer normalen HTTP-Verbindung können alle Daten, die in beide Richtungen (Anfrage vom Browser, 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üsselt erreichbaren 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 selektiv 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

SSL oder TLS?

Die verwendete Technik im Falle von HTTPS (und auch an diversen anderen Stellen, z. B. SMTPS, IMAPS) heißt heutzutage TLS (Transport Layer Security). TLS ist eine Weiterentwicklung des Protokolls SSL (Secure Sockets Layer). SSL war eine Entwicklung der Firma Netscape und die erste öffentlich genutzte (1995) Version war 2.0 (Version 1.0 hatte vor der Veröffentlichung entdeckte Sicherheitslücken) 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. TLS 1.3 wird für 2018 erwartet.

Aufgrund von bekannten Problemen in SSL 3.0[7] sollte heutzutage eigentlich ausschließlich TLS verwendet werden und sehr häufig ist eigentlich TLS gemeint – auch wenn der Begriff SSL genutzt wird.


Zertifikate

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 asymmetrische Verschlüsselungstechniken bei denen der Schlüssel (key) zum Verschlüsseln ein anderer ist als der zum Entschlüsseln benutzte (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 beim Aufbau der Verbindung das Zertifikat vom Server und kann überprüfen, ob der im Zertifikat genannte (Domain-)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 (u. a. Browser) 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.

Diese Liste mit vertrauenswürdigen CAs kann man sich vorstellen wie die Aussteller von Ausweisen:
Ein Supermarkt erkennt einen Ausweis und einen Führerschein als Altersnachweis an, lehnt dagegen einen Schülerausweis oder etwas selbst-gebasteltes ab, weil man dem Herausgeber nicht vertraut. In diese Liste werden nur Aussteller von Ausweise bzw. Zertifikaten aufgenommen, die vertrauenswürdig sind und Sicherheitsstandards einhalten.

Certificate Authorities

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 fehlerbehaftet (siehe z. B. en.wikipedia.org: Certificate authority#CA_compromise) und die Anzahl direkt oder indirekt integrierter Zertifikate ist bei den meisten Browsern unübersichtlich groß[8]. Diese Dienstleistung muss allerdings nicht kostenpflichtig sein, einige CAs bieten kostenlose Zertifikate an oder haben einen Vertrag mit einem Hoster abgeschlossen, sodass für dessen Kunden Zertifikate ohne weitere Zusatz-Kosten verfügbar sind.

Das u. a. von Mozilla, Akamai, Google, Cisco sowie der EFF initierte Let's Encrypt gibt kostenlos Zertifikate heraus, die aus Sicherheitsgründen nur eine Laufzeit von 90 Tagen haben, dafür aber mittels einer auf dem Server installierten Software[9] vollautomatisch aktualisiert werden. Let’s Encrypt hat mit seiner einfachen und automatisierten Ausgabe von Zertifikaten maßgeblich für eine zunehmende Verbeitung von HTTPS gesorgt und ist die CA der Wahl, wenn man einen eigenen Server betreibt.

Viele Webhoster aktivieren HTTPS automatisch und ohne weitere Eingriffe oder Kosten aufseiten des Kunden.

kompromittierte Zertifikate

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 immer 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 Zertifikate mit längerer Laufzeit.

Erstellung von Zertifikaten

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

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.[12][13]

Verschlüsselung

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 als Asymmetrische Verschlüsselung.


Anwendung und Praxis

Serverkonfiguration

https://cipherli.st/ und Mozillas TLS-Config-Generator stellen aktuelle Konfigurationen für Apache, nginx und Lighttpd 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

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

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.[14] 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"
"expr=%{HTTPS} =~ /on/"
Beachten Sie: "15768000" ist 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ß. Deshalb darf der Header nur gesendet werden, wenn auch der erste Aufruf über https erfolgt (expr=%{HTTPS} =~ /on/). Google etwa geht diesen Angriffsvektor 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

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

Weblinks

Quellen

  1. ↑ Harald Bögeholz / heise online: Hotel-WLAN manipuliert alle abgerufenen Webseiten
  2. ↑ Is TLS Fast Yet?
  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. ↑ Wikipedia: POODLE
  8. ↑ 2011 waren es bei Firefox z. B. 1482 Zertifikate
  9. ↑ ACME Client Implementations
  10. ↑ Thomas Leister: Eine eigene OpenSSL CA erstellen und Zertifikate ausstellen
  11. ↑ Mathias Kettner: Erstellen eines Server-Zertifikates
  12. ↑ ssl-trust: CSR erstellen
  13. ↑ psw: Wie wird eine Zertifizierungsanforderung (CSR) erstellt (Apache)?
  14. ↑ Der Angriff nennt sich SSL Stripping. Mehr Infos beispielsweise unter https://en.wikipedia.org/wiki/Moxie_Marlinspike#SSL_stripping

Spezifikationen

  • 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)
  • RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3

Weiterführende Links

Abgerufen von „http://wiki.selfhtml.org/index.php?title=HTTPS_und_TLS&oldid=85987“