Was ist HTTPS?

Wie sicher bist Du Dir, dass Deine Daten im Internet geschützt sind? Ohne HTTPS ist Deine Online-Privatsphäre potentiellen Angreifern schutzlos ausgeliefert! In diesem Artikel wirst Du erfahren, wie HTTPS funktioniert und wie es Deine persönlichen Informationen schützt.

Was bedeutet HTTPS?

Hypertext Transfer Protocol Secure (HTTPS) ist eine abhörsichere Erweiterung von Hypertext Transfer Protocol (HTTP) und für die sichere Datenübertragung zwischen Webbrowsern und Websites verantwortlich. Dabei wird HTTP für die Übertragung und Transport Layer Security (TLS) für die Verschlüsselung der Daten verwendet.

TLS war früher auch als Secure Sockets Layer (SSL) bekannt, weshalb HTTPS ebenfalls unter den Namen HTTP über TLS oder HTTP über SSL bekannt ist.

Websites werden auf Servern gespeichert. Wenn ein Benutzer auf eine Website zugreift, müssen diese Daten auf dem Computer des Clients bereitgestellt werden. Insbesondere, wenn dabei vertrauliche Daten über das Internet übertragen werden, wie z.B. beim Anmelden im Bankkonto, E-Mail-Dienst oder Krankenversicherer, ist eine sichere Datenübertragung mit Transportverschlüsselung essentiell. So können Hackerangriffe und Man-in-the-Middle-Angriffe vermieden und personenbezogene Daten geschützt werden. Aber auch das Nutzervertrauen und die Suchmaschinenrankings werden positiv beeinflusst. Die Verwendung von HTTPS hat also sogar positive Auswirkungen auf die Suchmaschinenoptimierung (SEO) und die Sichtbarkeit auf Google sowie auf anderen Suchmaschinen.

Eine sichere URL beginnt mit einem “https://” und HTTPS-verschlüsselte Websites werden in Browsern in der Regel mit einem Schlosssymbol dargestellt.

Wie funktioniert HTTPS?

HTTPS vereint zum Verschlüsseln von Kommunikationen den Übertragungsprozess von HTTP mit dem Verschlüsselungsprotokoll Transport Layer Security (TLS), früher als Secure Sockets Layer (SSL) bekannt. TLS ermöglicht eine abhörsichere Kommunikation durch Verwendung einer asymmetrischen Public-Key-Infrastruktur.

Die asymmetrische Public-Key-Infrastruktur verwendet zwei Schlüssel:

1. Der öffentliche Schlüssel ist für jeden verfügbar, der abhörsicher mit dem Server kommunizieren möchte. Mit dem öffentlichen Schlüssel verschlüsselte Informationen können nur mit dem privaten Schlüssel vom Webserver wieder entschlüsselt werden.
2. Der private Schlüssel befindet sich auf dem Webserver und wird vom Eigentümer der Website vertraulich behandelt. Nur der private Schlüssel kann Informationen entschlüsseln, die mit dem öffentlichen Schlüssel verschlüsselt wurden.

Die beiden Schlüssel ermöglichen es jedem Client, dem Webserver vertrauliche Informationen zu senden, sodass nur der Webserver diese verstehen kann. Doch wie kann der Webserver Informationen zurück zum Client senden, ohne dass jemand diese unterwegs abhören kann?

Wie funktioniert in HTTPS ein TLS-Handshake?

Für eine beidseitig sichere Datenübertragung wird durch einen TLS-Handshake ein geheimer Sitzungsschlüssel erstellt und ausgetauscht, den nur der Webserver und der Client kennen können:

