Активиране на шифъра rc4 в Internet Explorer 11. Решаване на проблема сами

15.05.2022

По някаква причина някои HTTPS сайтове (не всички!) спряха да ми се отварят. Когато се опитате да отворите такъв сайт в браузъра си, се появява прозорец с грешка „Този ​​сайт не може да осигури защитена връзка“. Сайтовете не се показват като в Google Chrome, както в браузъра Opera, така и в Yandex. Без HTTPS се отварят някои сайтове, но не всички, а само тези, чиито страници са достъпни както през HTTPS, така и през HTTP протокола.В Google Chrome грешката при отваряне на HTTPS сайт изглежда така:

Този сайт може да не предоставя защитена връзка.
Сайтът sitename.ru използва неподдържан протокол.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Поддръжка на клиенти и сървъри различни версии SSL протокол и набор от шифри. Най-вероятно сървърът използва шифър RC4, който се счита за несигурен."

В браузъра Opera и Yandex грешката изглежда приблизително еднаква. Как мога да отворя такива сайтове?

Отговор

Както вероятно вече сте разбрали, проблемът е свързан с проблеми с SSL комуникацията между вашия компютър и HTTPS сайта. Причините за такава грешка могат да бъдат доста различни. В тази статия се опитах да събера всички методи за коригиране на грешката „Този ​​сайт не може да осигури защитена връзка, ERR_SSL_PROTOCOL_ERROR“ в различни браузъри.

Бих искал веднага да отбележа, че въпреки факта, че Google браузъри Chrome, Opera и Yandex Browser се произвеждат от различни компании, всъщност всички тези браузъри са базирани на един и същ двигател - Chrome и проблемът с грешките при отваряне на HTTPS сайтове се решава по същия начин.

На първо място, трябва да се уверите, че проблемът не е от страна на самия HTTPS сайт. Опитайте да го отворите от други устройства (телефон, таблет, домашен/служебен компютър и др.). Проверете също дали се отваря в други браузъри, например IE/Edge или Mozilla Firefox. Във Firefox подобна грешка беше обсъдена в статията.

Изчистване на кеша на браузъра и бисквитките, SSL кеша

Кешът и бисквитките на браузъра могат да бъдат често срещана причина за грешки при SSL сертификати. Препоръчваме първо да изчистите кеша и бисквитките на браузъра си. В Chrome трябва да натиснете клавишна комбинация Ctrl + Shift + Delete, изберете период от време ( През цялото време) и щракнете върху бутона за изчистване на данните ( Изтриване на данни/ Изчистване на данните).

За да изчистите SSL кеша в Windows:

  1. Отидете в раздел Контролен панел -> Свойства на браузъра;
  2. Кликнете върху раздела Съдържание;
  3. Кликнете върху бутона Изчистване на SSL (Изчистване на състоянието на SSL);
  4. Трябва да се появи съобщението „SSL кешът е изчистен успешно“;
  5. Остава само да рестартирате браузъра и да проверите дали грешката ERR_SSL_PROTOCOL_ERROR остава.

Деактивирайте разширенията на браузъра на трети страни

Препоръчваме да деактивирате (деинсталирате) разширения на браузъра на трети страни, особено всички анонимизатори, проксита, VPN, антивирусни разширения и други подобни добавки, които могат да попречат на преминаването на трафик към целевия сайт. Можете да видите списъка с активирани разширения в Chrome, като отидете на Настройки -> Допълнителни инструменти -> Разширения, или като отидете на страницата chrome://разширения/. Деактивирайте всички подозрителни разширения.

Проверете настройките на антивирусната програма и защитната стена

Ако сте инсталирали на вашия компютър антивирусна програмаили защитна стена(често е вграден в антивирусната програма), може би достъпът до сайта е блокиран от тях. За да разберете дали антивирусите или защитните стени ограничават достъпа до даден сайт, опитайте да спрете работата им за известно време.
Много съвременни антивирусни програми имат модул за проверка на SST/TLS сертификати за уебсайтове по подразбиране. Ако антивирусът установи, че сайтът използва недостатъчно защитен (или) сертификат или остаряла версия SSL протокол (същият), потребителският достъп до такъв сайт може да бъде ограничен. Опитайте да деактивирате сканирането на HTTP/HTTPS трафик и SSL сертификати. Както разбирате, всичко зависи от това каква антивирусна програма сте инсталирали. Например:


