Az rc4 titkosítás engedélyezése az Internet Explorerben 11. A probléma megoldása saját maga

15.05.2022

Valamilyen oknál fogva néhány HTTPS-webhely (nem mindegyik!) leállt számomra. Amikor megpróbál megnyitni egy ilyen webhelyet a böngészőben, megjelenik egy ablak a „Ez a webhely nem tud biztonságos kapcsolatot biztosítani” hibával. A webhelyek nem úgy jelennek meg, mint Google Chrome, mind az Operában, mind a Yandex böngészőben. HTTPS nélkül néhány webhely nyílik meg, de nem mindegyik, csak azok, amelyek oldalai elérhetők HTTPS- és HTTP-protokollon keresztül is.

Előfordulhat, hogy ez a webhely nem biztosít biztonságos kapcsolatot.
A sitename.ru webhely nem támogatott protokollt használ.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Kliens és szerver támogatás különböző verziók SSL protokoll és rejtjelkészlet. Valószínűleg a szerver az RC4 titkosítást használja, amely nem tekinthető biztonságosnak."

Az Opera és a Yandex böngészőben a hiba megközelítőleg ugyanúgy néz ki. Hogyan nyithatok ilyen oldalakat?

Válasz

Amint valószínűleg már megértette, a probléma a számítógépe és a HTTPS-webhely közötti SSL-kommunikációval kapcsolatos problémákkal kapcsolatos. Az ilyen hibák okai meglehetősen eltérőek lehetnek. Ebben a cikkben megpróbáltam összegyűjteni az összes módszert az „Ez a webhely nem tud biztonságos kapcsolatot biztosítani, ERR_SSL_PROTOCOL_ERROR” hiba javítására különböző böngészőkben.

Azonnal szeretném megjegyezni, hogy annak ellenére Google böngészők A Chrome-ot, az Opera-t és a Yandex Browser-t különböző cégek gyártják, valójában ezek a böngészők ugyanazon a motoron alapulnak - a Chrome és a HTTPS-webhelyek megnyitásának hibáival kapcsolatos probléma ugyanúgy megoldódik.

Mindenekelőtt meg kell győződnie arról, hogy a probléma nem magának a HTTPS webhelynek az oldalán van. Próbálja meg megnyitni más eszközökről (telefon, táblagép, otthoni/munkahelyi számítógép stb.). Ellenőrizze azt is, hogy megnyílik-e más böngészőkben, például IE/Edge vagy Mozilla Firefox. A Firefoxban hasonló hibáról volt szó a cikkben.

Törölje a böngésző gyorsítótárát és a cookie-kat, valamint az SSL gyorsítótárat

A böngésző gyorsítótára és a cookie-k az SSL-tanúsítványokkal kapcsolatos hibák gyakori okai lehetnek. Javasoljuk, hogy először törölje a böngésző gyorsítótárát és a cookie-kat. A Chrome-ban meg kell nyomnia egy billentyűkódot Ctrl + Shift + Delete, válasszon egy időszakot ( Mindig), majd kattintson az adatok törlése gombra ( Adatok törlése/ Adatok törlése).

Az SSL gyorsítótár törlése Windows rendszeren:

Ugrás a szakaszra Kezelőpanel -> Böngésző tulajdonságai;
Kattintson a fülre Tartalom;
Kattintson a gombra SSL törlése (SSL állapot törlése);
Meg kell jelennie az „SSL gyorsítótár sikeresen törölve” üzenetnek;
Nem kell mást tenni, mint újraindítani a böngészőt, és ellenőrizni, hogy az ERR_SSL_PROTOCOL_ERROR hiba továbbra is fennáll-e.

A harmadik féltől származó böngészőbővítmények letiltása

Javasoljuk, hogy tiltsa le (távolítsa el) a harmadik féltől származó böngészőbővítményeket, különösen az anonimizálókat, proxykat, VPN-eket, víruskereső bővítményeket és más hasonló kiegészítőket, amelyek megzavarhatják a forgalom céloldalra történő áthaladását. A Chrome-ban engedélyezett bővítmények listáját a következő címen tekintheti meg Beállítások -> További eszközök -> Kiterjesztések, vagy az oldalra lépve chrome://extensions/. Tiltsa le az összes gyanús bővítményt.

