Google hat in Chrome die Funktion „Immer sichere Verbindungen verwenden" für alle Nutzer aktiviert. Wer eine unverschlüsselte HTTP-Adresse zum ersten Mal aufruft, sieht jetzt einen Berechtigungsdialog, bevor der Browser die Verbindung aufbaut. Chrome sichere Verbindungen sind damit keine Option für besonders vorsichtige Anwender mehr, sondern Voreinstellung – mit Folgen für alle, die alte Intranet-Seiten, Geräteoberflächen oder Nischenportale ohne TLS erreichen müssen. Eine Schwachstelle steckt nicht dahinter, eine CVE-Nummer gibt es nicht: Die Änderung ist eine Sicherheitsfunktion.
Wie Chrome sichere Verbindungen vor dem Handshake prüft
Der Dialog erscheint nicht nach dem Seitenaufbau, sondern davor. Chrome fragt vor dem Verbindungsaufbau, ob die unsichere Verbindung überhaupt zustande kommen soll, und wartet die Antwort ab; erst danach geht die erste Anfrage an den Server. Chrome-Produktmanager Eric Trouton und Engineering-Manager Joe DeBlasio bestätigen den Ablauf zum Start der Funktion.
Stimmt der Nutzer zu, merkt sich Chrome die Entscheidung zwei Wochen lang. Nach Ablauf dieser Frist fragt der Browser erneut nach.
Ausgenommen sind lokale Ziele: Single-Label-Hostnamen wie http://drucker, localhost und lokale IP-Adressen lösen keinen Dialog aus. Wer eine Geräteoberfläche über die IP-Adresse anspricht statt über einen DNS-Namen, merkt von der Änderung nichts. Google bezeichnet Chrome als ersten Browser, der diese Funktion standardmäßig aktiviert hat.
Warum Google die passive Warnung aufgibt
Bisher hat Chrome unsichere Seiten nur markiert: In der Adressleiste stand „Nicht sicher", der Rest blieb beim Alten. Google begründet den Wechsel mit den Grenzen genau dieses Badges – es informiere, halte aber niemanden auf. Erst der Dialog verlange eine Entscheidung, bevor Daten über eine unverschlüsselte Leitung gehen.
Wie groß der Kreis ist, macht die Ankündigung deutlich: Im Oktober 2025 war von über einer Milliarde betroffener Chrome-Nutzer die Rede. Der Schritt fällt in eine Entwicklung, die Google über Jahre gemessen hat: Lag die HTTPS-Verbreitung bei öffentlichen Websites 2015 bei 30 bis 45 Prozent, nennt der Konzern für die Zeit um 2020 Werte von 95 bis 99 Prozent. HTTP ist damit ein Randfall – einer, der jetzt Reibung erzeugt statt nur einen Hinweis.
Chrome 154 oder 155: der Versionsstand bleibt offen
Google hat die Standardeinstellung in seinem Grundsatzpost „HTTPS by default" an Chrome 154 gekoppelt und Oktober 2026 als Zeitpunkt genannt. Mit Chrome 155 ist die Funktion jetzt standardmäßig an Bord. Eine Erklärung für die Abweichung liefert keine der beiden Angaben.
Die ursprüngliche Planung war gestaffelt: Chrome 147 sollte die Funktion im April 2026 zunächst für Nutzer mit erweitertem Safe-Browsing aktivieren, Chrome 154 sie im Oktober 2026 zum Standard für alle machen. Wer ein Rollout-Fenster für Change-Logs oder Freigaben braucht, sollte die Versionsnummer in den Release-Notes der eigenen Installation prüfen, statt sich auf eine der beiden Angaben zu verlassen.
Was HTTP-Betreiber und Admins zu spüren bekommen
Für Websites ohne TLS ändert sich nicht die Technik, sondern die Zugänglichkeit. Der erste Besuch kostet einen zusätzlichen Klick, wiederkehrende Besucher alle zwei Wochen erneut. Wer eine HTTP-Seite als Login, Formular oder Wissensdatenbank betreibt, verliert den Selbstläufer, den das passive Badge jahrelang erlaubt hat.
Für Admins zählt die Ausnahmeliste: Solange ein interner Dienst über eine lokale IP-Adresse oder einen Namen ohne Punkt erreichbar ist, greift der Dialog nicht. Läuft das Ziel über einen DNS-Namen mit Punkt, fragt Chrome nach. Wie stark das stört, hängt davon ab, wie viele Geräteoberflächen, Monitoring- oder Verwaltungsseiten im eigenen Netz nur per Hostname erreichbar sind.
Abschalten und die übrigen Neuerungen im Update
Chrome lässt sich die Funktion wieder abgewöhnen: Sie ist in den Einstellungen deaktivierbar. Die Menübezeichnung unterscheidet sich je nach Sprache und Chrome-Version; Admins sollten den Schalter auf dem eigenen Client suchen, statt einer Anleitung aus einer fremdsprachigen Oberfläche zu folgen.
Chrome 155 bringt außerdem einen Schutz gegen ClickFix-Angriffe und eine Betrugserkennung für Gemini mit.
Fazit
Die Änderung verschiebt die Beweislast: Nicht der Browser muss warnen, sondern der Nutzer muss der unsicheren Verbindung zustimmen. Für Nutzer heißt das mehr Klicks im Ausnahmefall, für Betreiber ohne TLS ein spürbarer Nachteil bei jedem Erstbesuch. Wer noch HTTP-Dienste im Netz hat, sollte jetzt prüfen, welche davon über einen Hostnamen erreichbar sind, und für diese ein TLS-Zertifikat nachrüsten – oder den Zugriff bewusst über lokale Adressen und die dokumentierten Ausnahmen führen.