1. Der Client kontaktiert den Webserver, beispielsweise über einen Webbrowser.
2. Der Server akzeptiert die Verbindung und sendet sein Zertifikat sowie seinen öffentlichen Schlüssel zur Authentifizierung.
3. Der Client überprüft das Zertifikat. Wenn es ungültig ist, wird die Verbindung unterbrochen. Wenn es gültig ist, erstellt der Client einen geheimen Sitzungsschlüssel.
4. Der Client verschlüsselt den geheimen Sitzungsschlüssel mit dem öffentlichen Schlüssel des Servers und sendet ihn an den Server.
5. Der Server entschlüsselt den geheimen Sitzungsschlüssel mit seinem privaten Schlüssel.
6. Nun können der Server und der Client den geheimen Sitzungsschlüssel verwenden, um die Daten während der Kommunikation zu ver- und entschlüsseln.

In der Regel gilt der geheime Sitzungsschlüssel nur für die aktuelle Sitzung. Der private und öffentliche Schlüssel der Public-Key-Infrastruktur besteht hingegen langfristig.

Die Public-Key-Infrastruktur bietet somit die Grundlage für einen TLS-Handshake und ermöglicht so eine abhörsichere Kommunikation zwischen Client und Webserver in beide Richtungen.

Unterschied zwischen HTTPS und HTTP

HTTPS nutzt HTTP zur Datenübertragung und verwendet zusätzlich Verschlüsselung und Verifizierung. Der einzige Unterschied zwischen HTTPS und HTTP besteht also darin, dass HTTPS die Kommunikation mit TLS verschlüsselt und digital signiert. Das macht HTTPS deutlich sicherer als HTTP.

Da HTTP keine Sicherheitsebene besitzt, ist das Protokoll ausschließlich für die Übertragung von Klartext-Informationen im Internet verantwortlich. Das macht Websites, die HTTP verwenden, anfällig für Man-in-the-Middle- und Lauschangriffe.

Damit vertrauliche Informationen wie Kreditkarteninformationen, Rechnungsadressen oder Passwörter nicht von Hackern mitgelesen werden können, verwendet HTTPS zusätzlich zum HTTP-Protokoll eine SSL/TLS-Verschlüsselung. Dabei werden SSL/TLS-Zertifikate übertragen, um zu bestätigen, dass es sich bei dem Anbieter auch um die behauptete Person handelt. Außerdem wird ein TLS-Handshake verwendet, um mit einem Sitzungsschlüssel Daten zu verschlüsseln und abhörsicher zu übertragen.

Eine HTTPS-Verbindung wird durch ein “https://” statt einem “http://” für HTTP signalisiert. In der Regel wird bei einer HTTPS-Verbindung der Port 443 und bei einer HTTP-Verbindung der Port 80 verwendet.

Die folgende Tabelle fasst alle Unterschiede zwischen HTTPS und HTTP zusammen:

Wie sicher ist HTTPS?

HTTPS verwendet TLS zur Verschlüsselung des HTTP-Protokolls. Typischerweise gibt es also einen langfristigen öffentlichen und privaten Schlüssel, aus denen mittels eines TLS-Handshakes ein kurzfristiger Sitzungsschlüssel generiert wird. Dieser wird nun verwendet, um den Datenfluss zwischen Client und Webserver abhörsicher zu verschlüsseln.

Zusätzlich werden bereits beim Verbindungsaufbau Zertifikate verwendet, um den Webserver und manchmal auch den Client zu authentifizieren.

SSL/TLS gilt als mathematisch sicher und lässt sich nicht brechen. Dennoch gibt es einige Sicherheitseinschränken, denen man sich bewusst sein sollte.

Limitierungen von TLS

HTTPS basiert auf TLS, um das zugrunde liegende HTTP-Protokoll zu verschlüsseln. Dadurch können die URL der Anfrage, die Abfrageparameter, die Header und alle Cookies sicher übertragen werden.

Allerdings werden Webadressen und Portnummern durch die TCP/IP-Protokolle übertragen. Das führt dazu, dass HTTPS diese Informationen nicht schützen kann. Selbst bei korrekt konfigurierten Webservern können Lauschangriffe IP-Adressen und Portnummern des Webservers sowie unter Umständen auch die Domänennamen, wie z.B. “www.google.de” (ohne den Rest der URL), ermitteln. Darüber hinaus können Angreifer die Menge der übertragenen Daten und die Dauer der Kommunikation feststellen.

