Шифр rc4, який вважається небезпечним. Як отримати це оновлення

Загальна теорія: розширення протоколу передачі даних HTTP, що підтримує шифрування цих даних - HTTPS - не є власне протоколом шифрування. За шифрування відповідають криптографічні протоколи – SSL чи TLS.

При цьому не всі йогурти однаково корисні: SSL застарів повністю, TLS версії 1.0 теж, тому сьогодні рекомендується використовувати лише TLS версій 1.1 або 1.2. До слова, остання на сьогодні версія специфікації HTTPS, прийнята ще в 2000 році, так і називається HTTP over 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, зокрема, у браузері Internet Explorer. Насправді навіть його остання версія для 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 ), Яким присвоюємо значення 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:

"Enabled"=dword:00000000

"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

"DisabledByDefault"=dword:00000001

"DisabledByDefault"=dword:00000000

"AllowInsecureRenegoClients"=dword:00000 000
"AllowInsecureRenegoServers"=dword:00000 000

"Enabled"=dword:00000000

Все зламалося? Видаляємо зроблені зміни:

Windows Registry Editor Version 5.00

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

У мене чомусь перестали відкриватися деякі сайти HTTPS (не все!). При спробі відкрити такий сайт у браузері з'являється вікно з помилкою "Цей сайт не може забезпечити безпечне з'єднання". Сайти не відображаються як у Google Chrome, так і в Opera та Яндекс Браузері. Без HTTPS деякі сайти відкриваються, але не всі тільки ті, у яких сторінки доступні і за протоколом HTTPS і за протоколом HTTP. У Google Chrome помилка при відкритті HTTPS сайт виглядає так:

Цей сайт не може забезпечити безпечне з'єднання.
На сайті sitename.ru використовується протокол, що не підтримується.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Клієнт та сервер підтримують різні версії протоколу SSL та набору шифрів. Швидше за все, сервер використовує шифр RC4, який вважається небезпечним.

У Opera та Яндекс Браузер помилка виглядає приблизно також. Як відкрити такі сайти?

Відповідь

Як ви вже мабуть зрозуміли, проблема пов'язана з проблемами при SSL взаємодії між вашим комп'ютером і сайтом HTTPS. Причини такої помилки можуть бути різні. У цій статті я спробував зібрати всі методи виправлення помилки «Цей сайт не може забезпечити безпечне з'єднання» в різних браузерах.

Відразу хочеться відзначити, що незважаючи на те, що браузери Google Chrome, Opera і Яндекс Браузер випускаються різними компаніями, насправді всі ці браузери засновані на тому самому движку - Chrome і проблема з помилками відкриття HTTPS сайтів в них вирішується однаково.

