HTTPS und SSL: Warum alte Websites oft noch unsicher übertragen

Noch immer gibt es Websites und Webanwendungen, die Daten unverschlüsselt über HTTP übertragen. Das klingt nach einem technischen Detail. Es ist keins. Eine alte Website ohne HTTPS ist ein offenes Buch für jeden, der zuhören will.

Dieser Artikel erklärt, was hinter dem Unterschied zwischen HTTP und HTTPS steckt, warum viele ältere Websites dieses Problem haben und was es Sie kostet, wenn Sie nichts tun.

Was ist HTTPS und was bedeutet SSL?

HTTP steht für "Hypertext Transfer Protocol". Es ist das Protokoll, über das Browser und Webserver miteinander kommunizieren. Das Problem: HTTP überträgt alles im Klartext. Passwörter, Formulardaten, Sitzungsinformationen.

HTTPS ist die gesicherte Variante. Das "S" steht für "Secure". Die Verbindung wird dabei über SSL (Secure Sockets Layer) oder das modernere TLS (Transport Layer Security) verschlüsselt. Wer den Datenverkehr abfängt, sieht nur unlesbaren Code.

Erkennbar ist der Unterschied am Browser: Eine HTTPS-Website zeigt ein Schloss-Symbol in der Adresszeile. Eine HTTP-Website wird von modernen Browsern oft mit einer Warnung markiert: "Nicht sicher."

Warum viele alte Websites noch auf HTTP laufen

Vor etwa zehn Jahren war HTTP der Standard. SSL-Zertifikate, die HTTPS erst ermöglichen, kosteten damals Geld und waren technisch aufwändig einzurichten.

Das hat sich geändert. Seit 2016 gibt es Let's Encrypt, eine kostenlose Zertifizierungsstelle. Ein SSL-Zertifikat kostet heute in vielen Fällen nichts. Die meisten Webhoster aktivieren HTTPS mit einem einzigen Klick.

Warum läuft dann noch so viel auf HTTP? Weil niemand hingeschaut hat. Wer seine Website vor 2015 gebaut hat und seitdem nicht aktiv betreut, hat das Problem möglicherweise nie bemerkt. Oder er hat es bemerkt und aufgeschoben.

Das ist menschlich. Aber es hat Konsequenzen.

Was bei einer HTTP-Website konkret passiert

Daten fließen unverschlüsselt

Jedes Formular, das über HTTP abgeschickt wird, sendet seine Daten im Klartext. Das gilt für Kontaktformulare, Login-Masken, Bestellformulare, Supportanfragen.

Wer im selben Netzwerk ist wie der Nutzer, kann diesen Datenverkehr mitlesen. Das ist in öffentlichen WLAN-Netzen besonders relevant. Kein Angreifer muss dabei besonders raffiniert sein. Entsprechende Werkzeuge sind frei verfügbar.

DSGVO-Pflichten werden verletzt

Die Datenschutz-Grundverordnung verlangt, dass personenbezogene Daten technisch angemessen geschützt werden. Eine Übertragung über HTTP ist nicht angemessen. Das haben Aufsichtsbehörden in mehreren Entscheidungen klargestellt.

Wer noch auf DSGVO-Risiken alter Software hingewiesen werden möchte: Die fehlende Verschlüsselung zählt zu den häufigsten Befunden bei Datenschutzprüfungen. Bußgelder wurden dafür verhängt. Auch gegen kleine Unternehmen.

Google straft HTTP ab

Google wertet HTTPS als Rankingfaktor. Websites ohne HTTPS werden in den Suchergebnissen schlechter platziert. Für viele Unternehmen ist das schmerzhafter als das direkte Sicherheitsrisiko.

Dazu kommt: Chrome, Firefox und Edge kennzeichnen HTTP-Seiten aktiv als "Nicht sicher". Wer eine solche Warnung auf seiner Website sieht, klickt oft weg. Das kostet Besucher, Anfragen und Umsatz.

Wer ist betroffen?

Nicht nur Unternehmenswebsites. Auch Webanwendungen, Kundenportale, Extranetlösungen und interne Tools, die über den Browser erreichbar sind.