Ellenőrizze a víruskereső és a tűzfal beállításait

Ha telepítette a számítógépére víruskereső program vagy tűzfal(gyakran az antivírusba van beépítve), esetleg blokkolják az oldalhoz való hozzáférést. Ha szeretné megérteni, hogy a víruskeresők vagy a tűzfalak korlátozzák-e a hozzáférést egy webhelyhez, próbálja meg egy időre szüneteltetni a működésüket.
Sok modern vírusirtó alapértelmezés szerint rendelkezik egy modullal az SST/TLS webhelytanúsítványok ellenőrzésére. Ha a vírusirtó azt észleli, hogy a webhely nem megfelelően védett (vagy) tanúsítványt használ, ill elavult verzió SSL protokoll (ugyanaz), a felhasználói hozzáférés egy ilyen webhelyhez korlátozott lehet. Próbálja meg letiltani a HTTP/HTTPS forgalom és az SSL-tanúsítványok vizsgálatát. Mint érti, minden attól függ, hogy milyen víruskeresőt telepített. Például:

Ellenőrizze a dátum- és időbeállításokat

A számítógépen megadott helytelen dátum és idő is hibákat okozhat a HTTPS-webhelyekhez való biztonságos kapcsolat létrehozása során. Hiszen a hitelesítés során a rendszer ellenőrzi a helytanúsítvány létrehozási idejét és lejárati idejét, valamint a magasabb hitelesítési hatóságot.

Frissítse a Windows gyökértanúsítványait

Ha a számítógép egy elszigetelt szegmensben van, hosszú ideig nem frissítették, vagy a szolgáltatás teljesen le van tiltva rajta automatikus frissítés, előfordulhat, hogy számítógépe nem rendelkezik új megbízható gyökértanúsítványokkal (TrustedRootCA). Javasoljuk a rendszer frissítését: telepítse Legújabb frissítések biztonság, Windows 7 esetén feltétlenül telepítse az SP1 () és az időzóna frissítéseket ().

Manuálisan frissítheti gyökértanúsítványok cikk szerint: (ezt is ajánljuk, ezzel elkerülhető a HTTPs forgalom elfogása és számos egyéb probléma).

A QUIC protokoll támogatásának letiltása

Ellenőrizze, hogy a Chrome-ban engedélyezve van-e a protokolltámogatás QUIC(Gyors UDP internetkapcsolatok). A QUIC protokoll lehetővé teszi a kapcsolat sokkal gyorsabb megnyitását és az összes TLS (HTTP) paraméter egyeztetését, amikor egy webhelyhez csatlakozik. Bizonyos esetekben azonban problémákat okozhat SSL kapcsolatok. Próbálja meg kikapcsolni a QUIC-t:

Menj az oldalra: chrome://flags/#enable-quic;
Keresse meg a lehetőséget Kísérleti QUIC protokoll;
Módosítsa az Alapértelmezett beállítást erre Tiltva;
Indítsa újra a Chrome-ot.

Engedélyezze a TLS és SSL protokollok támogatását

És az utolsó pont - a probléma megoldásához valószínűleg csak engedélyeznie kell a TLS és SSL protokollok régebbi verzióinak támogatását. A legtöbb esetben ez lesz a leghatékonyabb, de szándékosan áthelyeztem a cikk végére. Elmagyarázom miért.

A TLS és SSL protokollok régi verziói nem a fejlesztők egyszerű szeszélye miatt vannak letiltva, hanem a jelenlétük miatt. nagy mennyiség biztonsági rések, amelyek lehetővé teszik a támadók számára, hogy elfogják az Ön adatait a HTTPS-forgalomban, és akár módosítsák is azokat. A régi protokollok átgondolatlan engedélyezése jelentősen csökkenti az internet biztonságát, ezért érdemes ezt a módszert végső esetben igénybe venni, ha minden más nem sikerül.

A modern böngészők és operációs rendszerek már régóta felhagytak az elavult és sebezhető SSL/TLS protokollok (SSL 2.0, SSL 3.0 és TLS 1.1) támogatásával. A TLS 1.2 és TLS 1.3 ma már szabványnak számít

