Chrome wird ab Oktober 2026 sicherer: Google kündigt HTTPS-Zwang an
von caschy | 11 Kommentare
Google hat eine Änderung für den Chrome-Browser angekündigt, die allerdings noch etwas auf sich warten lässt. Ab Oktober 2026 wird Chrome standardmäßig nur noch verschlüsselte HTTPS-Verbindungen zulassen. Die Funktion „Immer sichere Verbindungen verwenden“ wird dann für alle mehr als 3 Milliarden Chrome-Nutzer automatisch aktiviert. Der Browser wird künftig bei jedem Versuch, eine unverschlüsselte Website aufzurufen, eine Warnung anzeigen und nach einer Bestätigung fragen. Das ist durchaus sinnvoll, denn bei unverschlüsselten HTTP-Verbindungen können Angreifer die Kommunikation zwischen Browser und Webserver abfangen oder manipulieren. Die gute Nachricht: Man muss nicht bis Ende 2026 warten. Die Option gibt es schon jetzt in den Chrome-Einstellungen unter „Datenschutz und Sicherheit“. Wer auf Nummer sicher gehen will, sollte sie gleich aktivieren:
Erinnerung: Trotzdem ist auch mit aktiviertem HTTPS Vorsicht geboten. Auch Betrüger und Cyberkriminelle nutzen verschlüsselte Verbindungen für ihre Machenschaften. Eine verschlüsselte Verbindung bedeutet also nicht automatisch, dass eine Website vertrauenswürdig ist.
![OOONO CO-Driver NO2 [NEUES Modell 2025] - Optimierter CO-Driver fürs Auto - Warnt vor Tempo-Kontrollen und...](https://m.media-amazon.com/images/I/41hrZMibdrL._SL160_.jpg)
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Leider hat die Einstellung keine Ausnahmelist.
Meine Fritzbox für VoIP wird auf absehbare Zeit kein Zertifikat bekommen, meine OpenWRT-Router und APs auch nicht.
Mein Denon AVR-X2600H hat schon immer ein Zertifikat und leitet HTTP auch grundsätzlich auf HTTPS Port 10443 weiter (!?), aber mit Gültigkeit seit 2019, bis 2069 und ohne Domain-Nennung, sodass jeder vernünftige Browser selbst mit aktuellen Einstellungen diese Verbindung erst mal ablehnt.
Wenn wir einen Schritt weiter zum IoT-Krempel gehen, kann man heute mit entsprechendem Aufwand ein paar Produkte finden, die ab der Anschaffung ohne Cloud-Zwang und ohne chinesische oder amerikanische Server auskommen. Das wir dann ja auch ne ganze Ecke unbequemer, wenn das auf dem RPi laufende Verwaltungstool meiner Wahl vor jedem Login erst ein „thisisunsafe“ von mir verlangt.
Es wäre schön, wenn man künftig bestimmte Domains, Hostnames und IP-Adressen vom Zertifikatszwang ausschließen könnte oder bekannte defekte Zertifikate zulassen, egal wie weit sie von Gültigkeit entfernt sind.
Meine Fritzbox und auch mein OpenWRT-Router haben beide ein self-signed Zertifikat. Ich greife allerdings nur via Reverse Proxy mit einem vertrauenswürdigen Wildcard Domain Zertifikat darauf zu. Selbst wenn man keine Domain hat, kann man immer noch einfach xyz.internal nutzen mit einem self-signed CA Zertifikat, das dann natürlich einmalig auf den Endgeräten im trust store hinterlegt werden muss. Den Rest regelt dann auch der Reverse Proxy.
Es wird sicherlich eine Menge alter, noch funktionierender Hardware treffen. So gibt es noch putzmuntere Drucker, mit entsprechendem Alter, die ohne Zertifikat daher kommen.
Das wird ein großer Spaß… Die Idee dahinter kann man nachvollziehen, aber es gibt doch in freier Wildbahn eigentlich praktisch keine relevanten Seiten mehr, die ohne https daher kommen. Der Zwang von Google erscheint mir daher übereifrig.
Ergänzung: Offensichtlich geht Google das Thema recht schlau an. Vom https Zwang sind interne Dienste (also im privaten IP-Bereich) ausgeschlossen. Daher wird es kein Problem sein, alte Geräte mit Web-Interface ohne https-Unterstützung zu nutzen. Außerdem scheint man auch Ausnahmen erstellen zu können. Siehe den Artikel auf Heise.
Das ergibt überhaupt keinen Sinn.
Seit LetsEncrypt läuft praktisch das gesamte WWW sowieso unter https. Sehr selten trifft man noch auf alte Seiten, und dann gibt es ja noch die lokalen „Dinge“ wie Router, DSL-Modem, Sharing-App auf dem Handy,…
…es macht also überhaupt keinen Sinn, wegen der paar Exoten gleich das ganze Protokoll zu crashen. Kein Mensch braucht https im Intranet. Wer soll mich attackieren? Meine Frau? Unser Hamster?
Ein roter Locationbar hätte vollkommen gereicht.
Wer soll einen im lokalen Netzwerk attackieren? Na zum Beispiel die unzähligen IoT-Devices mit veralteter Software.
Alles zu verschlüsseln hat schon seinen Sinn. Im schlechtesten Fall kommt halt eine Zertifikatswarnung, aber Hauptsache HTTPS.
> Wer soll einen im lokalen Netzwerk attackieren? Na zum Beispiel die unzähligen IoT-Devices mit veralteter Software.
Das ist einfach technisch falsch.
Wenn ich per http mit meinem Gerät A auf Gerät B zugreife, hat irgendein anderes IoT-Gerät damit überhaupt nichts zu tun. Die Daten kommen daran schlicht nicht vorbei.
Ausnahme 1: Gerät B -ist- das infizierte IoT-Device, in dem Fall gibt es keinen Unterschied zwischen http und https, das Gerät bekommt ja als legitimer Empfänger den Request entschlüsselt oder darf ungehindert Exploits in die Response packen. Es agiert so bösartig, wie es nur will, ohne dass https eine Rolle spielen würde.
Ausnahme 2: Das böse Gerät ist dein Router, dein WLAN-Range-Extender, dein Hub,… in diesem Fall hat „Team Böse“ eh komplett die Hand unter’m Rock deines Netzwerkes, da brauchen wir über https nicht mehr reden, Du hast verloren. Das Device kann aktiv alle Gerät attackieren, spoofen, Code nachladen, 0-Days abfeuern…
In allen Fällen passiert entweder gar nichts, ODER dein Netz ist bereits dermaßen kompromittiert, dass https kein sinnvolles Szenario mehr darstellt.
Interessant wie da die Welten auseinander gehen, mein ganzes Intranet läuft jetzt schon über https von lets-encyprt. Damit sind dann auch alle nervigen Warnungen über self-signed etc weg.
Bei uns daheim sind im Moment ca. 60 Geräte im Einsatz, ein Großteil davon hat irgendeine Art Weboberfläche. Was von Außen erreichbar sein soll, hat natürlich eine Subdomain und https über Reverseproxy.
Das für den Rest von dem Zeug, der auch noch oft geändert wird, intern zu pflegen, habe ich 1. keine Lust und 2. halte ich für übertrieben.
Sollte ich irgendwann eine Art von Verfolgungswahn vor „IoT-Devices mit veralteter Software“ entwickeln, würde ich sie als erstes in ein separates VLan packen und nicht per https absichern.
Mir die Möglichkeit zu verwehren, solche Dinge eigenverantwortlich mit einer Ausnahmenliste zu regeln halte ich übrigens für eine ziemliche Unverschämtheit.
Zwei kleine, feine Ergänzungen anhand von laut https://security.googleblog.com/2025/10/https-by-default.html:
Die Warnungen gelten nur bei „public sites“, also eben nicht irgendein IoT-Gerät im privaten Netzwerk.
Und die Warnungen gibt es bereits im April 2026 für Leute, die in ihrem Chrome-Profil das „Enhanced Safe Browsing“ aktiviert haben – was laut Google rund eine Milliarde Menschen sein sollen.
Danke. Und so ergibt das auch einen Sinn.