Implementierungsfehler und Lücken in SSL/TLS

SSL/TLS gilt zwar als mathematisch nicht zu brechen, aber dennoch können Fehler in der Implementierung Sicherheitslücken verursachen.

Durch Recherche sind über die Jahre Lücken in der Umsetzung gefunden worden. Beispielsweise wurde 2013 bekannt, dass die NSA Schwachstellen sowohl bei der Verschlüsselung als auch im Zertifikatssystem nutzte, um Zugang zu verschlüsselten Verbindungen zu erlangen.

Schützt HTTPS vor DNS-Spoofing?

Beim Spoofing des Domain Name System (DNS) werden Einträge im DNS-Cache eines DNS-Servers verfälscht, um einen Nutzer heimlich auf eine andere Website umzuleiten, als er angefragt hatte. DNS-Spoofing ermöglicht es dem Angreifer, sensible Daten von ahnungslosen Nutzern zu stehlen.

Doch schützt HTTPS vor DNS-Spoofing? Angenommen, ein Angreifer hat den DNS-Cache mit einer anderen IP-Adresse vergiftet. Versucht ein Nutzer nun, die eigentlich sichere Website zu besuchen, wird er auf die vom Angreifers eingetragene IP-Adresse weitergeleitet. Doch als Teil des SSL-Handshake-Prozesses muss der Webserver ein gültiges Zertifikat und den öffentlichen Schlüssel für die ursprüngliche Website bereitstellen. Jetzt gibt es zwei mögliche Szenarien:

1. Der Angreifer sendet das korrekte Zertifikat. Das Zertifikat wird vom Nutzer akzeptiert und daraufhin verschlüsselt und sendet er seine Nachricht wie gewöhnlich zum Webserver. Da der Angreifer allerdings nicht den privaten Schlüssel der ursprünglichen Website besitzt, kann er die Nachricht nicht entschlüsseln.
2. Der Angreifer sendet ein gefälschtes Zertifikat. Dieses ist jedoch nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert und so wird im Browser des Nutzers eine Warnung angezeigt.

DNS-Spoofing funktioniert in der Regel also nur dann, wenn Nutzer Warnhinweise ignorieren und somit ist HTTPS eins der besten Schutzmechanismen gegen DNS-Spoofing.

HTTPS und VPN für mehr Sicherheit

Virtuelle private Netzwerke (VPNs) verbergen die Identität und die Browseraktivitäten eines Benutzers. Durch die Kombination von HTTPS und VPN-Diensten entsteht eine doppelte Sicherheitsebene. Auf diese Weise werden die Vorteile beider Technologien zur Erzielung höchstmöglicher Sicherheit vereint.

Warum ist HTTPS so wichtig?

HTTPS verhindert Lauschangriffe durch Verschlüsselung. Wird stattdessen HTTP ohne Verschlüsselung verwendet, werden alle Informationen komplett unverschlüsselt im Klartext übertragen und die Kommunikation zwischen Client und Webserver ist potenziellen On-Path-Angriffen schutzlos ausgeliefert. So können Angreifer persönliche Daten wie Namen, Adressen, Telefonnummern, Passwörter oder Informationen zum Online-Banking oder Versicherungen problemlos mitlesen.

HTTPS verschlüsselt die Daten derart, dass kein potenzieller Angreifer die Inhalte entziffern kann. Beispielsweise möchte der Client die folgende Nachricht übermitteln:

Dies ist ein unverschlüsselter Klartext

Mittels HTTPS wird diese Nachricht beispielsweise folgendermaßen verschlüsselt:

ALD10+k9gBpohYcDWQ0djJWz4BtXcfpluSsX0D1uqRlmb2a/4RwVEv93J0qpN9z4A8qwgZkBJ/Ey9X/WQJ9t4cIJ5s2sg4/QxNn4gEOcvVMoUo9v8OVBtFYbb+9tpGRO58ok4K9BXn4j5oI3yNNTxYhMalhCn5lU3jtvzvLhenQ=