Насамперед потрібно переконатися, що проблема не на боці самого HTTPS сайту. Спробуйте відкрити його з інших пристроїв (телефон, планшет, домашній/робочий комп'ютер тощо). Також перевірте, чи відкривається в інших браузерах, наприклад IE/Edge або Mozilla Firefox. У Firefox схожа помилка обговорювалася у статті.

Очистіть кеш та куки браузера, SSL кеш

Кеш і куки браузера можуть бути частою причиною помилок з SSL сертифікатами. Рекомендуємо спочатку очистити в браузері кеш та кукі. У Chrome потрібно натиснути клавіші Ctrl+Shift+Delete, виберіть проміжок часу ( Весь час) та натисніть кнопку очищення даних ( Видалити дані/ Clear Data).

Щоб очистити SSL кеш у Windows:

Перейдіть до розділу Панель управління -> Властивості браузера;
Клацніть на вкладці Зміст;
Натисніть на кнопку Очистити SSL (Clear SSL State);
Повинне з'явитися повідомлення "SSL-кеш успішно очищений";
Залишилося перезапустити браузер і перевірити, чи залишилася помилка ERR_SSL_PROTOCOL_ERROR.

Вимкніть сторонні розширення у браузері

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

Перевірте налаштування антивірусу та файрволу

Якщо на вашому комп'ютері встановлена антивірусна програма або міжмережевий екран (часто він вбудований в антивірус), можливо, доступ до сайту блокується саме ними. Щоб зрозуміти, чи обмежують доступ до сайту антивіруси або файрволи, спробуйте на якийсь час призупинити їхню роботу.
У багатьох сучасних антивірусах за замовчуванням є модуль перевірки SST/TLS сертифікатів сайтів. Якщо антивірус виявить, що сайт використовує недостатньо захищений (або ) сертифікат або застарілу версію протоколу SSL (той самий), доступ до користувача до такого сайту може бути обмежений. Спробуйте вимкнути сканування HTTP/HTTPS трафіку та SSL сертифікатів. Як ви розумієте, все залежить від того, який антивірус і вас встановлено. Наприклад:

Перевірте налаштування дати та часу

Неправильна дата та час (і ) на комп'ютері також можуть бути причиною помилки під час встановлення захищеного з'єднання з HTTPS сайтами. Адже при виконанні аутентифікації система перевіряє термін створення та дату закінчення сертифікату сайту та вищого центру сертифікації.

Оновлення кореневих сертифікатів Windows

Якщо ваш комп'ютер знаходиться в ізольованому сегменті, давно не оновлювався або на ньому зовсім відключено службу автоматичного оновлення, на вашому комп'ютері можуть бути відсутні нові кореневі довірені сертифікати (TrustedRootCA). Рекомендуємо виконати оновлення системи: встановити останні оновлення безпеки, у випадку з Windows 7 – обов'язково встановити SP1 () та оновлення часових поясів ().

Ви можете вручну оновити кореневі сертифікати за статтею: (так само рекомендуємо, це дозволить запобігти перехопленню вашого HTTPs трафіку та ряду інших проблем).

Вимкніть підтримку протоколу QUIC

Перевірте, чи не ввімкнено Chrome підтримка протоколу QUIC(Quick UDP Internet Connections). Протокол QUIC дозволяє набагато швидше відкрити з'єднання та узгодити всі параметри TLS (HTTPs) при підключенні до сайту. Однак у деяких випадках він може викликати проблеми з підключеннями SSL. Спробуйте вимкнути QUIC:

Перейдіть на сторінку: chrome://flags/#enable-quic;
Знайдіть опцію Experimental QUIC protocol;
Змініть значення опції Default на Disabled;
Перезапустіть 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 (ще раз наголошую – це небезпечно):

Якщо всі розглянуті способи не допомогли позбутися помилки «Цей сайт не може забезпечити безпечне з'єднання» також спробуйте:

Компанія Google, Microsoft і Mozilla оголосили терміни повного припинення підтримки алгоритму шифрування RC4.

Зі зростанням загрози кібератак на RC4 цей алгоритм почав стрімко втрачати свою надійність, і провідні вендори браузерів вирішили зовсім від нього відмовитися - наприкінці січня чи на початку лютого.

За словами Річарда Барнса (Richard Barnes) з Mozilla, підтримка RC4 Firefox буде скасована з випуском версії 44, запланованим на 26 січня. «Відключення RC4 позначатиме, що Firefox більше не зможе підключатися до серверів, що вимагають використання RC4, - пояснив представник компанії на її форумі для розробників. - Дані, які ми маємо, показують, що таких серверів небагато, але вони ще є, хоча користувачі Firefox до них рідко звертаються».

Адам Ленглі (Adam Langley) з Google заявив, що відповідний реліз Chrome стане доступним широким масам у січні або лютому. Дату він не уточнив, лише сказав, що HTTPS-сервери, які використовують виключно RC4, будуть відключені. «Коли Chrome встановлює HTTPS-з'єднання, він зобов'язаний зробити все можливе, щоб забезпечити його безпеку, - зазначив Ленглі у спеціалізованій розсилці на [email protected]. - На даний момент використання 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, – пояснив Девід Волп (David Walp), топ-менеджер проекту 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, що дозволяють перехоплювати cookie-файл жертви і розшифровувати його за набагато менший час, ніж це вважалося можливим раніше.