Schauen Sie sich jetzt einmal die Adressleiste Ihres Browsers an. Die Website beginnt mit ziemlicher Sicherheit mit „https“ und zeigt ein kleines Vorhängeschloss an; wäre dies nicht der Fall, würde Ihr Browser Sie wahrscheinlich warnen, bevor Sie fortfahren können. Dieser eine zusätzliche Buchstabe, das „s“, hat das Internet still und leise verändert. Dieses kleine „s“ steht für „sicher“ und ist weitaus wichtiger, als man gemeinhin annimmt. Dieser Blogbeitrag bietet einen leicht verständlichen Vergleich zwischen HTTP und HTTPS: Was genau unterscheidet die beiden Protokolle, warum ist das wichtig und wo liegen die tatsächlichen Feinheiten?
HTTP vs. HTTPS auf einen Blick
Hier ist die kurze Antwort, bevor ich ins Detail gehe. HTTP und HTTPS sind dasselbe Protokoll. Gleiche Methoden, gleiche Header, gleiche Statuscodes, gleiche URL-Struktur. Eine HTTPS-Anfrage entspricht Byte für Byte der HTTP-Anfrage, die es sonst gewesen wäre; sie wird lediglich anders übertragen. HTTPS ist HTTP, das innerhalb einer TLS -Sitzung übertragen wird, weshalb die Definition so knapp ausfällt: ein Schema, ein Standardport und die Anweisung, den TLS -Handshake abzuschließen, bevor HTTP verwendet wird. Was TLS hinzufügt, sind drei Eigenschaften, nicht nur die Verschlüsselung.
Vertraulichkeit: Die Daten werden verschlüsselt übertragen. Jeder, der die Daten auf ihrem Weg abfängt, sieht lediglich verschlüsselten Text, der von Rauschen nicht zu unterscheiden ist – und nicht Ihre Anfrage im lesbaren Text.
Integrität: „ TLS “ verwendet authentifizierte Verschlüsselung. Das bedeutet, dass jede Änderung an einem Datensatz die Authentifizierung scheitern lässt und die Verbindung unterbrochen wird, anstatt die geänderten Inhalte unbemerkt zu übermitteln.
Authentifizierung: Der Server legt ein digitales Zertifikat vor, das seinen öffentlichen Schlüssel mit dem von Ihnen eingegebenen Servernamen verknüpft und auf einen Vertrauensanker verweist, den Ihr Browser bereits enthält.
Der letzte Punkt ist wohl der wichtigste. Ohne ihn baut ein Angreifer auf dem Übertragungsweg einfach eine verschlüsselte Verbindung zuIhnenund eine separate Verbindung zum Ursprung auf, und die Vertraulichkeit nützt dann nichts mehr.
Port 80 vs. Port 443
Ein Port ist eine Nummer, die angibt, für welches Programm auf einem Rechner der Netzwerkverkehr bestimmt ist. Wenn Netzwerkverkehr an der „Tür“ Ihres Computers ankommt, prüft er den Port, den er mit sich bringt, und teilt diesen dem Computer mit, der den Datenverkehr dann an das richtige Programm weiterleitet. Webbrowser verwenden Port 80, um über das HyperText Transfer Protocol (HTTP) eine Verbindung zu Webservern herzustellen. HTTPS nutzt Port 443, wobei die Verbindung verschlüsselt und der Server authentifiziert wird. Wenn ein Browser eine sichere Verbindung benötigt, wechselt er automatisch zum verschlüsselten Kanal, sofern auf dem Server ein gültiges Zertifikat installiert ist.
Klartext vs. verschlüsselt
HTTP ist ein Klartextprotokoll, das alle Daten auf der Übertragungsstrecke offenlegt: Header, Cookies, Hauptteil usw. Das bedeutet, dass es relativ einfach ist, die Daten während der Übertragung abzufangen und zu lesen und so alles zu erfahren, was während der Kommunikation gesendet wurde. Es ist für alles, was Vertraulichkeit erfordert, ungeeignet. Darüber hinaus setzt HTTP Nutzer nicht authentifizierten Servern aus, die Malware enthalten oder andere Bedrohungen darstellen können. HTTPS hingegen verschlüsselt die Kommunikation und authentifiziert den Server. Selbst wenn ein Angreifer den Datenverkehr abfängt, erscheint der verschlüsselte Inhalt als unverständliches Kauderwelsch, sofern er nicht über den richtigen Entschlüsselungsschlüssel verfügt.
Woran man das erkennt
Am einfachsten lässt sich dies anhand der URL überprüfen. Eine sichere Website beginnt mit „https“ und zeigt ein Vorhängeschloss-Symbol neben der Adressleiste an. Klicken Sie auf dieses Vorhängeschloss, um die Zertifikatsdetails anzuzeigen, darunter den Aussteller und das Ablaufdatum.
Im Terminal können Sie außerdem alle derzeit geöffneten Verbindungen überwachen, die über einen bestimmten Port laufen. Beispielsweise für Port 443:
ss -tnp state established „( dport = :443 oder sport = :443 )“
Ein kurzer Rückblick: Wie das Web standardmäßig sicher wurde
HTTP gab es schon zuerst, und jahrelang war es der unverschlüsselte Standard im Web. Im Laufe der Zeit wurden Sicherheitsfunktionen hinzugefügt, und die Komponenten, die HTTPS ermöglichten, kamen schrittweise hinzu.
Das Zeitalter des Klartextes
In den Anfängen des Internets wurden Daten offen übertragen. HTTP übertrug Seiten und Formularübermittlungen als lesbaren Text, in dem Sinne, dass jeder, der eine Paketaufzeichnung hatte, durch eine Sitzung scrollen konnte, so wie man durch ein Dokument scrollt. Das war eine bewusste Designentscheidung, kein Versehen. Tim Berners-Lees ursprüngliches Protokoll verfügte über eine einzige Methode und keine Header; es holte Hypertext-Dokumente von Physik-Servern für ein Publikum aus Physikern ab. Die Anfänge waren von der akademischen Tradition der Offenheit geprägt, ohne Angst vor böswilligen Akteuren. Eine Verschlüsselung wäre ein unnötiger Aufwand gewesen, um einer Bedrohung entgegenzuwirken, die es noch gar nicht gab.
Was diese Annahme widerlegte, war kein Fehler im HTTP-Protokoll. Es waren der E-Commerce und die Angst vor Malware. Sobald im Internet Kreditkartennummern und Anmeldedaten übertragen wurden, war die Eigenschaft „für jeden auf dem Übertragungsweg lesbar“ keine neutrale Eigenschaft mehr. Außerdem war es wichtig, sich beim Besuch einer Website sicher zu fühlen und zu wissen, dass die Instanz auf der anderen Seite genau die ist, für die sie sich ausgibt.
Von Netscape SSL bis hin zu modernen TLS
Netscape entwickelte in den 1990er Jahren das „ SSL “, um die Internetkommunikation zu verschlüsseln und zu sichern.
- SSL Version 1.0 wurde aufgrund von Sicherheitsproblemen nie veröffentlicht.
- Version 2.0 kam 1995 auf den Markt und wies zahlreiche Mängel auf.
- 1996 folgte die Version 3.0 mit wesentlichen Verbesserungen.
- Die Internet Engineering Task Force entwickelte daraufhin „ TLS “ als Nachfolgeversion: „ TLS “ Version 1.0 im Jahr 1999, Version 1.2 im Jahr 2008 und Version 1.3, die 2018 fertiggestellt wurde.
- Bis 2020 war „ SSL “ vollständig veraltet, und „ TLS “ in den Versionen 1.2 und 1.3 wurden zu den weiterhin verwendeten Protokollen, auch wenn die Leute immer noch beiläufig von „SSL “ sprechen.
Einen vollständigen Vergleich zwischen SSL und TLS finden Sie in unserem Artikel zu „HTTPS Everywhere“.
Moderne Browser legen mittlerweile standardmäßig Wert auf Sicherheit. Chrome, Firefox, Edge und andere verwenden standardmäßig HTTPS und kennzeichnen unsichere Seiten entsprechend. Aus diesem Grund löst eine Website, die ausschließlich HTTP nutzt, zunehmend eine Warnung aus, anstatt stillschweigend geladen zu werden. Diese Standardeinstellung ist sozusagen „mehrschichtig“ geworden.
- Die erste dieser Ebenen betrifft das Verhalten der Adressleiste: Wenn man beispielsweise keyfactor.com eingibt, wird dies zuhttps://www.keyfactor.com aufgelöst.
- Der zweite Punkt betrifft die Verbesserung der Navigation: Wenn Sie auf den Linkhttp://www.keyfactor.com oder einen in eine Seite eingebetteten Link klicken, wird der Aufruf stillschweigend über HTTPS wiederholt, wobei bei einem Fehlschlag auf Klartext zurückgegriffen wird.
- Der dritte Modus ist der „HTTPS-First“-Modus: In diesem Modus wird der Fallback deaktiviert und eine vollständige Warnseite angezeigt. Der Nutzer kann zwar weiterhin fortfahren, muss dies jedoch ausdrücklich bestätigen.
Das Bedrohungsmodell: Was passiert wirklich bei einfachem HTTP?
Der Grund, warum Browser so stark auf HTTPS setzen, ist nicht nur kosmetischer Natur. Unverschlüsseltes HTTP weist echte, ausnutzbare Schwachstellen auf.
Abhören und Abfangen
Bei ungesicherten HTTP-Verbindungen kann jeder, der sich auf dem Netzwerkpfad befindet, Nachrichten zwischen dem Browser und dem Server abfangen und im Klartext lesen. Verschlüsselte Verbindungen verschlüsseln diese Kommunikation, bis der vorgesehene Empfänger sie entschlüsselt, sodass ein Abhörer nichts Verwertbares sieht. Dies ist besonders wichtig, wenn die Kommunikation personenbezogene Daten, sensible Informationen, Passwörter usw. enthält.
Man-in-the-Middle-Angriffe
Wenn Sie eine Website besuchen, sendet Ihr Browser eine Anfrage, und der Server sendet eine Antwort zurück. Ohne Schutz ist diese Interaktion anfällig für Man-in-the-Middle-Angriffe, bei denen ein böswilliger Akteur die übertragenen Daten abfängt und diese extrahieren oder verändern kann. Wenn Sie sich beispielsweise bei einem Online-Banking-Portal anmelden und jemand diesen Datenverkehr abfängt, könnten Ihre Zugangsdaten offengelegt werden, was möglicherweise zu Identitätsdiebstahl oder finanziellen Verlusten führen kann.
Vertrauen, Phishing und die Notwendigkeit einer Public-Key-Infrastruktur
Verschlüsselung ist nur die halbe Miete. Ein gültiges Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wurde, authentifiziert zudem den Server und belegt, dass die Website tatsächlich die ist, für die sie sich ausgibt. Wenn eine Website sensible Informationen abfragt und kein Zertifikat besitzt, sollte dieser Verbindung keine privaten Daten anvertraut werden. Die Serverauthentifizierung belegt, dass ein Zertifikat zu der Domain in der Adressleiste gehört – nicht jedoch, dass es sich bei der Domain um die handelt, die der Nutzer eigentlich besuchen wollte. Phishing nutzt diese Lücke aus, da ein Angreifer, der eine überzeugend ähnliche Domain registriert, ein gültiges Zertifikat dafür erhalten und eine vollständig authentifizierte Verbindung zu einer Website vortäuschen kann, der der Nutzer eigentlich nicht vertraut. HTTPS schützt daher sowohl die Vertraulichkeit des Datenaustauschs als auch die Identität der Website. Um mehr über Zertifizierungsstellen zu erfahren, lesen Sie unserenspeziellen Leitfaden zu CAs oder unserenausführlichen Artikel über PKI, um einen umfassenderen Überblick über die Vertrauensinfrastruktur zu erhalten.
Die zukünftige Bedrohung: Jetzt ernten, später entschlüsseln
Es besteht zudem ein zukunftsbezogenes Risiko. Die derzeitige Verschlüsselung ist zwar gegen klassische Computer sicher, nicht jedoch gegen ausreichend leistungsfähige Quantencomputer, die voraussichtlich in den kommenden 5 bis 15 Jahren realisiert werden. Dies hat Bedenken hinsichtlich (HNDL)-Angriffen aufkommen lassen, bei denen Angreifer heute verschlüsselten Datenverkehr aufzeichnen und beabsichtigen, diesen später zu entschlüsseln, sobald die Quantenkapazitäten ausgereift sind.
Um sich dagegen zu schützen, stellt die Branche derzeit auf Post-Quanten-Kryptografie um, die auf normalen Computern läuft, aber auch dann noch gegen Angriffe resistent bleibt, wenn leistungsstarke Quantencomputer gebaut werden. Teil dieser kryptografischen Umstellung ist der Ersatz des herkömmlichen Schlüsselaustauschs durch quantenresistente Mechanismen in zukünftigen Versionen von TLS.
Was HTTPS nach wie vor nicht verbirgt
Hier kommt der ehrliche Teil, der oft übersehen wird: HTTPS schützt denInhaltIhrer Anfragen, macht Sie aber nicht unsichtbar. Die Verschlüsselung verbirgt zwar, was Sie senden und empfangen, sodass ein Abhörer nur Kauderwelsch sieht, doch einige Signale bleiben offen sichtbar.
Metadaten, die sichtbar bleiben
Die Ziel-IP-Adresse ist nach wie vor einsehbar, da das Netzwerk Ihren Datenverkehr irgendwohin weiterleiten muss. In vielen Konfigurationen wird der Domainname zudem durch DNS -Abfragen offengelegt, und der Servername wird bereits zu Beginn der Verbindung übermittelt. Ein Beobachter kann Ihre Nachrichten zwar nicht lesen, oft jedoch erkennen, mit welchem Dienst Sie kommunizieren.
Verkehrsströme
Das Volumen und der zeitliche Verlauf Ihres Datenverkehrs können bereits für sich genommen Informationen preisgeben. Deutliche Muster, wie beispielsweise der Rhythmus eines Videostreams oder der Verlauf einer Anmeldesequenz, können Aufschluss darüber geben, was gerade geschieht, selbst wenn die Nutzdaten verschlüsselt sind.
Was Verschlüsselung nicht beheben kann
Die Verschlüsselung schützt Daten während der Übertragung, nicht jedoch an den Endpunkten der Verbindung. Ein kompromittiertes Gerät, Malware auf Ihrem Computer oder eine bösartige Website mit einem vollkommen gültigen Zertifikat – all dies liegt außerhalb des Wirkungsbereichs von HTTPS. Ein Vorhängeschloss bestätigt, dass die Verbindung verschlüsselt ist und das Zertifikat gültig ist; es sagt jedoch nichts über die Absichten der Person am anderen Ende aus.
Wann einfaches HTTP noch akzeptabel ist
Einfaches HTTP ist nicht grundsätzlich falsch. Es gibt zwar noch einige wenige legitime Fälle mit geringem Risiko, doch der Spielraum für eine uneingeschränkte Empfehlung wird immer kleiner.
Nicht sensible, interne oder isolierte Kontexte
Interne Tools und lokale Entwicklung, bei denen keine privaten Daten weitergegeben werden, können ohne große Bedenken über HTTP laufen. Der Datenverkehr zu Ihrem eigenen Rechner verlässt das Netzwerk nicht, sodass Sie sich keine Sorgen um mögliche Abhörversuche machen müssen. Aus diesem Grund sind Domain-Validated-Zertifikate – die einfachste und am schnellsten ausstellbare Art von Zertifikaten – eher für private oder interne Websites gedacht als für öffentliche, datenerfassende Unternehmenswebsites.
Es gibt auch einen prinzipiellen Aspekt, bei dem HTTP von Grund auf korrekt ist. Manche signierte Objekte verfügen über eine eigene Integrität, unabhängig davon, wie sie übertragen werden; daher ist ihre Bereitstellung über HTTP eher beabsichtigt als eine Abkürzung. Und bestimmte Bootstrap-Schritte, wie beispielsweise die anfängliche Weiterleitung von einer „http://“-Adresse zu „https://“, müssen über Port 80 erfolgen, bevor eine sichere Verbindung besteht.
Warum der Begriff „akzeptabel“ an Bedeutung verliert
Die Liste der zulässigen HTTP-Fälle wird aus guten Gründen immer kürzer. Browser kennzeichnen reines HTTP nun standardmäßig als „nicht sicher“, unabhängig vom Inhalt. Zertifikate sind mittlerweile kostenlos und werden über das ACME-Protokoll automatisch erneuert, das mittlerweile von mehreren PKI-Plattformen wie EJBCA umfassend unterstützt wird, sodass die alte Ausrede, Zertifikate seien teuer oder müssten manuell verwaltet werden, nicht mehr zutrifft. Zudem ist die Annahme eines „vertrauenswürdigen internen Netzwerks“ heute weniger stichhaltig als früher, da nach dem Zero-Trust-Ansatz kein Standort im Netzwerk mehr als von Natur aus sicher gilt. Für alles, was öffentlich ist oder mit Nutzerdaten umgeht, ist HTTPS der Standard und die erwartete Wahl.
Wie Keyfactor helfen Keyfactor
HTTPS funktioniert nur, wenn die zugrunde liegenden Zertifikate gültig und vertrauenswürdig sind – und genau damit haben viele Unternehmen Schwierigkeiten. Der Druck nimmt zu: Das CA/Browser Forum hat beschlossen, die Gültigkeitsdauer von Zertifikaten bis 2026 auf maximal 200 Tage, bis 2027 auf 100 Tage und bis 2029 auf nur noch 47 Tage zu verkürzen. Wird eine Verlängerung versäumt, kann eine Website ausfallen, Nutzer verlieren das Vertrauen und Ihre Sicherheitslage leidet darunter. Eine manuelle Nachverfolgung lässt sich bei diesem Tempo nicht skalieren.
Keyfactor Hilft Teams dabei, alle Websites ohne Ausfälle über HTTPS zu betreiben. EJBCA bietet die Plattform zur Erstellung der Zertifikate, auf die TLS angewiesen ist, während Bouncy Castle einen vollständigen TLS -Stack für Entwickler bereitstellt. Im Bereich der Erkennung identifiziert AgileSec kryptografische Ressourcen und Zertifikate in Ihrer gesamten Umgebung, sodass nichts in einem toten Winkel verborgen bleibt. Keyfactor Command verwaltet Zertifikate unternehmensweit, verfolgt Ablaufdaten und automatisiert die Bereitstellung und Erneuerung, sodass die unkontrollierte Verbreitung zahlreicher Zertifikate und unerwartete Ablaufdaten der Vergangenheit angehören. Zusammen decken sie die Automatisierung des Zertifikatslebenszyklus, PKI und die Erkennung kryptografischer Ressourcen ab und helfen Teams dabei, sich im Zuge der Weiterentwicklung der Standards auf die Post-Quantum-Sicherheit vorzubereiten.
Haben Sie Fragen zu HTTP und HTTPS? Wir haben die Antworten.
Was ist der Hauptunterschied zwischen HTTP und HTTPS?
HTTP überträgt Daten im Klartext über Port 80, sodass sie abgefangen und gelesen werden können. HTTPS nutzt eine Verschlüsselung über Port 443, wodurch die Daten verschlüsselt werden, sodass nur der vorgesehene Server und Browser sie lesen können. HTTPS authentifiziert zudem die Identität des Servers.
Ist HTTPS einfach nur HTTP mit Verschlüsselung?
HTTPS ist HTTP, das über eine verschlüsselte, authentifizierte Verbindung übertragen wird. Diese Ebene sorgt für Vertraulichkeit, Serverauthentifizierung und Datenintegrität – allesamt Eigenschaften, die reines HTTP nicht bietet.
Wie kann ich feststellen, ob eine Website HTTPS verwendet?
Schauen Sie in die Adressleiste. Die URL einer sicheren Website beginnt mit „https“ und zeigt ein Vorhängeschloss-Symbol an. Wenn Sie auf das Vorhängeschloss klicken, können Sie die Zertifikatsdetails der Website einsehen.
Warum warnen mich Browser vor HTTP-Seiten?
Weil Daten über HTTP abgefangen und im Klartext gelesen werden können. Browser wie Chrome verwenden mittlerweile standardmäßig HTTPS und kennzeichnen unsichere Seiten, um Nutzer vor Abhörversuchen und Phishing zu schützen.
Verbirgt HTTPS alles, was ich online tue?
Nein. HTTPS verschlüsselt zwar den Inhalt Ihrer Anfragen, doch Details wie die Ziel-IP-Adresse, die von Ihnen besuchte Domain sowie Umfang und Zeitpunkt des Datenverkehrs können weiterhin sichtbar sein. Außerdem kann es ein Gerät nicht schützen, das bereits kompromittiert wurde.
Ist es jemals in Ordnung, einfaches HTTP zu verwenden?
Für isolierte interne Tools oder die lokale Entwicklung, bei denen keine sensiblen Daten verarbeitet werden, kann HTTP akzeptabel sein. Für jede öffentliche Website oder eine Website, die Nutzerdaten erfasst, ist HTTPS der Standard und die erwartete Wahl.
Hilft HTTPS bei der Suchmaschinenoptimierung (SEO)?
Ja. HTTPS ist ein positives Ranking-Signal, und ein gültiges Zertifikat stärkt das Vertrauen der Nutzer – beides trägt zur Sichtbarkeit in Suchmaschinen bei.
Was macht HTTPS vertrauenswürdig?
Ein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes „ SSL “- bzw. „TLS “-Zertifikat bestätigt die Identität der Website und ermöglicht die Verschlüsselung. Der Browser überprüft dieses Zertifikat anhand einer Vertrauenskette, die bis zu einer vertrauenswürdigen Stammzertifizierungsstelle zurückreicht.