Ha a webhelyoldal az SSL/TLS protokoll alacsonyabb verzióját használja, mint amit az ügyfél/böngésző támogat, a felhasználó hibát lát a biztonságos kapcsolat létrehozása során.

Az SSL/TLS protokollok régebbi verzióinak engedélyezéséhez (ez ismét nem biztonságos):

Ha a fent tárgyalt módszerek mindegyike nem segített megszabadulni az „Ez a webhely nem tud biztonságos kapcsolatot biztosítani” hibaüzenettől, próbálkozzon a következővel:

Általános elmélet: A HTTP adatátviteli protokoll ezen adatok titkosítását támogató kiterjesztése – a HTTPS – önmagában nem titkosítási protokoll. A titkosításért a kriptográfiai protokollok – SSL vagy TLS – felelősek.

Azonban nem minden joghurt egyformán hasznos: az SSL teljesen elavult, a TLS 1.0-s verziója is elavult, így ma már csak az 1.1-es vagy 1.2-es TLS-verzió használata javasolt. Egyébként a HTTPS specifikáció legfrissebb, 2000-ben elfogadott változatát HTTP over TLS-nek hívják, ott szinte szó sem esik az SSL-ről.

De ez csak elmélet, a gyakorlatban a TLS 1.2-t még csak korlátozott számú oldalon támogatják, a TLS 1.1-nél már érezhetően jobb, de szintén nem mindenhol. A TLS modern verzióinak támogatásának problémája „kliens oldalon” is jelen van, erről később.

Tehát ahhoz, hogy számítógépén csak a jelenlegi kriptográfiai protokoll legfrissebb verzióit használhassa (gyerünk, gyerekek, emlékeztessem, mi a neve? Így van, TLS! És melyik verzió? Igaz, nem alacsonyabb, mint 1.1), szüksége van hogy számos nevetséges mozdulatot tegyen . Miért? Így van, mert helyettünk senki sem fogja engedélyezni a TLS 1.1/1.2-t a számítógépünkön. Számunkra csak a Windows „autenticitás” ellenőrzését engedélyezik, és egy csomó „szemetet” tömnek az indításba. Azonban elkalandozom.

Lírai kitérő: Őszintén meg vagyok győződve (és ezt a meggyőződést a gyakorlat is megerősíti), hogy a számítógép-felhasználók 90%-a továbbra is használhatja a Windows 3.11-et (a 90-es évek elején volt ilyen operációs rendszer), vagy extrém esetben a Windows 98 SE-t - “ írógép" és a böngésző nem igényel mást, hogy ne hazudjanak nekünk az operációs rendszer "forradalmian új" verzióinak új, még továbbfejlesztett felületeiről és egyéb apróságairól.

Az is igaz, hogy modern technológiák Nincs mód a biztonsággal kapcsolatos problémák elavult operációs rendszerekhez való csatolására. Nem azért, mert ez elvileg lehetetlen, hanem azért, mert a gyártójuk nem ezt tette, mint ahogy semmit sem tett azért, hogy felcsavarható legyen. harmadik fél gyártókÁLTAL. Ezért a család összes operációs rendszere Windows verziók XP alatt (és még az is belátható időn belül) sajnos reménytelenül elavult a hálózatbiztonság szempontjából.

Itt fejezzük be a dalszövegeket: a következő érvek mindegyike azon a tényen alapul, hogy Windows XP vagy újabb (Vista, 7 vagy 8) operációs rendszert használ. És azon a tényen, hogy mi magunk egyáltalán nem vagyunk gonosz Pinokkiók, ezért azonnal telepítjük az összes szükséges frissítést és „javítást” az általunk használt operációs rendszerre.

Tehát először engedélyeznünk kell a TLS 1.1 és TLS 1.2 támogatását, és le kell tiltanunk az SSL-t és a TLS 1.0-t operációs rendszer szinten, amiért a Microsoft TLS/SSL biztonsági szolgáltató (schannel.dll) a felelős. Mit fog ez adni nekünk? Íme: minden olyan program, amely nem rendelkezik saját TLS-támogató modullal, de a rendszert használja, a TLS legújabb verzióit fogja használni.

