Chrome: Witryna korzysta z HSTS. Błędy sieciowe… ta strona prawdopodobnie będzie działać później

Rozwijam się przeciwko localhost. Dziś rano zaraz po użyciu Fiddlera zacząłem otrzymywać ten błąd na chrome (działa poprawnie w firefox)

„Nie możesz teraz odwiedzić localhost, ponieważ witryna korzysta z HSTS. Błędy sieciowe i ataki są zwykle tymczasowe, więc ta strona prawdopodobnie będzie działać później”.

Teraz localhost działa w chrome tylko wtedy, gdy uruchomiony jest program Fiddler. Upewniłem się już, że przekierowania proxy, które wykonuje skrzypek, są poprawiane, gdy skrzypek się wyłącza.

Próbowałem też zaimportować certyfikat do mojego zaufanego katalogu głównego i ponownie uruchomić przeglądarkę (a także komputer).

Jednym z bardzo szybkich sposobów obejścia tego problemu jest wyświetlenie ekranu „Twoje połączenie nie jest prywatne”:

rodzaj badidea

typ thisisunsafe(kredyt dla The Java Guy za znalezienie nowego hasła)

Umożliwi to wyjątek bezpieczeństwa, gdy Chrome w innym przypadku nie zezwala na ustawienie wyjątku za pomocą kliknięcia, np. Dla tego przypadku HSTS.

Jest to oczywiście zalecane tylko dla połączeń lokalnych i maszyn wirtualnych w sieci lokalnej, ale ma tę zaletę, że działa na maszynach wirtualnych używanych do programowania (np. W połączeniach lokalnych z przekierowaniem portów), a nie tylko w przypadku bezpośrednich połączeń z hostem lokalnym.

Uwaga: programiści Chrome zmienili to hasło w przeszłości i mogą to zrobić ponownie. Jeśli badideaprzestanie działać, zostaw tutaj notatkę, jeśli nauczysz się nowego hasła. Spróbuję zrobić to samo.

Edycja: od 30 stycznia 2018 r. To hasło wydaje się już nie działać.

Jeśli uda mi się znaleźć nowy, opublikuję go tutaj. W międzyczasie poświęcę trochę czasu na skonfigurowanie certyfikatu z podpisem własnym za pomocą metody opisanej w tym poście stosu:

Jak utworzyć certyfikat z podpisem własnym za pomocą openssl?

Edycja: od 1 marca 2018 r. I wersji Chrome 64.0.3282.186 to hasło działa ponownie dla bloków związanych z HSTS w witrynach .dev.

Edycja: od 9 marca 2018 r. I wersji Chrome 65.0.3325.146 badideahasło już nie działa.

Edycja 2: problem z samopodpisanymi certyfikatami wydaje się polegać na tym, że wraz ze zacieśnianiem się standardów bezpieczeństwa w dzisiejszych czasach, powodują one wyrzucanie własnych błędów (na przykład nginx odmawia załadowania certyfikatu SSL / TLS, który zawiera certyfikat z podpisem własnym w łańcuchu uprawnień, domyślnie).

Rozwiązaniem, które teraz wybieram, jest zamiana domeny najwyższego poziomu we wszystkich moich witrynach programistycznych .app i .dev na .test lub .localhost. Chrome i Safari nie będą już akceptować niezabezpieczonych połączeń ze standardowymi domenami najwyższego poziomu (w tym .app).

Bieżącą listę standardowych domen najwyższego poziomu można znaleźć w tym artykule w Wikipedii, w tym domeny specjalnego użytku:

Wikipedia: Lista internetowych domen najwyższego poziomu: domeny specjalnego przeznaczenia

Wydaje się, że te domeny najwyższego poziomu są zwolnione z nowych ograniczeń dotyczących tylko https:

• .lokalny
• .Lokalny Gospodarz
• .test
• (dowolna niestandardowa / niestandardowa domena najwyższego poziomu)

Zobacz odpowiedź i link od codinghands do oryginalnego pytania, aby uzyskać więcej informacji:

odpowiedź z rąk kodujących

Kiedy odwiedzałeś https: // localhost wcześniej w pewnym momencie, nie tylko odwiedził to przez bezpieczny kanał (https zamiast http), ale także poinformował przeglądarkę, używając specjalnego nagłówka HTTP: Strict-Transport-Security (często w skrócie HSTS ), że powinien używać TYLKO protokołu https do wszystkich przyszłych wizyt.

Jest to funkcja bezpieczeństwa, której serwery internetowe mogą używać, aby zapobiec obniżeniu statusu użytkowników do http (celowo lub przez złą stronę).

