Chrome domyślnie włączy HTTPS dla publicznych stron. Co to oznacza dla użytkowników i administratorów?

Wprowadzenie do problemu / definicja zmiany

Google zapowiedział, iż Chrome domyślnie włączy tryb „Always Use Secure Connections” (HTTPS-First) dla wszystkich użytkowników na publicznych stronach. Oznacza to, iż przy pierwszym wejściu na witrynę bez HTTPS przeglądarka wyświetli ostrzeżenie i poprosi o świadome potwierdzenie przejścia po niezabezpieczonym HTTP. Zmiana wejdzie globalnie wraz z Chrome 154 w październiku 2026 r., a wcześniej – od Chrome 147 w kwietniu 2026 r. – obejmie użytkowników z włączoną Enhanced Safe Browsing. Zapowiedź padła 28 października 2025 r. na oficjalnym blogu Google Security.

W skrócie

• Kiedy? Zapowiedziano 28.10.2025; ESB: od Chrome 147 (04.2026); wszyscy: od Chrome 154 (10.2026).
• Co się zmienia? Chrome domyślnie będzie wymuszał HTTPS dla publicznych domen; przy braku HTTPS pokaże ostrzeżenie z możliwością obejścia.
• Dlaczego? Mimo ~95–99% ruchu po HTTPS, pojedyncza nawigacja po HTTP wystarczy, by atakujący przejął ruch lub wstrzyknął treść.
• Wyjątki? Niższy rygor dla prywatnych adresów/LAN (mniejsze ryzyko, inne ścieżki nadużyć).

Kontekst / historia / powiązania

„HTTPS-First Mode” pojawił się jako opcja już w 2022 r., a w 2023 r. zarysowano drogę do „HTTPS by default” (automatyczne upgrade’y HTTP→HTTPS, ostrzeżenia dla niebezpiecznych pobrań, domyślnie w trybie Incognito). Celem od lat jest „secure-by-default” w Chrome.

Analiza techniczna / szczegóły zmiany

• Tryb domyślny: Chrome próbuje nawiązać połączenie po HTTPS; jeżeli brak wsparcia, wyświetla ostrzeżenie typu interstitial z możliwością manualnego kontynuowania przez HTTP. To dotyczy „public sites” (np. example.com).
• Widoczność ryzyka: Problemem jest nie tylko trwały HTTP, ale też „niewidoczne” przekierowania: wejście po HTTP, które natychmiast przenosi na HTTPS – użytkownik nie widzi statusu „Not Secure”, choć pierwsza nawigacja była podatna na przejęcie.
• Telemetria/efekt ostrzeżeń: W eksperymencie (Chrome 141) mediana użytkowników widziała <1 ostrzeżenia/tydzień, a 95. percentyl <3/tydzień; oczekuje się dalszego spadku po migracjach do HTTPS.
• Prywatne adresy (LAN): Największy udział HTTP dotyczy prywatnych nazw/adresów (np. 192.168.0.1, router.local). Dla nich ryzyko bywa niższe (atak zwykle wymaga obecności w tej samej sieci), dlatego Chrome wyłącza ostrzeżenia w wariancie „public sites only”.
• LNA (Local Network Access): Aby odblokować migrację do pełnego HTTPS na stronach, które muszą rozmawiać z urządzeniami LAN (i dotąd wpadały w mixed content), Google wprowadza nowe uprawnienie Local Network Access oraz zwolnienia z blokad mixed content dla wybranych przypadków (.local, prywatne IP, targetAddressSpace: "local").

Praktyczne konsekwencje / ryzyko

• Użytkownicy końcowi: Rzadziej trafią na niezauważone HTTP. Zamiast cichego „Not Secure” w pasku adresu dostaną jasne ostrzeżenie i wybór. To redukuje ryzyko MITM, injection, phishingu z przejęciem nawigacji.
• Właściciele serwisów publicznych: Strony bez HTTPS (lub z błędną konfiguracją, np. luki w przekierowaniach) od 10.2026 zaczną generować twarde ostrzeżenia – ryzyko spadku ruchu/konwersji i utraty reputacji.
• Admini/Producenci urządzeń: Panele konfiguracyjne w LAN i aplikacje www korzystające z HTTP do urządzeń lokalnych powinny sprawdzić zachowanie z LNA oraz rozważyć certyfikaty (gdzie to możliwe) lub adekwatne adnotacje w żądaniach.