Ez az elmélet szerint a támogatás így van konfigurálva aktuális verziók TLS, beleértve internet böngésző Felfedező. Sőt, még őt is legújabb verzió Windows XP esetén – nyolcadik – nem támogatja az 1.0-nál magasabb TLS-verziókat. Windows Vista alatt támogatja, de Windows XP alatt nem, sőt figyelmen kívül hagyja a TLS 1.0 használatának tilalmát. Hogy hogy? A kérdés a Microsoftnak szól, nem nekem, mi továbbra is megtesszük, amit elvárnak tőlünk a gyártó utasításai szerint.

És a következőket tesszük: bemegyünk a nyilvántartóba a címen
HKLM\SYSTEM\CurrentControlSet\Control\Se curityProviders\SCHANNEL\Protocols, keresse meg ott a PCT 1.0, SSL 2.0, SSL 3.0 és TLS 1.0 szakaszokat, mindegyikben - a Kliens és a Szerver alfejezetben, és hozza létre bennük a DisabledByDefa-ban a DisabledByDefa-t. típusú - DWORD ), amelyhez 1 (egy) értéket rendelünk.

Ezután ott megtaláljuk a TLS 1.1 és TLS 1.2 szekciókat, és hasonló módon létrehozzuk bennük a fent említett kulcsot, de más értéket rendelünk hozzá - 0 (nulla). Itt letiltjuk az RC2, RC4, DES, MD4 és MD5 gyenge titkosítási és kivonatolási algoritmusait, valamint megtiltjuk a telepítést is. biztonságos kapcsolatokat titkosítás nélkül (igen, ez is előfordul... valaki egészségtelen fantáziájában), csak viszonylag erős Triple DES és SHA marad.

Mivel őszintén lusta vagyok leírni, hogyan, mit és hol kell módosítani, az alábbiakban a rendszerleíró adatbázis megfelelő módosításait végrehajtó .reg fájl tartalma lesz. Ezt a tartalmat gondosan át kell másolnia a vágólapra, létre kell hoznia egy új szöveges fájlt, oda kell illesztenie a tartalmat, mentenie kell ezt a fájlt .reg kiterjesztéssel, futtassa, majd indítsa újra.

Ha megtörtént, hogy újraindítás után problémák jelentkeztek a internetkapcsolat, ugyanezt a műveletet kell elvégezni a következő fájllal is - törli az összes általunk végzett változtatást a registry-ből, ami után (igaz, gyerekek) újraindul. Ha a rendszerleíró adatbázis egyáltalán nem talál értéket az általunk megsérült rendszerleíró részben, akkor az operációs rendszer rendszerindításkor újra létrehozza azokat az alapértelmezett értékekkel.

A haladó felhasználók a változtatások teljes visszaállítása helyett az első fájlok szerkesztésével játszhatnak az egyes protokollok és algoritmusok engedélyezésével és letiltásával. Megjegyzés a háziasszonynak: ha vállalati hálózatot használ az internethez való csatlakozáshoz a helyi hálózat, és főleg a domainnel, akkor valószínűsíthetőek a problémák, melyek megoldásának módjait a hálózati adminisztrátorral egy üveg sör mellett érdemes keresni;)

Megjegyzés: Chrome böngészők, Firefox, Opera és Safari, i.e. mindazok, amelyek nem az Internet Explorer motoron alapulnak, saját SSL- és TLS-támogató moduljaikat használják, ezért nem függenek az általunk tárgyalt beállításoktól. De ez nem jelenti azt, hogy elhanyagolhatóak (a beállítások értelmében). De maguknak a böngészőknek a beállításairól legközelebb fogunk beszélni.

A TLS 1.1 és 1.2 engedélyezése, az SSL és a TLS 1.0 letiltása:

"Engedélyezve"=dword:00000000

"DisabledByDefault"=dword:00000001
"Engedélyezve"=dword:00000000

"DisabledByDefault"=dword:00000001

"DisabledByDefault"=dword:00000000

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

"Engedélyezve"=dword:00000000

Minden elromlott? Töröljük az elvégzett módosításokat:

Windows Registry Editor 5.00 verzió

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