Jeśli jednak następnie wyłączysz serwer https i po prostu zechcesz przeglądać http, nie możesz (zgodnie z projektem - o to chodzi w tej funkcji bezpieczeństwa).

HSTS zapobiega również akceptowaniu i pomijaniu poprzednich błędów certyfikatów.

Aby to zresetować, aby HSTS nie był już ustawiony na hosta lokalnego, wpisz następujące polecenie w pasku adresu Chrome:

chrome://net-internals/#hsts

Gdzie będziesz mógł usunąć to ustawienie dla „localhost”.

Możesz także chcieć dowiedzieć się, co to ustawiało, aby uniknąć tego problemu w przyszłości!

Zwróć uwagę, że w przypadku innych witryn (np. Www.google.com) są one „wstępnie załadowane” do kodu Chrome, więc nie można ich usunąć. Po zapytaniu o nie na chrome: // net-internals / # hsts zobaczysz je na liście jako staticwpisy HSTS.

Na koniec zauważ, że Google rozpoczął wstępne ładowanie HSTS dla całej domeny .dev: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

Kliknij w dowolnym miejscu okna chrome i wpisz thisisunsafe(zamiast badideawcześniej) w chrome.

To hasło może się zmienić w przyszłości. To jest źródło

https://chromium.googlesource.com/chromium/src/+/master/components/security_interstitials/core/browser/resources/interstitial_large.js#19

Zgodnie z tą linią wpisz window.atob('dGhpc2lzdW5zYWZl')w konsoli przeglądarki, a otrzymasz aktualne hasło.

Tym razem hasło to thisisunsafe.

Miałem ten problem z witrynami działającymi na XAMPP z prywatnymi nazwami hostów. Okazuje się, że nie tak prywatnie! Były to wszystkie domain.dev, które Google zarejestrował teraz jako prywatny gTLD i wymusza HSTS na poziomie domeny. Zmieniono każdy wirtualny host na .devel(eugh), zrestartowałem Apache i wszystko jest teraz w porządku.

Niedawno miałem ten sam problem podczas próby dostępu z wykorzystaniem domen CloudFlare Origin CA .

Jedynym sposobem obejścia / uniknięcia wyjątku certyfikatu HSTS w przeglądarce Chrome (kompilacja systemu Windows) było postępowanie zgodnie z krótkimi instrukcjami na stronie https://support.opendns.com/entries/66657664 .

Obejście:
dodaj do Chrome skrót flagi --ignore-certificate-errors, a następnie otwórz ją ponownie i przejdź do swojej witryny.

Przypomnienie:
używaj go tylko do celów programistycznych.

Widzę, że jest tu wiele przydatnych odpowiedzi, ale mimo to natrafiam na przydatny artykuł. https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

Natknąłem się na ten sam problem i ten artykuł pomógł mi dowiedzieć się, czym dokładnie jest i jak sobie z tym poradzić :-)

Napotkano podobny błąd. resetowanie chrome: // net-internals / # hsts nie działa dla mnie. Problem polegał na tym, że zegar mojej maszyny wirtualnej był przekrzywiony o dni. resetowanie czasu pomogło rozwiązać ten problem. https://support.google.com/chrome/answer/4454607?hl=en

Napotykam ten sam błąd, a tryb incognito również ma ten sam problem. Rozwiązuję ten problem, usuwając historię Chrome.

Cierpię z powodu tego problemu od bardzo dawna. Nie mogłem otwierać witryn takich jak GitHub. Prawie wypróbowałem wszystkie odpowiedzi w Internecie i nikt nie działał. Próbowałem również ponownie zainstalować chrome. Znalazłem rozwiązanie tego problemu od naszego operatora sieci i zadziałało. W rejestrze jest poprawka, która na stałe usunie ten błąd.

1. Naciśnij klawisz Windows + R , aby otworzyć okno dialogowe uruchamiania
2. wpisz: regedit i naciśnij Enter, aby otworzyć rejestr
3. W widoku drzewa po lewej stronie kliknij następującą ścieżkę HKEY_LOCAL_MACHINE> OPROGRAMOWANIE> ZASADY> Microsoft> Certyfikat systemu> Authroot
4. Teraz kliknij dwukrotnie DisableRootAutoUpdate po prawej stronie i ustaw na 0 (zero) w wyświetlonym oknie dialogowym
5. Uruchom ponownie komputer, aby zastosować zmiany w rejestrze, a ten błąd nie będzie już wyświetlany

Powyższe rozwiązanie dotyczy systemu Windows 8. Jest prawie identyczne w nowszych wersjach, ale nie jestem pewien, czy dotyczy to starszych wersji, jak XP i Vista. Więc to musi być sprawdzone.