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:

  1. Przejdź do sekcji Panel sterowania -> Właściwości przeglądarki;
  2. Kliknij na zakładkę Zawartość;
  3. Kliknij przycisk Wyczyść SSL (Wyczyść stan SSL);
  4. Powinien pojawić się komunikat „Pamięć podręczna SSL została pomyślnie wyczyszczona”;
  5. 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:


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:

  1. Idź do strony: chrome://flagi/#enable-quic;
  2. Znajdź opcję Eksperymentalny protokół QUIC;
  3. Zmień wartość opcji Domyślne na Wyłączone;
  4. 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):

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ż:

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.