A Google, a Microsoft és a Mozilla bejelentette, hogy az RC4 titkosítási algoritmus támogatása teljes mértékben megszűnik.

Az RC4 elleni kibertámadások növekvő veszélyével ez az algoritmus gyorsan veszíteni kezdett megbízhatóságából, és a vezető böngészőgyártók úgy döntöttek, hogy teljesen felhagynak vele – január végén vagy február elején.

Richard Barnes (Mozilla) szerint a Firefox RC4 támogatása megszűnik a január 26-ra tervezett 44-es verzió megjelenésével. "Az RC4 letiltása azt jelenti, hogy a Firefox többé nem tud csatlakozni az RC4-et igénylő szerverekhez" - magyarázta a cég szóvivője a fejlesztői fórumán. "A rendelkezésünkre álló adatok azt mutatják, hogy kevés ilyen szerver létezik, de még mindig léteznek, bár a Firefox-felhasználók ritkán érik el őket."

Adam Langley, a Google munkatársa elmondta, hogy a Chrome megfelelő kiadása januárban vagy februárban lesz elérhető a nagyközönség számára. Nem adta meg a dátumot, csak annyit mondott, hogy a kizárólag RC4-et használó HTTPS-szervereket letiltják. „Amikor a Chrome HTTPS-kapcsolatot létesít, minden tőle telhetőt meg kell tennie annak biztonsága érdekében” – jegyezte meg Langley egy erről szóló hírlevélben. [e-mail védett]. „Jelenleg az RC4 használata HTTPS-kapcsolatokban nem felel meg ezeknek a követelményeknek, ezért azt tervezzük, hogy a Chrome egy jövőbeni kiadásában letiltjuk az RC4 támogatását.”

Jelenleg a Firefox stabil és béta verziója is korlátozás nélkül használhatja az RC4-et, de valójában csak a kapcsolatok 0,08, illetve 0,05%-ára használják. A Chrome esetében ez a szám valamivel magasabb - 0,13%. "A működés folytatásához az adott szerverek üzemeltetőinek valószínűleg csak kissé módosítaniuk kell a konfigurációt, hogy biztonságosabb titkosítási csomagra váltsanak" - mondta Langley.

A Microsoft bejelentette, hogy megszünteti az elavult algoritmus támogatását a termékekben Microsoft Edgeés IE 11; a támogatás jövő év elején alapértelmezés szerint le lesz tiltva. "A Microsoft Edge és az Internet Explorer 11 csak akkor használja az RC4-et, amikor a verzióról alacsonyabb verzióra vált TLS protokoll 1.2 vagy 1.1 a TLS 1.0 előtt” – magyarázta David Walp, a Microsoft Edge vezető projektmenedzsere. - Az RC4-et használó TLS 1.0-ra való visszaállítás leggyakrabban tévedésből következik be, de egy ilyen szituáció, bár ártatlan, megkülönböztethetetlen az ember a közepén támadástól. Emiatt 2016 elején az RC4 alapértelmezés szerint le lesz tiltva a Microsoft Edge és az Internet Explorer összes felhasználója számára Windows 7, Windows 8.1 és Windows 10 alatt.

A kutatók több mint egy évtizeden át panaszkodtak az RC4 tökéletlenségei miatt, rámutatva arra a lehetőségre, hogy véletlenszerű értékeket válasszanak ki a titkosított szövegek létrehozásához ezzel az algoritmussal. Egy bizonyos idő, számítási teljesítmény és bizonyos számú TLS-kéréshez való hozzáférés miatt a visszafejtés nem lesz nehéz a támadó számára.

2013-ban Daniel J. Bernstein az Illinoisi Egyetemen végzett kutatása lehetővé tette számára, hogy gyakorlati támadást hozzon létre az RC4 ismert sebezhetősége ellen a TLS-munkamenet veszélyeztetése érdekében. Ez volt az egyik első ilyen kísérlet, amelyet nyilvánosságra hoztak.

Tavaly júliusban belga kutatók megtámadták az RC4-et, lehetővé téve az áldozat cookie-jának lehallgatását és visszafejtését, sokkal rövidebb idő alatt, mint azt korábban lehetségesnek tartották.

Hasonló cikkek