Проверете настройките за дата и час

Неправилните дата и час(а) на вашия компютър също могат да причинят грешки при установяване на защитена връзка към HTTPS сайтове. В крайна сметка, когато извършва удостоверяване, системата проверява периода на създаване и датата на изтичане на сертификата на сайта и по-високия сертифициращ орган.

Актуализирайте главните сертификати на Windows

Ако компютърът ви е в изолиран сегмент, не е актуализиран дълго време или услугата е напълно деактивирана на него автоматична актуализация, вашият компютър може да няма нови доверени основни сертификати (TrustedRootCA). Препоръчваме актуализиране на системата: инсталирайте Последни актуализациисигурност, в случай на Windows 7, не забравяйте да инсталирате SP1 () и актуализации на часовата зона ().

Можете ръчно да актуализирате основни сертификатиспоред статията: (ние също препоръчваме това, това ще предотврати прихващането на вашия HTTPs трафик и редица други проблеми).

Деактивирайте поддръжката на QUIC протокол

Проверете дали Chrome има активирана поддръжка на протокол БЪРЗО(Бързи UDP интернет връзки). Протоколът QUIC ви позволява да отворите връзка много по-бързо и да договорите всички TLS (HTTP) параметри, когато се свързвате към сайт. В някои случаи обаче може да причини проблеми с SSL връзки. Опитайте да деактивирате QUIC:

  1. Отиди на страница: chrome://flags/#enable-quic;
  2. Намерете опцията Експериментален QUIC протокол;
  3. Променете опцията по подразбиране на хора с увреждания;
  4. Рестартирайте Chrome.

Активиране на поддръжка за TLS и SSL протоколи

И последната точка - най-вероятно, за да разрешите проблема, ще трябва само да активирате поддръжка за по-стари версии на протоколите TLS и SSL. В повечето случаи ще е най-ефективен, но умишлено го преместих в края на статията. Ще обясня защо.

Старите версии на протоколите TLS и SSL са деактивирани не поради простата прищявка на разработчиците, а поради наличието голямо количествоуязвимости, които позволяват на нападателите да прихванат вашите данни в HTTPS трафик и дори да ги променят. Необмисленото активиране на стари протоколи значително намалява вашата сигурност в интернет, така че трябва да прибягвате до този метод като последна мярка, ако всичко друго се провали.

Съвременните браузъри и операционни системи отдавна са изоставили поддръжката на остарели и уязвими SSL/TLS протоколи (SSL 2.0, SSL 3.0 и TLS 1.1). TLS 1.2 и TLS 1.3 вече се считат за стандартни

Ако страната на сайта използва по-ниска версия на SSL/TLS протокола, отколкото се поддържа от клиента/браузъра, потребителят вижда грешка при установяване на защитена връзка.

За да активирате по-стари версии на SSL/TLS протоколите (отново това не е сигурно):

Ако всички обсъдени по-горе методи не помогнаха да се отървете от грешката „Този ​​сайт не може да осигури защитена връзка“, опитайте също:

Обща теория: Разширението на HTTP протокола за пренос на данни, което поддържа криптиране на тези данни - HTTPS - само по себе си не е протокол за криптиране. Криптографските протоколи – SSL или TLS – отговарят за криптирането.

Не всички кисели млека обаче са еднакво полезни: SSL е напълно остарял, TLS версия 1.0 също е остаряла, така че днес се препоръчва да се използват само TLS версии 1.1 или 1.2. Между другото, последната версия на спецификацията HTTPS, приета през 2000 г., се нарича HTTP през TLS; там почти не се споменава SSL.

Но това е само теория, на практика TLS 1.2 все още се поддържа само на ограничен брой сайтове, с TLS 1.1 вече е забележимо по-добре, но също не навсякъде. Проблемът с поддръжката на модерни версии на TLS също присъства от страна на клиента, повече за това по-късно.

И така, за да използвате на вашия компютър само най-новите версии на текущия криптографски протокол (Хайде, деца, припомнете ми как се казва? Точно така, TLS! И каква версия? Точно така, не по-ниска от 1.1), трябва да направи редица нелепи жестове. Защо? Точно така, защото никой няма да активира TLS 1.1/1.2 на нашия компютър вместо нас. За нас те ще активират само проверката за „автентичност“ на Windows и ще напълнят куп „боклук“ при стартиране. Аз обаче се отклоних.