Der Webserver kann diese Nachricht problemlos mit dem geheimen Sitzungsschlüssel, den er über den TLS-Handshake erhalten hat, entschlüsseln, doch kein Angreifer kann den Inhalt der Nachricht verstehen.

Was sind die Gefahren ohne HTTPS?

Angriffe in öffentlichen WLAN-Netzwerken

Die Verwendung von HTTPS ist insbesondere in öffentlichen WLAN-Netzwerken empfehlenswert. Jede Person, die sich im selben lokalen Netzwerk befindet, kann ungeschützte Pakete zwischen Clients und Webservern ohne HTTPS-Verschlüsselung im Klartext mitlesen. Dadurch können sie vertrauliche Informationen abfangen. Die Anzahl an privaten und öffentlichen WLAN-Netzwerken nimmt rasant zu und das jährliche Wachstum wird bis 2029 auf 27,03% geschätzt. Somit steigt auch das Risiko von derartigen Lauschangriffen.

Gefahren im Tor-Netzwerk

Ebenso wichtig ist die Verwendung von HTTPS für Verbindungen über das Tor-Netzwerk. Ohne HTTPS können Daten manipuliert oder verändert und Malware in die Verbindung eingeschleust werden.

Modifizierung fremder Websites

Verwendet eine Website kein HTTPS, können Internet-Service-Provider (ISPs) oder andere Vermittler Inhalte der Website ohne die Zustimmung des Besitzers modifizieren. Oft wird so Werbung eingebettet, um so den Umsatz des Angreifers zu steigern, ohne dies dem Websitebesitzer mitzuteilen. HTTPS verhindert diese Modifikationen.

Suchmaschinenoptimierung (SEO)

Seit 2014 betrachtet Google die Verwendung von HTTPS als ein positives Ranking-Signal im Bezug auf SEO. Websites, die kein HTTPS verwenden, könnten daher in ihrer Platzierung beeinträchtigt werden. Zusätzlich zeigen Browser Warnungen an, wenn eine Website kein HTTPS verwendet, was zu einer höheren Absprungrate der Besucher führen kann. Dies wiederum wird von Google als negatives Ranking-Signal gewertet und kann sich negativ auf die Platzierung in den Suchergebnissen auswirken. Die Verwendung von HTTPS ist somit ein entscheidender Faktor für eine erfolgreiche Suchmaschinenoptimierung.

Technische Limitierungen von HTTPS

Bei HTTPS gibt es einige technische Limitierungen, die beachtet werden sollten. Die Wirksamkeit der SSL/TLS-Verschlüsselung hängt von der korrekten Implementierung und den verwendeten Algorithmen ab. Eine fehlerhafte Implementierung kann die Sicherheit gefährden.

Ein weiteres Problem ist, dass das Indexieren von Websites durch Webcrawler nicht verhindert wird, was potenziell sensible Informationen preisgeben könnte. Auch die Analyse der Größe von Anfragen und Antworten kann Rückschlüsse auf die URI (Uniform Resource Identifier) zulassen.

Ein technisches Limit von TLS ist die Beschränkung auf ein Zertifikat pro Adresse/Port ohne den Einsatz von SNI (Server Name Indication). Ältere Browser unterstützen SNI oft nicht, was die Nutzung von HTTPS erschweren kann. Die Verwaltung von SSL/TLS-Zertifikaten kann zudem komplex und zeitaufwendig sein, da Zertifikate regelmäßig erneuert werden müssen und fehlerhafte Konfigurationen zu Sicherheitslücken führen können. Hochwertige SSL/TLS-Zertifikate sind oft mit Kosten verbunden, insbesondere wenn sie von vertrauenswürdigen Zertifizierungsstellen (CAs) stammen. Obwohl es kostenlose Optionen wie Let's Encrypt gibt, haben sie möglicherweise Einschränkungen, die nicht für alle Websites geeignet sind.

