Z jakiegoś powodu niektóre strony HTTPS przestały się dla mnie otwierać (nie wszystkie!). Podczas próby otwarcia takiej witryny w przeglądarce pojawia się okno z błędem „Ta witryna nie może zapewnić bezpiecznego połączenia”. Witryny się nie wyświetlają Google Chrome oraz w przeglądarce Opera i Yandex. Bez HTTPS otwierają się niektóre witryny, ale nie wszystkie, tylko te, których strony są dostępne zarówno przez HTTPS, jak i HTTP. W Google Chrome błąd podczas otwierania witryny HTTPS wygląda tak:
Ta witryna nie zapewnia bezpiecznego połączenia.
Witryna sitename.ru używa nieobsługiwanego protokołu.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Obsługa klienta i serwera różne wersje Protokół SSL i zestaw szyfrów. Najprawdopodobniej serwer używa szyfru RC4, który jest uważany za niepewny”.
W przeglądarce Opera i Yandex błąd wygląda podobnie. Jak mogę otworzyć takie strony?
Odpowiadać
Jak zapewne już się zorientowałeś, problem dotyczy problemów z komunikacją SSL między Twoimi komputerami a witryną HTTPS. Przyczyny tego błędu mogą być zupełnie inne. W tym artykule próbowałem zebrać wszystkie metody naprawy błędu „Ta witryna nie może zapewnić bezpiecznego połączenia” (ta witryna nie może zapewnić bezpiecznego połączenia, ERR_SSL_PROTOCOL_ERROR) w różnych przeglądarkach.
Chcę od razu zaznaczyć, że pomimo tego, że Przeglądarki Google Wydano przeglądarkę Chrome, Opera i Yandex różne firmy w rzeczywistości wszystkie te przeglądarki są oparte na tym samym silniku - Chrome i problem z błędami otwierania w nich witryn HTTPS jest rozwiązywany w ten sam sposób.
Przede wszystkim musisz upewnić się, że problem nie leży po stronie samej witryny HTTPS. Spróbuj otworzyć go z innych urządzeń (telefonu, tabletu, komputera w domu/pracy itp.). Sprawdź również, czy otwiera się w innych przeglądarkach, takich jak IE/Edge lub Mozilla Firefox. W Firefoksie podobny błąd został omówiony w artykule.
Wyczyść pamięć podręczną przeglądarki i pliki cookie, pamięć podręczną SSL
Pamięć podręczna przeglądarki i pliki cookie mogą być popularny przypadek błędy z certyfikatami SSL. Zalecamy, aby najpierw wyczyścić pamięć podręczną i pliki cookie w przeglądarce. W Chrome musisz nacisnąć skrót klawiaturowy Ctrl + Shift + Usuń, wybierz okres czasu ( Cały czas) i kliknij przycisk wyczyść dane ( Usunąć dane/Wyczyść dane).
Aby wyczyścić pamięć podręczną SSL w systemie Windows:
- Przejdź do sekcji Panel sterowania -> Właściwości przeglądarki;
- Kliknij na zakładkę Zawartość;
- Kliknij przycisk Wyczyść SSL (Wyczyść stan SSL);
- Powinien pojawić się komunikat „Pamięć podręczna SSL została pomyślnie wyczyszczona”;
- Pozostaje zrestartować przeglądarkę i sprawdzić, czy nadal występuje błąd ERR_SSL_PROTOCOL_ERROR.
Wyłącz rozszerzenia przeglądarki innych firm
Zalecamy wyłączenie (usunięcie) rozszerzenia stron trzecich przeglądarki, zwłaszcza wszelkich anonimizatorów, serwerów proxy, VPN, rozszerzeń antywirusowych i innych podobnych dodatków, które mogą zakłócać ruch do docelowej witryny. Listę rozszerzeń włączonych w Chrome możesz wyświetlić, przechodząc do Ustawienia -> Dodatkowe narzędzia -> Rozszerzenia, lub przechodząc do strony chrome://rozszerzenia/. Wyłącz wszystkie podejrzane rozszerzenia.
Sprawdź ustawienia antywirusa i zapory
Jeśli Twój komputer ma program antywirusowy lub zapora sieciowa(często jest wbudowany w program antywirusowy), możliwe jest, że dostęp do witryny jest przez nich blokowany. Aby zrozumieć, czy programy antywirusowe lub zapory sieciowe ograniczają dostęp do witryny, spróbuj tymczasowo zawiesić ich pracę.
W wielu nowoczesnych antywirusach domyślnie znajduje się moduł sprawdzania certyfikatów witryn SST/TLS. Jeśli program antywirusowy wykryje, że witryna korzysta z niewystarczająco bezpiecznego (lub) certyfikatu lub przestarzałej wersji protokołu SSL (tego samego), dostęp użytkownika do takiej witryny może zostać ograniczony. Spróbuj wyłączyć skanowanie ruchu HTTP/HTTPS i Certyfikaty SSL. Jak rozumiesz, wszystko zależy od zainstalowanego programu antywirusowego. Na przykład:
![](https://i0.wp.com/winitpro.ru/wp-content/uploads/2018/11/vklyuchit-filtraciyu-protokola-ssl-tls-eset-nod32.png)
Sprawdź ustawienia daty i godziny
Nieprawidłowa data i godzina (i ) na komputerze może również powodować błąd podczas nawiązywania bezpiecznego połączenia z witrynami HTTPS. Przecież podczas przeprowadzania uwierzytelniania system sprawdza datę utworzenia i datę wygaśnięcia certyfikatu witryny oraz wyższego urzędu certyfikacji.
Zaktualizuj certyfikaty główne systemu Windows
Jeśli Twój komputer znajduje się w odizolowanym segmencie, nie był aktualizowany od dłuższego czasu lub usługa jest na nim całkowicie wyłączona automatyczna aktualizacja, komputer może nie mieć nowych zaufanych certyfikatów głównych (TrustedRootCA). Zalecamy aktualizację systemu: zainstaluj Najnowsze aktualizacje bezpieczeństwo, w przypadku Windows 7 - pamiętaj, aby zainstalować SP1 () i aktualizacje stref czasowych ().
Możesz ręcznie zaktualizować certyfikaty główne, postępując zgodnie z artykułem: (zalecamy również, aby zapobiec przechwyceniu ruchu HTTPs i wielu innym problemom).
Wyłącz obsługę protokołu QUIC
Sprawdź, czy Chrome ma włączoną obsługę protokołów SZYBKO(Szybkie połączenia internetowe UDP). Protokół QUIC umożliwia znacznie szybsze otwieranie połączenia i negocjowanie wszystkich parametrów TLS (HTTP) podczas łączenia się z witryną. Jednak w niektórych przypadkach może powodować problemy z Połączenia SSL. Spróbuj wyłączyć QUIC:
- Idź do strony: chrome://flagi/#enable-quic;
- Znajdź opcję Eksperymentalny protokół QUIC;
- Zmień wartość opcji Domyślne na Wyłączone;
- Uruchom ponownie Chrome.
Włącz obsługę protokołów TLS i SSL
A najbardziej ostatni akapit- najprawdopodobniej do rozwiązania problemu wystarczy włączenie obsługi starszych wersji protokołów TLS i SSL. W większości przypadków będzie najskuteczniejszy, ale celowo przeniosłem to na koniec artykułu. Wyjaśnię dlaczego.
Stare wersje protokołów TLS i SSL są wyłączane nie tylko z powodu kaprysu programistów, ale ze względu na obecność dużej liczby luk, które pozwalają atakującym przechwycić Twoje dane w ruchu HTTPS, a nawet je zmodyfikować. Bezmyślne włączanie starych protokołów znacznie zmniejsza Twoje bezpieczeństwo w Internecie, więc ta metoda powinna być stosowana w ostateczności, jeśli wszystko inne zdecydowanie nie pomogło.
Nowoczesne przeglądarki i systemy operacyjne już dawno zrezygnowały z obsługi starszych i podatnych na ataki protokołów SSL/TLS (SSL 2.0, SSL 3.0 i TLS 1.1). TLS 1.2 i TLS 1.3 są teraz uważane za standardowe
Jeżeli strona korzysta z niższej wersji protokołu SSL/TLS niż jest obsługiwana przez klienta/przeglądarkę, użytkownik widzi błąd nawiązania bezpiecznego połączenia.
Aby włączyć starsze wersje protokołów SSL/TLS (znowu zauważam - jest to niebezpieczne):
![](https://i0.wp.com/winitpro.ru/wp-content/uploads/2018/11/vklyuchit-tls-1-0-tls-1-1.png)
Jeśli wszystkie powyższe metody nie pomogły pozbyć się błędu „Ta witryna nie może zapewnić bezpiecznego połączenia”, spróbuj również:
![](https://i2.wp.com/winitpro.ru/wp-content/uploads/2018/11/srednij-uroven-bezopasnosti-dlya-zony-internet.png)
Ogólna teoria: Rozszerzenie protokołu przesyłania danych HTTP, które obsługuje szyfrowanie tych danych - HTTPS - nie jest samym protokołem szyfrowania. Za szyfrowanie odpowiadają protokoły kryptograficzne - SSL lub TLS.
Jednocześnie nie wszystkie jogurty są równie przydatne: SSL jest całkowicie przestarzały, TLS w wersji 1.0 też jest, więc dziś zaleca się używanie tylko TLS w wersji 1.1 lub 1.2. Nawiasem mówiąc, najnowsza wersja specyfikacji HTTPS, przyjęta w 2000 roku, nazywa się HTTP over TLS, prawie nie ma tam wzmianki o SSL.
Ale to tylko teoria, w praktyce TLS 1.2 jest nadal obsługiwany tylko w ograniczonej liczbie witryn, z TLS 1.1 jest już zauważalnie lepszy, ale też nie wszędzie. Problem z obsługą nowoczesnych wersji TLS występuje również „po stronie klienta”, o czym później.
Tak więc, aby używać na swoim komputerze tylko najnowszych wersji aktualnego protokołu kryptograficznego (Dalej dzieci, przypomnijcie mi, jak to się nazywa? Zgadza się, TLS! A której wersji? Zgadza się, nie niższej niż 1.1), potrzebujesz zrobić kilka śmiesznych gestów. Czemu? Zgadza się, ponieważ nikt nie włączy za nas TLS 1.1/1.2 na naszym komputerze. Dla nas włączone będzie tylko sprawdzanie „autentyczności” systemu Windows, a do uruchamiania zostanie wrzuconych kilka „śmieci”. Jednak dygresję.
Dygresja liryczna: jestem szczerze przekonany (a to przekonanie potwierdza praktyka), że 90% użytkowników komputerów może nadal korzystać z Windows 3.11 (był taki system operacyjny na początku lat 90.) lub, w skrajnych przypadkach, Windows 98 SE -” maszyna do pisania” i przeglądarka nie wymagają niczego więcej, aby nie okłamywały nas o nowych, jeszcze bardziej ulepszonych interfejsach i innych drobiazgach „rewolucyjnych” nowych wersji systemu operacyjnego.
Prawdą jest też, że nowoczesne technologie, związane z bezpieczeństwem, nie mogą być w żaden sposób połączone z przestarzałymi systemami operacyjnymi. Nie dlatego, że w zasadzie jest to niemożliwe, ale dlatego, że ich producent tego nie zrobił, podobnie jak nie zrobili nic, aby powiązać ich z zewnętrznymi producentami oprogramowania. Dlatego wszystkie systemy operacyjne rodziny Wersje Windows poniżej XP (a nawet ten już w dającej się przewidzieć przyszłości), niestety, są beznadziejnie przestarzałe pod względem bezpieczeństwa sieci.
Na tym kończymy tekst: wszystkie poniższe argumenty będą oparte na fakcie, że używany jest Windows XP lub nowszy (Vista, 7 lub 8). I o tym, że my sami wcale nie jesteśmy złymi Pinokio, dlatego instalujemy wszystkie niezbędne aktualizacje i „łatki” w systemie operacyjnym, z którego korzystamy w odpowiednim czasie.
Tak więc na początek powinniśmy włączyć obsługę TLS 1.1 i TLS 1.2 oraz wyłączyć SSL i TLS 1.0 na poziomie systemu operacyjnego, za co odpowiada Microsoft TLS/SSL Security Provider (schannel.dll). Co nam to da? A oto co: wszystkie programy, które nie mają własnego modułu obsługi TLS, ale korzystają z modułu systemowego, będą korzystać z aktualnych wersji TLS.
To jest teoretycznie, zgodnie z którym wsparcie jest skonfigurowane w ten sposób aktualne wersje TLS, w tym w przeglądarce Internet Explorer. W rzeczywistości nawet jego Ostatnia wersja dla Windows XP - ósmy - nie obsługuje wersji TLS wyższych niż 1.0. Pod Windows Vista- obsługuje, ale pod Windows XP - nie, a ponadto ignoruje zakaz używania TLS 1.0. Jak to? Pytanie brzmi do Microsoftu, a nie do mnie, nadal będziemy robić to, czego od nas wymaga się zgodnie z instrukcjami producenta.
I robimy co następuje: wchodzimy do rejestru na
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, znajdź tam sekcje PCT 1.0, SSL 2.0, SSL 3.0 i TLS 1.0, w każdej z nich podsekcje Client i Server i utwórz w nich klucze DisabledByDefault (wpisz - DWORD ), któremu przypisujemy wartość 1 (jeden).
Następnie znajdujemy sekcje TLS 1.1 i TLS 1.2 w tym samym miejscu i podobnie tworzymy w nich wspomniany klucz, ale przypisujemy mu inną wartość - 0 (zero). W tym samym miejscu wyłączamy słabe szyfrowanie i algorytmy haszujące RC2, RC4, DES, MD4 i MD5, a także zabraniamy nawiązywania bezpiecznych połączeń bez szyfrowania (tak, to się dzieje… w czyichś niezdrowych fantazjach), pozostawiając tylko stosunkowo mocny Triple DES i SHA.
Ponieważ szczerze mówiąc, lenistwo jest dla mnie opisywanie, jak, co i gdzie zmienić, poniżej będzie zawartość pliku .reg, który wprowadza odpowiednie zmiany w rejestrze. Musisz dokładnie skopiować całą tę zawartość do schowka, utworzyć nową plik tekstowy, wklej tam zawartość, zapisz ten plik z rozszerzeniem .reg i uruchom go, a następnie uruchom ponownie.
Jeśli zdarzyło się, że po restarcie pojawiły się problemy z połączenie internetowe, ta sama operacja będzie musiała zostać wykonana z następnym plikiem - usuwa wszystkie zmiany, które wprowadziliśmy z rejestru, po czym (zgadza się, dzieci) ponownie uruchom ponownie. Nie znajdując żadnych wartości w rejestrze w sekcji rejestru, którą uszkodziliśmy, system operacyjny utworzy je ponownie podczas rozruchu z wartościami domyślnymi.
Zaawansowani użytkownicy mogą, zamiast całkowitego wycofywania zmian, bawić się z włączaniem i wyłączaniem poszczególnych protokołów i algorytmów, edytując pierwszy z plików. Uwaga dla gospodyni: jeśli korzystasz z firmy sieć lokalna, a tym bardziej z domeną, wtedy problemy są prawdopodobne i warto poszukać sposobów ich rozwiązania przy piwie z administratorem sieci ;)
Uwaga również: Przeglądarki Chrome, Firefox, Opera i Safari, tj. wszystkie, które nie są oparte na silniku Internet Explorera, używają własnych modułów obsługi SSL i TLS, a zatem nie zależą od ustawień, które omówiliśmy. Ale to nie znaczy, że można je zaniedbać (w sensie ustawień). Ale następnym razem porozmawiamy o ustawieniach samych przeglądarek.
Włącz TLS 1.1 i 1.2, wyłącz SSL i TLS 1.0:
"Włączone"=dword:00000000
"DisabledByDefault"=dword:00000001
"Włączone"=dword:00000000
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000001
"DisabledByDefault"=dword:00000000
"DisabledByDefault"=dword:00000000
"DisabledByDefault"=dword:00000000
"AllowInsecureRenegoClients"=dword:00000 000
"AllowInsecureRenegoServers"=dword:00000 000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
"Włączone"=dword:00000000
Czy wszystko jest zepsute? Usuń wprowadzone zmiany:
Okna Edytor rejestru Wersja 5.00
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl olSet\Control\SecurityProviders\SCHANNEL]
Google, Microsoft i Mozilla ogłosiły terminy całkowitego zaprzestania obsługi algorytmu szyfrowania RC4.
Wraz ze wzrostem zagrożenia cyberatakami na RC4 algorytm ten zaczął gwałtownie tracić na swojej niezawodności, a czołowi producenci przeglądarek postanowili całkowicie z niego zrezygnować – pod koniec stycznia lub na początku lutego.
Według Richarda Barnesa z Mozilli, wsparcie dla RC4 w Firefoksie zostanie porzucone wraz z wydaniem wersji 44, zaplanowanym na 26 stycznia. „Wyłączenie RC4 oznacza, że Firefox nie będzie już mógł łączyć się z serwerami, które wymagają użycia RC4” – wyjaśnił rzecznik firmy na forum dla programistów. „Dane, które posiadamy pokazują, że takich serwerów jest niewiele, ale nadal istnieją, chociaż użytkownicy Firefoksa rzadko mają do nich dostęp”.
Adam Langley z Google powiedział, że odpowiednia wersja Chrome będzie dostępna dla ogółu społeczeństwa w styczniu lub lutym. Nie podał daty, powiedział tylko, że serwery HTTPS korzystające wyłącznie z RC4 zostaną wyłączone. „Kiedy Chrome nawiązuje połączenie HTTPS, musi dołożyć wszelkich starań, aby je zabezpieczyć” – zauważył Langley na dedykowanej liście mailingowej na [e-mail chroniony]- Na ten moment używanie RC4 w połączeniach HTTPS nie spełnia tych wymagań, dlatego planujemy usunąć obsługę RC4 w przyszłej wersji Chrome”.
Obecnie i stabilnie wersje Firefoksa, a wersje beta mogą używać RC4 bez ograniczeń, ale w rzeczywistości używają go tylko odpowiednio dla 0,08 i 0,05% połączeń. W przypadku Chrome liczba ta jest nieco wyższa - 0,13%. „Aby kontynuować pracę, operatorzy odpowiednich serwerów najprawdopodobniej będą musieli jedynie nieznacznie zmienić konfigurację, aby przejść na silniejszy zestaw szyfrów” – powiedział Langley.
Microsoft ogłosił koniec wsparcia dla przestarzałego algorytmu w produktach Microsoft Edge oraz IE 11; wsparcie zostanie domyślnie wyłączone na początku przyszłego roku. „Microsoft Edge i Internet Explorer 11 używają RC4 tylko podczas zmiany wersji TLS 1.2 lub 1.1 na TLS 1.0” — powiedział David Walp, starszy kierownik projektu w Microsoft Edge. - Powrót do TLS 1.0 przy użyciu RC4 najczęściej zdarza się przez pomyłkę, ale taka sytuacja, mimo całej swojej niewinności, jest nie do odróżnienia od ataku typu man-in-the-middle. Z tego powodu na początku 2016 r. RC4 zostanie domyślnie wyłączony dla wszystkich użytkowników przeglądarki Microsoft Edge i Internet Explorer w systemach Windows 7, Windows 8.1 i Windows 10”.
Od ponad dekady badacze narzekają na niedoskonałości RC4, wskazując na możliwość wyboru losowych wartości wykorzystywanych do tworzenia szyfrogramów za pomocą tego algorytmu. Po pewnym czasie, moc obliczeniowa i dostęp do pewnej liczby żądań TLS, odszyfrowanie dla atakującego nie będzie trudne.
W 2013 roku badania przeprowadzone przez Daniela J. Bernsteina z University of Illinois pozwoliły mu stworzyć praktyczny sposób zaatakowania znanej luki w RC4 w celu złamania sesji TLS. Był to jeden z pierwszych takich eksperymentów, który został upubliczniony.
W lipcu ubiegłego roku belgijscy badacze zaatakowali RC4, pozwalając im przechwycić plik cookie ofiary i odszyfrować go w znacznie krótszym czasie, niż wcześniej sądzono.