Лирично отклонение: искрено съм убеден (и това убеждение се потвърждава от практиката), че 90% от компютърните потребители все още могат да използват Windows 3.11 (имаше такава операционна система в началото на 90-те) или, в краен случай, Windows 98 SE - “ пишеща машина" и браузърът не изисква нищо друго, за да не ни лъжат за нови, още по-подобрени интерфейси и други дреболии на "революционно" нови версии на ОС.

Също така е вярно, че модерни технологииНяма начин да прикрепите проблеми, свързани със сигурността, към остарели операционни системи. Не защото това е невъзможно по принцип, а защото производителят им не го е направил, както не е направил нищо, за да могат да бъдат прецакани производители на трети страниОТ. Следователно всички операционни системи от семейството Windows версиипод XP (и дори това в обозримо бъдеще), уви, са безнадеждно остарели по отношение на мрежовата сигурност.

Нека приключим с текста тук: всички следващи аргументи ще се основават на факта, че се използва Windows XP или по-нова версия (Vista, 7 или 8). И на факта, че ние самите изобщо не сме зли Пинокио ​​и затова незабавно инсталираме всички необходими актуализации и „кръпки“ на операционната система, която използваме.

И така, първо трябва да активираме поддръжката за TLS 1.1 и TLS 1.2 и да деактивираме SSL и TLS 1.0 на ниво операционна система, за което отговаря Microsoft TLS/SSL Security Provider (schannel.dll). Какво ще ни даде това? Ето какво: всички програми, които нямат собствен модул за поддръжка на TLS, но използват системния, ще използват последните версии на TLS.

Това е теорията, че поддръжката е конфигурирана по този начин текущи версии TLS, включително интернет браузърИзследовател. Всъщност дори той последна версияза Windows XP - осмо - не поддържа TLS версии по-високи от 1.0. Под Windows Vista поддържа, но под Windows XP не и освен това игнорира забраната за използване на TLS 1.0. Как така? Въпросът е към Microsoft, не към мен, ние все пак ще направим това, което се изисква от нас според инструкциите на производителя.

И правим следното: отиваме в регистратурата на адреса
HKLM\SYSTEM\CurrentControlSet\Control\Se curityProviders\SCHANNEL\Protocols, намерете там секциите PCT 1.0, SSL 2.0, SSL 3.0 и TLS 1.0, във всяка от тях - подсекциите Client и Server и създайте ключовете DisabledByDefault в тях ( тип - DWORD ), на който присвояваме стойност 1 (едно).

След това намираме секциите TLS 1.1 и TLS 1.2 там и по същия начин създаваме гореспоменатия ключ в тях, но му присвояваме различна стойност - 0 (нула). Там също деактивираме слабото криптиране и алгоритмите за хеширане RC2, RC4, DES, MD4 и MD5 и също така забраняваме инсталирането сигурни връзкибез криптиране (да, това също се случва... в нечии нездравословни фантазии), оставяйки само относително силни Triple DES и SHA.

Тъй като откровено ме мързи да описвам как, какво и къде да променя, по-долу ще бъде съдържанието на .reg файла, който прави съответните промени в системния регистър. Трябва внимателно да копирате цялото това съдържание в клипборда, да създадете нов текстов файл, да поставите съдържанието там, да запишете този файл с разширение .reg и да го стартирате, след което да рестартирате.

Ако се случи, че след рестартиране се появят проблеми с мрежова връзка, ще трябва да се направи същата операция със следващия файл - той изтрива всички промени, които направихме от системния регистър, след което (точно така, деца) ще се рестартира отново. Ако регистърът не намери никакви стойности в раздела на регистъра, който сме повредили, операционната система ще ги създаде отново по време на зареждане със стойности по подразбиране.

Напредналите потребители могат, вместо да връщат напълно промените, да си поиграят с активирането и деактивирането на отделни протоколи и алгоритми, като редактират първия от файловете. Забележка към домакинята: ако използвате корпоративна мрежа за връзка с интернет локалната мрежа, и особено с домейна, тогава са вероятни проблеми и се препоръчва да търсите начини за разрешаването им, докато пиете бутилка бира с мрежовия администратор;)