Die SSL/TLS-Verbindung wird von der initiierenden Front-Maschine verwaltet, was die Weitergabe komplexer Benutzerauthentifikationen erschwert. Eine weitere Sicherheitsbedrohung ist der SSL-Stripping-Angriff, bei dem HTTPS-Verbindungen auf HTTP herabgestuft werden können. Obwohl HTTPS die Datenverschlüsselung verbessert, ist es dennoch anfällig für Traffic-Analysen, die sensible Informationen offenlegen können. Zudem kann “Mixed Content” (gemischte Inhalte) die Sicherheit der gesamten Seite gefährden, wenn HTTPS-Seiten nicht-verschlüsselte Inhalte laden.

Probleme beim Zugriff auf HTTPS-Websites über öffentliche WLAN-Hotspots sowie Performance-Einbußen durch die Verschlüsselung und Entschlüsselung von Daten können ebenfalls auftreten, da diese zusätzliche Serverressourcen beanspruchen und die Ladezeiten der Website leicht erhöhen können. Dies kann zusätzlich negative Auswirkungen auf SEO haben. Nicht alle Systeme und Geräte unterstützen die neuesten Versionen von SSL/TLS, was zu Kompatibilitätsproblemen führen kann, insbesondere bei älteren Geräten oder Software.

Da die Sicherheit von HTTPS stark von den Zertifizierungsstellen abhängt, könnten die von ihr ausgestellten Zertifikate unsicher werden, wenn die CA kompromittiert wird. Manchmal müssen Websites Zwischenzertifikate verwenden, die ebenfalls richtig konfiguriert und installiert werden müssen. Fehler hierbei können dazu führen, dass die HTTPS-Verbindung als unsicher betrachtet wird. Ältere Verschlüsselungsstandards, die noch von einigen Servern und Clients verwendet werden, können Schwachstellen aufweisen, die ausgenutzt werden könnten.

Website auf HTTPS umstellen in 10 Schritten

Eine Website kann in 10 Schritten von HTTP auf HTTPS umgestellt werden. Nicht alle Schritte sind für jede Website relevant, aber diese Liste kann als Leitfaden dienen, um sicherzustellen, dass kein wichtiger Schritt vergessen wird.

Herausforderungen beim Umstellen am Beispiel Stack Overflow

Der Prozess der Implementierung von HTTPS bei Stack Overflow umfasste mehrere Phasen und Herausforderungen und dauerte vier Jahre. Folgenden Gründe machten die Situation außergewöhnlich:

• Hunderte von Domains (viele Websites und andere Dienste)
  • Viele Second-Level-Domains (stackoverflow.com, stackexchange.com, askubuntu.com, usw.)
  • Viele 4th-Level-Domains (z.B. meta.gaming.stackexchange.com)
• Benutzer können Inhalte einreichen und einbetten (z.B. Bilder und YouTube-Videos in Beiträgen)
• Ein einziges Rechenzentrum (Latenz zu einem einzigen Ursprung)
• Verwendung von Werbung und Werbenetzwerken
• Verwenden von Websockets, mit mehr als 500.000 aktiven Verbindungen zu jeder Zeit
• Viele DDoS-Angegriffe (Proxy)
• Viele Websites und Anwendungen kommunizieren über HTTP-APIs (Proxy-Probleme)
• Hoher Anspruch an Performance

Zunächst musste das Team seine Infrastruktur aktualisieren, um HTTPS zu unterstützen. Dazu gehörten die Aufrüstung von Load Balancern und die ordnungsgemäße Verwaltung der SSL-Zertifikate. Außerdem mussten sie ihre Systeme optimieren, da der zusätzliche Verschlüsselungs-Overhead die Geschwindigkeit der Website beeinträchtigen könnte.

Ein großes Problem waren gemischte Inhalte bei Millionen von Seiten und Assets, bei denen HTTPS-Seiten immer noch unsichere HTTP-Ressourcen geladen haben. Außerdem mussten sie verschiedene Dienste und Abhängigkeiten von Drittanbietern aktualisieren, um die Kompatibilität mit HTTPS zu gewährleisten.