Rekomendacje operacyjne / co zrobić teraz

Dla właścicieli serwisów/publicznych aplikacji:

1. Włącz HSTS (z pre-load, jeżeli spełniasz kryteria), wymuś 301 z HTTP→HTTPS, wyczyść legacy linki http://.
2. Certyfikaty: automatyzuj odnowienia (ACME), waliduj łańcuchy, SNI/ALPN, obsługuj TLS 1.2+.
3. Content security: usuń mixed content, przypilnuj zasobów zewnętrznych (CDN, reklamy, fonty).
4. Monitoring: ściągawka alertów na HTTP 200 po porcie 80, 404/redirect loops po wymuszeniu HTTPS; testuj Lighthouse i skanery TLS.
5. Test „HTTPS-First” już dziś: włącz „Always use secure connections” w chrome://settings/security i sprawdź, czy nawigacje do Twojej domeny nie wywołują ostrzeżeń.

Dla aplikacji korzystających z urządzeń w LAN (IoT, MFP, routery, OT):

1. Przejrzyj dokument „Local Network Access” (LNA) i adnotacje (targetAddressSpace: "local").
2. W aplikacjach SPA/PWA z panelami do urządzeń lokalnych przetestuj LNA (Chrome 142+) i planowane zwolnienia z mixed content.
3. Dla krytycznych use-case’ów rozważ lokalne certyfikaty (np. własne CA korporacyjne) i/lub pre-grant przez polityki enterprise.

Dla zespołów IT / MDM (Chrome Enterprise):

• Przygotuj polityki (HttpAllowlist, HttpsOnlyMode, HttpsUpgradesEnabled, InsecureContentAllowedForUrls), zmapuj domeny wymagające wyjątków i komunikację do użytkowników przed 04–10.2026.

Różnice / porównania z innymi przypadkami

• Wcześniej (Chrome ≤141): HTTPS-First był opcjonalny; ostrzeżenia pojawiały się rzadziej, a HTTP bywał „niewidoczny” przy natychmiastowym redirectcie.
• Teraz: Podejście „public-sites by default” ogranicza uciążliwość dla developerów/korporacji pracujących z prywatnymi adresami, jednocześnie znacząco podnosi bezpieczeństwo zwykłych użytkowników.
• Firefox: Mozilla wcześniej komunikowała HTTPS-Only Mode jako kierunek – rynek zbiega się do tego samego modelu.

Podsumowanie / najważniejsze wnioski

Chrome przechodzi na „HTTPS domyślnie” dla publicznych stron, z ostrzeżeniami przy pierwszej nawigacji po HTTP. To zamyka jedną z ostatnich furt do ataków MITM/injection, a jednocześnie uwzględnia realia sieci prywatnych dzięki LNA i wyjątkom. Właściciele serwisów mają rok na pełną migrację do poprawnego HTTPS – inaczej użytkownicy zobaczą ostrzeżenia, a ruch/konwersje ucierpią.

Źródła / bibliografia

1. Google Online Security Blog — „HTTPS by default” (28.10.2025): ogłoszenie, timeline, metryki, wariant „public sites”. (Google Online Security Blog)
2. SecurityWeek — „Chrome to Turn HTTPS on by Default for Public Sites” (29.10.2025): omówienie zmiany i dat. (SecurityWeek)
3. Chromium Blog — „Towards HTTPS by default” (16.08.2023): kamienie milowe, upgrade HTTP→HTTPS, polityki enterprise. (Chromium Blog)
4. Chromium Blog — „Increasing HTTPS adoption” (14.07.2021): HTTPS-First Mode jako opcja, kierunek „secure-by-default”. (Chromium Blog)
5. Chrome for Developers — „New permission prompt for Local Network Access” (09.06.2025, aktual. 29.09.2025): LNA, zwolnienia z mixed content dla ruchu lokalnego. (Chrome for Developers)