Също така имайте предвид: браузъри Chrome, Firefox, Opera и Safari, т.е. всички, които не са базирани на двигателя на Internet Explorer, използват свои собствени модули за поддръжка на SSL и TLS и следователно не зависят от настройките, които обсъждахме. Но това не означава, че те могат да бъдат пренебрегнати (в смисъл на настройки). Но ще говорим за настройките на самите браузъри следващия път.


Активиране на TLS 1.1 и 1.2, деактивиране на SSL и TLS 1.0:




"Активирано"=dword:00000000


"DisabledByDefault"=dword:00000001
"Активирано"=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


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000


"Активирано"=dword:00000000

Всичко ли е счупено? Изтриваме направените промени:

Windows Registry Editor версия 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentContr olSet\Control\SecurityProviders\SCHANNEL]

Google, Microsoft и Mozilla обявиха момента на пълния край на поддръжката за алгоритъма за криптиране RC4.

С нарастващата заплаха от кибератаки срещу RC4 този алгоритъм започна бързо да губи своята надеждност и водещите доставчици на браузъри решиха да го изоставят напълно - в края на януари или началото на февруари.

Според Ричард Барнс от Mozilla, поддръжката за RC4 във Firefox ще бъде премахната с пускането на версия 44, планирано за 26 януари. „Деактивирането на RC4 ще означава, че Firefox вече няма да може да се свързва със сървъри, които изискват RC4“, обясни говорител на компанията във форума за разработчици. „Данните, с които разполагаме, показват, че такива сървъри са малко, но те все още съществуват, въпреки че потребителите на Firefox рядко имат достъп до тях.“

Адам Лангли от Google каза, че съответната версия на Chrome ще бъде достъпна за широката публика през януари или февруари. Той не уточни датата, само каза, че HTTPS сървърите, използващи изключително RC4, ще бъдат деактивирани. „Когато Chrome установи HTTPS връзка, той трябва да направи всичко възможно, за да гарантира своята сигурност“, отбеляза Лангли в специален бюлетин на [имейл защитен]. „Понастоящем използването на RC4 в HTTPS връзки не отговаря на тези изисквания, така че планираме да деактивираме поддръжката на RC4 в бъдеща версия на Chrome.“

В момента както стабилните, така и бета версиите на Firefox могат да използват RC4 без ограничения, но всъщност го използват съответно само за 0,08 и 0,05% от връзките. За Chrome тази цифра е малко по-висока - 0,13%. „За да продължат да работят, операторите на съответните сървъри вероятно ще трябва само леко да променят конфигурацията, за да преминат към по-сигурен пакет за шифроване“, каза Лангли.

Microsoft обяви края на поддръжката на остарелия алгоритъм в продуктите Microsoft Edgeи IE 11; поддръжката ще бъде деактивирана по подразбиране в началото на следващата година. „Microsoft Edge и Internet Explorer 11 използват RC4 само при понижаване от TLS протокол 1.2 или 1.1 преди TLS 1.0“, обясни Дейвид Уолп, старши мениджър проекти за Microsoft Edge. - Връщане към TLS 1.0 с помощта на RC4 най-често се случва по погрешка, но такава ситуация, макар и невинна, е неразличима от атака човек по средата. Поради тази причина в началото на 2016 г. RC4 ще бъде деактивиран по подразбиране за всички потребители на Microsoft Edge и Internet Explorer под Windows 7, Windows 8.1 и Windows 10.

Повече от десетилетие изследователите се оплакват от несъвършенствата на RC4, посочвайки възможността за избиране на произволни стойности, използвани за създаване на шифровани текстове с помощта на този алгоритъм. Като се има предвид определено време, изчислителна мощност и достъп до определен брой TLS заявки, дешифрирането няма да бъде трудно за нападателя.

През 2013 г. изследване, проведено от Daniel J. Bernstein от Университета на Илинойс, му позволи да създаде практическа атака срещу известна уязвимост в RC4, за да компрометира TLS сесия. Това беше един от първите подобни експерименти, които станаха публични.

Миналия юли белгийски изследователи атакуваха RC4, позволявайки му да прихване бисквитката на жертвата и да я дешифрира за много по-малко време, отколкото се смяташе за възможно.