Eine weitere Herausforderung war die Aufrechterhaltung von SEO-Rankings und Verweisdaten während der Umstellung. Es wurden 301-Weiterleitungen verwendet, um Suchmaschinen über die Änderungen zu informieren, die Suchergebnisse beizubehalten und diese durch die Umstellung auf HTTPS wenn möglich sogar durch das positive Ranking Signal zu verbessern.

Umstellung auf HTTP Strict Transport Security (HSTS)

Während eines 301-Redirects ergibt sich ein kurzes Zeitfenster für Man-in-the-Middle-Angriffe. Um sich vor diesen schützen zu können, wird empfohlen, HTTP Strict Transport Security (HSTS) mit HTTPS zu verwenden. HSTS informiert den Browser darüber, dass die Website ausschließlich mit HTTPS statt HTTP geöffnet werden soll. Somit werden zukünftige Zugriffe automatisch zu HTTPS konvertiert.

Bevor Du HSTS aktivierst, solltest Du zunächst sicherstellen, dass Dein SSL-Zertifikat auf dem neuesten Stand ist und korrekt funktioniert. Teste ebenfalls die Webanwendungen und Benutzeranmeldungen.

Um nach dem Aktivieren von HSTS zu testen, ob es korrekt funktioniert, solltest Du das Höchstalter (max-age) schrittweise erhöhen. Das Höchstalter gibt an, wie lange jede HTTP-Anfrage auf HTTPS umgeleitet werden soll. Diesen Wert schrittweise zu erhöhen, ermöglicht es Dir, den Prozess sorgfältig zu überwachen und Fehler frühzeitig zu erkennen und zu beheben. Wenn direkt ein sehr langer Zeitraum eingestellt wird und Probleme auftreten, kann es schwierig sein, diese zu beheben, da die Browser der Benutzer gezwungen werden, für den gesamten Zeitraum ausschließlich HTTPS zu verwenden. Die folgenden Schritte werden empfohlen:

• 5 Minuten Höchstalter = 300 Sekunden
• 1 Woche Höchstalter = 604800 Sekunden
• 1 Monat Höchstalter = 2592000 Sekunden
• 2 Jahre Höchstalter = 63072000 Sekunden

Wie wird HTTPS von Browsern integriert?

Die meisten Browser zeigen eine Warnung, wenn eine Website nicht HTTPS verwendet. Alte Browser öffnen ein Dialogfenster, wohingegen neuere Browser eine Warnung über das gesamte Fenster platzieren.

Neue Browser zeigen zusätzlich Sicherheitsinformationen in der Adressleiste, oftmals in Form eines Vorhängeschlosses.

Die meisten modernen Browser zeigen ebenfalls Warnungen an, wenn die besuchte Website eine Mischung aus verschlüsselten und unverschlüsselten Inhalten enthält.

Um unsichere Websites sicher besuchen zu können, wurden Browser-Plug-ins wie HTTPS Everywhere für Mozilla Firefox, Opera und Google Chrome entwickelt, um Verbindungen zu Websites automatisch zu verschlüsseln. Viele Browser wie Firefox oder Chrome ermöglichen zusätzliche Einstellungen, um ausschließlich das Laden von HTTPS-Inhalten zu erzwingen.

Geschichte von HTTPS kurzgefasst

HTTPS wurde 1994 von Netscape entwickelt und zusammen mit SSL 2.0 und dem eigenen Browser Netscape Navigator veröffentlicht. Es handelte sich zu dem Zeitpunkt um ein URI-Schema, also eine zusätzliche Schicht zwischen HTTP und TCP.

Im Mai 2000 wurde SSL zu TLS weiterentwickelt und somit auch formal im RFC 2818 spezifiziert.

Die Spezifikation RFC 2818 wurde im Juni 2022 vom Internetstandard RFC 9110 abgelöst.