Viele ältere PHP-Anwendungen wurden ohne HTTPS gebaut. Die Infrastruktur dahinter hat sich nie geändert, weil die Anwendung "noch läuft". Dabei ist der Aufwand für eine Umstellung oft minimal.

Problematisch wird es, wenn die Anwendung selbst hartcodierte HTTP-URLs enthält. Dann reicht ein Zertifikat allein nicht aus. Die Anwendung muss angepasst werden, damit sie interne Links, Weiterleitungen und API-Aufrufe korrekt über HTTPS abwickelt. Das ist in der Regel kein großes Projekt, aber es braucht jemanden, der den Code kennt oder kennenlernt.

Wie sieht die Umstellung aus?

Der technische Ablauf ist überschaubar.

Schritt 1: SSL-Zertifikat besorgen. Bei den meisten Hostern ist Let's Encrypt inzwischen direkt integriert. Ein Klick genügt. Wer auf dedizierten Servern betreibt, richtet Certbot ein, ein kostenloses Werkzeug für Let's Encrypt.

Schritt 2: Webserver konfigurieren. Apache oder Nginx muss so eingestellt werden, dass HTTP-Aufrufe automatisch auf HTTPS umgeleitet werden. Das passiert per 301-Redirect, also einer dauerhaften Weiterleitung. Google und Browser folgen dieser Weiterleitung und behandeln die HTTPS-Version als Hauptadresse.

Schritt 3: Anwendung prüfen. Gibt es hartcodierte HTTP-Adressen im Code? Werden externe Ressourcen wie Schriften, Bilder oder Bibliotheken noch über HTTP geladen? Diese sogenannten "Mixed Content"-Fehler verhindern, dass der Browser das Schloss-Symbol anzeigt, selbst wenn ein Zertifikat vorhanden ist.

Schritt 4: Testen. Nach der Umstellung prüfen, ob alle Seiten korrekt über HTTPS geladen werden, ob es keine Weiterleitungsschleifen gibt und ob alle Formulare funktionieren.

Für eine einfache Website dauert das ein bis zwei Stunden. Bei einer komplexen Webanwendung mit viel eigenem Code kann es mehr sein. Das lässt sich erst nach einer Analyse des Systems sagen.

Was das mit dem Rest zusammenhängt

Eine fehlende HTTPS-Verschlüsselung ist selten das einzige Problem. Wer eine Website seit Jahren nicht aktiv betreut, hat in der Regel mehr als eine Baustelle. Veraltete PHP-Versionen, offene Sicherheitslücken in Abhängigkeiten, fehlende Backups: Das sammelt sich an.

Technische Schulden entstehen nicht durch eine einzige Entscheidung. Sie entstehen durch viele kleine Aufschiebungen. Das SSL-Zertifikat ist oft der sichtbarste, aber nicht der einzige Teil des Problems.

Wer wissen möchte, in welchem Zustand seine Website oder Webanwendung insgesamt ist, braucht eine strukturierte Bestandsaufnahme. Das ist der sinnvollste erste Schritt, bevor man einzelne Punkte angehen kann.

Was Sie jetzt tun sollten

Prüfen Sie zunächst, ob Ihre Website bereits HTTPS nutzt. Rufen Sie die Adresse im Browser auf und schauen Sie auf das Symbol links in der Adresszeile. Kein Schloss oder ein Warnzeichen ist ein eindeutiges Signal.

Wenn Ihre Website über HTTP läuft, lohnt sich der Kontakt zum Hoster. In vielen Fällen lässt sich HTTPS dort direkt aktivieren, ohne Entwicklerarbeit. Wenn die Anwendung älter ist und eigenen Code enthält, sollte jemand mit technischem Verständnis die Umstellung begleiten. Damit die Umstellung korrekt läuft und keine Nebeneffekte entstehen.

Wir helfen bei der Software-Wartung genau solcher Systeme. Wir schauen uns an, was vorhanden ist, und sagen Ihnen ehrlich, was als nächstes sinnvoll ist.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.