Ssl tls akceptujú všetky certifikáty. Uistite sa, že ssl a tls sú povolené

Sieťové protokoly SSL a TLS sú kryptografické protokoly, ktoré poskytujú autentifikáciu a ochranu pred neoprávneným prístupom, narušením integrity prenášaných dát. Protokoly SSL/TLS sú navrhnuté tak, aby zabránili falšovaniu identity na strane klienta alebo servera, zverejneniu alebo skresleniu údajov. Na tieto účely sa používa spoľahlivá metóda autentifikácie, používa sa šifrovanie komunikačného kanála a kódy integrity správ. Predvolený port pre SSL/TLS je port 443 pre HTTPS, 465 pre SMTPS (e-mail), 636 pre LDAPS, 563 pre NNTPS, 994 pre IRCS (chat), 995 pre POP3S.

SSL protokol

Protokol SSL bol vyvinutý spoločnosťou Netscape na zabezpečenie údajov medzi servisnými a transportnými protokolmi. Prvá publikovaná verzia bola vydaná v roku 1995. Široko používaný pre aplikácie VoIP, služby okamžitých správ. SSL je zabezpečený kanál, ktorý má nasledujúce vlastnosti:

• Súkromný kanál. Všetky správy sú zašifrované po dialógu potrebnom na určenie šifrovacieho kľúča.
• Kanál je overený. Autentifikácia je voliteľná pre stranu klienta, ale povinná pre stranu servera.
• Spoľahlivosť kanála. Pri prenose správ sa vykoná kontrola integrity pomocou MAC.

Protokol SSL používa symetrické aj asymetrické kľúče.

Vlastnosti a účel protokolu SSL

Protokol SSL poskytuje riešenie dvoch problémov – šifrovanie prenášaných informácií a prenos informácií presne tam, kde je to potrebné (autentifikácia). Hlavným účelom protokolu je poskytnúť spoľahlivý spôsob výmeny údajov medzi aplikáciami. Implementácia SSL je implementovaná ako viacvrstvové prostredie, ktoré slúži na bezpečný prenos informácií cez nezabezpečené komunikačné kanály.

Vrstvená štruktúra je reprezentovaná vrstvou protokolu potvrdenia spojenia a vrstvou protokolu záznamu. Prvou vrstvou je transportný protokol, napríklad TCP - spolu s protokolom SSL Record Protocol tvoria tieto vrstvy jadro SSL, ktoré sa následne podieľa na tvorbe komplexných infraštruktúr.

Medzi hlavné črty protokolu SSL treba poznamenať nezávislosť od softvérovej platformy. V súčasnosti protokol SSL neposkytuje dostatočnú ochranu – bol nahradený protokolom TLS.

protokol TLS

Protokol TLS je kryptografický protokol, ktorý sa používa na bezpečný prenos údajov medzi rôznymi uzlami na internete. Tento protokol našiel uplatnenie v aplikáciách VoIP, webových prehliadačoch, aplikáciách na odosielanie okamžitých správ. TLS je implementované na špecifikácii SSL 3.0. Na vývoji a vývoji protokolu sa podieľa IETF.

Medzi hlavné bezpečnostné opatrenia poskytované protokolom TLS patria:

• Použitie kľúča na overenie autentifikačného kódu správy.
• Eliminuje možnosť downgradu TLS alebo jeho nahradenia menej bezpečným sieťovým protokolom.
• Správa handshake obsahuje hash všetkých správ, ktoré si strany vymenili.
• Použitie číslovania záznamov aplikácie pomocou MAC.
• Použitie pseudonáhodnej funkcie, ktorá rozdeľuje vstupné správy na 2 časti, z ktorých každá je spracovaná inou hašovacou funkciou.

Vlastnosti a účel protokolu TLS

Protokol TLS používa nasledujúce algoritmy:

• RC4, Triple DES, SEED, IDEA atď. pre symetrické šifrovanie.
• RSA, DSA, Diffie-Hellman a ECDSA pre autentifikáciu kľúčov.
• MD5, SHA a SHA-256/384 pre hašovacie funkcie.

Aplikácie si vymieňajú záznamy, ktoré uchovávajú údaje. Záznamy môžu byť komprimované, vyplnené, šifrované alebo identifikované. V tomto prípade každý záznam obsahuje údaje o dĺžke paketu a použitej verzii TLS.

Vo všeobecnosti použitie kryptografie v protokoloch SSL / TLS výrazne znižuje výkon aplikácie, ale poskytuje spoľahlivú ochranu prenos dát. Protokoly nevyžadujú takmer žiadne nastavenia na strane klienta a sú považované za najbežnejšie bezpečnostné protokoly na internete.

Čo je to podanie ruky TLS a ako to funguje

TLS je jedným z najčastejšie používaných bezpečnostných nástrojov na internete. Protokol aktívne spolupracuje s mnohými sieťovými procesmi: prenos súborov, pripojenie VPN (v niektorých implementáciách na výmenu kľúčov), služby okamžitých správ alebo IP telefónia.

Jedným z kľúčových aspektov protokolu je podanie ruky. Práve o ňom budeme hovoriť v tomto článku.

"SSL/TLS handshake" je názov kroku nastavenia pripojenia HTTPS. Väčšina práce súvisiacej s protokolom SSL/TLS sa vykonáva v tejto fáze. Minulý rok IETF dokončila TLS 1.3 s kompletným prepracovaním procesu podávania rúk.
Článok sa bude zaoberať dvoma typmi handshake - pre protokoly TLS 1.2 a TLS 1.3, ktoré zvážime od abstraktnej úrovne a postupne sa ponoríme do funkcií:

• koordinácia kryptografických protokolov;
• autentifikácia pomocou SSL certifikátu;
• generovanie kľúča relácie.

Ako funguje podanie ruky TLS?

Pri pripojení HTTPS sa zúčastňujú dve strany: klient (iniciátor pripojenia, zvyčajne webový prehliadač) a server. Účelom SSL/TLS handshake je vykonať všetku kryptografickú prácu na vytvorenie bezpečného spojenia, vrátane overenia pravosti používaného certifikátu SSL a vygenerovania šifrovacieho kľúča.

Vyjednávanie šifrovacej sady

Každý softvér jedinečný. Preto aj tie najpopulárnejšie webové prehliadače majú rôzne funkcie. Podobne na strane servera - Windows Server, Apache a NGINX sú tiež odlišné. Veci sa ešte viac skomplikujú, keď pridáte vlastné konfigurácie.

Preto je prvým krokom TLS handshake výmena informácií o jeho schopnostiach medzi klientom a serverom pre ďalší výber podporovaných kryptografických funkcií.

Keď sa klient a server dohodnú na použití šifrovacej sady, server odošle svoj certifikát SSL klientovi.

Overenie

Po prijatí certifikátu klient skontroluje jeho pravosť. Ide o mimoriadne dôležitý krok. Aby bolo pripojenie bezpečné, musíte nielen zašifrovať údaje, ale musíte sa tiež uistiť, že sú odoslané na správnu webovú stránku. Certifikáty SSL/TLS poskytujú túto autentifikáciu a spôsob, akým to robia, závisí od použitej šifrovacej súpravy.

Všetky dôveryhodné certifikáty SSL vydáva certifikačná autorita (CA). Aby bola CA dôveryhodná, musí dodržiavať prísne pravidlá vydávania a overovania certifikátov. O CA si môžete predstaviť niečo ako notára – jeho podpis znamená, že údaje v certifikáte sú skutočné.

Počas autentifikačnej časti TLS handshake klient vykoná niekoľko kryptograficky bezpečných kontrol, aby sa uistil, že certifikát vydaný serverom je pravý. Proces zahŕňa kontrolu digitálny podpis a či je certifikát vydaný dôveryhodnou CA.

V tomto kroku klient nepriamo skontroluje, či server vlastní súkromný kľúč spojený s certifikátom.

V RSA, najbežnejšom kryptosystéme s verejným kľúčom, klient používa verejný kľúč na šifrovanie náhodných údajov, ktoré sa použijú na vygenerovanie kľúča relácie. Server bude môcť dešifrovať a použiť tieto údaje iba vtedy, ak má súkromný kľúč, ktorého prítomnosť zaisťuje autenticitu strany.

Ak sa použije iný kryptosystém, algoritmus sa môže zmeniť, ale autentifikácia druhej strany zostane zachovaná.

Výmena kľúčov

Posledná časť handshake TLS zahŕňa vytvorenie „kľúča relácie“, ktorý sa bude skutočne používať na zabezpečenú komunikáciu.

Kľúče relácie sú „symetrické“, čo znamená, že rovnaký kľúč sa používa na šifrovanie aj dešifrovanie.

Symetrické šifrovanie je rýchlejšie ako asymetrické šifrovanie, vďaka čomu je vhodnejšie na odosielanie údajov cez pripojenie HTTPS. Presná metóda generovania kľúča závisí od zvoleného šifrovacieho balíka, pričom dva najbežnejšie sú RSA a Diffie-Hellman.

Aby bolo podanie ruky dokončené, každá strana informuje druhú, že dokončila všetko potrebná práca a potom overí kontrolné súčty, aby sa uistil, že podanie ruky prebehlo bez akejkoľvek manipulácie alebo poškodenia.

Celé nadviazanie spojenia SSL sa uskutoční v priebehu niekoľkých stoviek milisekúnd. Toto je prvá vec, ktorá sa stane pri pripojení HTTPS, ešte pred načítaním webovej stránky. Po nadviazaní spojenia SSL sa spustí šifrované a overené pripojenie HTTPS a všetky údaje odoslané a prijaté klientom a serverom sú chránené.

Až do TLS 1.3 sa podanie ruky opakovalo zakaždým, keď ste navštívili stránku. TLS 1.3 handshake podporuje 0-RTT alebo nulový čas spiatočnej cesty, čo výrazne zvyšuje rýchlosť pre vracajúceho sa návštevníka.

Postup podávania rúk krok za krokom v TLS 1.2

Pozrime sa bližšie na handshake TLS pomocou RSA. Použitie Diffie-Hellmanovho algoritmu bude opísané nižšie.

1. Prvá správa sa volá „klient Dobrý deň“. Táto správa uvádza možnosti klienta, takže server si môže vybrať šifrovací balík, ktorý použije na komunikáciu. Správa tiež obsahuje veľké náhodne vybrané prvočíslo, nazývané „náhodné číslo zákazníka“.
2. Server zdvorilo odpovie správou „Server Hello“. Tam klientovi oznámi, aké možnosti pripojenia boli zvolené, a vráti svoje náhodne zvolené prvočíslo, nazývané „náhodné číslo servera“. Ak klient a server nezdieľajú šifrovacie sady, spojenie zlyhá.
3. V správe „Certifikát“ server odošle svoj reťazec certifikátov SSL klientovi, ktorý zahŕňa listové a prechodné certifikáty. Po ich obdržaní klient vykoná niekoľko kontrol na overenie certifikátu. Klient musí tiež zabezpečiť, aby server mal súkromný kľúč certifikát, ku ktorému dochádza počas procesu výmeny/generovania kľúča.
4. Toto je voliteľná správa, ktorá sa vyžaduje iba pri určitých metódach výmeny kľúčov (napríklad Diffie-Hellman), ktoré vyžadujú dodatočné údaje zo servera.
5. Správa „Server Hello Done“ oznamuje klientovi, že server dokončil prenos údajov.
6. Klient sa potom podieľa na generovaní kľúča relácie. Špecifiká tohto kroku závisia od spôsobu výmeny kľúčov, ktorý bol zvolený v pôvodných správach „Ahoj“. Keďže sa pozeráme na RSA, klient vygeneruje náhodný reťazec bajtov nazývaný pre-master secret, zašifruje ho verejným kľúčom servera a odošle ho späť.
7. Správa „Change Cipher Spec“ informuje druhú stranu, že kľúč relácie bol vygenerovaný a môže prejsť na šifrované pripojenie.
8. Potom sa odošle správa „Finished“ (Dokončené), čo znamená, že handshake je dokončený na strane klienta. Od tohto momentu je pripojenie chránené kľúčom relácie. Správa obsahuje údaje (MAC), ktoré možno použiť na overenie, či sa s podaním ruky nemanipulovalo.
9. Server teraz dešifruje predmaster tajný kľúč a vypočíta kľúč relácie. Potom odošle správu „Change Cipher Spec“ s upozornením, že prechádza na šifrované pripojenie.
10. Server tiež odošle správu "Dokončené" pomocou novo vygenerovaného kľúča symetrickej relácie a overí kontrolný súčet, aby overil integritu celého handshake.

Po týchto krokoch je nadviazanie spojenia SSL dokončené. Obe strany teraz majú kľúč relácie a môžu komunikovať cez šifrované a overené pripojenie.

V tomto bode môžu byť odoslané prvé bajty webovej aplikácie (údaje súvisiace so skutočnou službou - HTML, Javascript atď.).

Postup podávania rúk krok za krokom v TLS 1.3

TLS 1.3 handshake je výrazne kratší ako jeho predchodca.

1. Rovnako ako v prípade TLS 1.2, správa „Klient Dobrý deň“ spúšťa podanie ruky, ale tentoraz obsahuje oveľa viac informácií. TLS 1.3 znížil počet podporovaných šifier z 37 na 5. To znamená, že klient vie odhadnúť, ktorá dohoda kľúča alebo protokol výmeny sa použije, a tak okrem správy posiela aj svoju časť verejného kľúča z predpokladaného protokolu.
2. Server odpovie správou „Server Hello“. Rovnako ako pri podaní ruky 1.2 sa v tomto bode odošle certifikát. Ak klient správne uhádol šifrovací protokol s pripojenými údajmi a server s tým súhlasil, server odošle svoju časť verejného kľúča, vypočíta kľúč relácie a dokončí prenos správou „Server dokončený“.
3. Teraz, keď má klient všetky informácie, ktoré potrebuje, overí certifikát SSL a použije dva verejné kľúče na výpočet svojej kópie kľúča relácie. Po dokončení odošle správu „Klient je dokončený“.

TLS handshake nad hlavou

Historicky jednou zo sťažností na SSL/TLS bolo, že preťažovalo servery dodatočnou réžiou. To prispelo k dnes už zaniknutej predstave, že HTTPS je pomalší ako HTTP.

Handshake pred TLS 1.2 vyžadovali veľa zdrojov a vo veľkom meradle mohli vážne zaťažiť server. Dokonca aj TLS 1.2 handshake môže veci spomaliť, ak sa ich deje veľa súčasne. Autentifikácia, šifrovanie a dešifrovanie sú drahé procesy.

Na menších weboch to pravdepodobne veci výrazne nespomalí, ale pre podnikové systémy, kam denne prichádzajú státisíce návštevníkov, to môže byť veľký problém. Každý novú verziu handshake tento proces značne zjednodušujú: TLS 1.2 má dve fázy, zatiaľ čo TLS 1.3 sa zmestí len do jednej a podporuje 0-RTT.

Vylepšenia handshake TLS 1.3 oproti TLS 1.2

Vo vyššie uvedenom vysvetlení je podanie ruky rozdelené do desiatich samostatných krokov. V skutočnosti sa mnohé z týchto vecí dejú súčasne, takže sú často zoskupené a nazývané fázy.

TLS 1.2 handshake má dve fázy. Niekedy môžu byť potrebné ďalšie, ale pokiaľ ide o množstvo, predvolený je najlepší scenár.

Na rozdiel od 1.2 sa handshake TLS 1.3 zmestí do jednej fázy, aj keď presnejšie by bolo povedať jeden a pol, ale stále je oveľa rýchlejší ako TLS 1.2.

Redukcia šifrovacích súprav

Nikto nikdy nepoužil 37 súborov na šifrovanie údajov, tak sa protokol vyvinul. Zakaždým, keď bol pridaný nový algoritmus, boli pridané nové kombinácie a čoskoro IANA spravovala 37 rôznych šifrovacích sád.

Je to zlé z dvoch dôvodov:

1. Táto variabilita vedie k nesprávnym konfiguráciám, ktoré spôsobujú, že používatelia internetu sú zraniteľní voči známym exploitom.
2. To spôsobilo, že nastavenie SSL bolo mätúce.

IETF odstránila podporu pre všetky algoritmy okrem najbezpečnejších v TLS 1.3, čím sa odstránil zmätok obmedzením výberu. Odstránil sa najmä výber spôsobu výmeny kľúčov. Efemérna schéma Diffie-Hellman sa stala jediným spôsobom, ako môže klient poslať svoje kľúčové informácie spolu s „klientom ahoj“ v prvej časti handshake. Šifrovanie RSA bolo úplne odstránené spolu so všetkými ostatnými schémami výmeny statických kľúčov.

Ako už bolo povedané, v TLS 1.3 existuje jedna potenciálna Achillova päta.

Nulový čas opätovného prenosu - 0-RTT

0-RTT je to, na čo sa celý technologický svet zameriaval, a tu je to s TLS 1.3. Ako už bolo spomenuté, TLS handshake bol historicky pomalý, preto bolo dôležité ho urýchliť. 0-RTT to robí uložením niektorých tajných informácií o klientovi, zvyčajne ID relácie alebo lístkov relácie, na použitie pri ďalšom pripojení.

Napriek všetkým výhodám 0-RTT obsahuje niekoľko potenciálnych úskalí. Tento režim robí klientov náchylnými na opakované útoky, kde útočník, ktorému sa nejakým spôsobom podarí získať prístup k šifrovanej relácii, môže získať údaje 0-RTT vrátane prvej požiadavky klienta a odoslať ich späť na server.

Využívanie exploitu však nie je jednoduché. Pravdepodobne je takýmto rizikom malá cena za mimoriadne užitočnú funkciu.

Bezpečnosť

Od samého začiatku znepokojovalo množstvo informácií odosielaných v čistom texte počas podávania rúk. To je zjavne neisté, takže čím viac krokov handshake sa uskutoční v zašifrovanej forme, tým lepšie.

Pri handshake TLS 1.2 neboli vyjednávacie kroky bezpečné, namiesto toho sa použila jednoduchá funkcia MAC, ktorá zabránila komukoľvek zasahovať do prenosu. Fáza vyjednávania zahŕňa správy „Pozdrav klienta“ a „Pozdrav servera“.

Funkcia MAC funguje ako indikátor, ale neposkytuje žiadne záruky bezpečnosti. Možno ste už počuli o útoku, ktorý núti strany používať menej bezpečné protokoly a funkcie (útok na nižšiu verziu). Ak server aj klient podporujú zastarané šifrovacie sady – to sa dá ľahko získať počúvaním spojenia – útočník môže zmeniť šifrovanie zvolené serverom na slabšie. Takéto útoky nie sú samy osebe nebezpečné, ale otvárajú dvere k ďalším známym exploitom tých šifrovacích súprav, na ktoré sa pôvodne vybraná šifra zmenila.

Handshake TLS 1.3 využíva digitálny podpis v počiatočných fázach pripojenia, vďaka čomu je bezpečnejšie a chráni pred útokmi na zmenu šifrovacieho balíka. Podpis tiež umožňuje rýchlejšie a efektívnejšie overenie servera.

Teraz sa pozrime, ako budú tieto aktualizácie handshake TLS 1.3 implementované vo všetkých troch hlavných funkciách samotného handshaku SSL/TLS.

TLS handshake šifrovacie súpravy

Šifrovací balík je sada algoritmov, ktoré určujú parametre zabezpečeného pripojenia.

Na začiatku akéhokoľvek pripojenia je úplne prvá interakcia, „klient Hello“, zoznam podporovaných šifrovacích súprav. Server si vyberie najlepšiu a najbezpečnejšiu možnosť, ktorú podporuje a spĺňa jeho požiadavky. Môžete sa pozrieť na šifrovací balík a zistiť všetky parametre handshake a pripojenia.

šifrovacie súpravy TLS 1.2

• TLS je protokol.
• ECDHE je algoritmus výmeny kľúčov.
• ECDSA je autentifikačný algoritmus.
• AES 128 GCM je symetrický šifrovací algoritmus.
• SHA256 je hashovací algoritmus.

Vyššie uvedený príklad používa systém efemérnej eliptickej krivky Diffie-Hellman (DH) na výmenu kľúčov a algoritmus digitálneho podpisu s eliptickou krivkou na autentifikáciu. DH možno tiež pripojiť k RSA (funguje ako algoritmus digitálneho podpisu) na vykonanie autentifikácie.

Tu je zoznam najviac podporovaných šifrovacích balíkov TLS 1.2:

šifrovacie súpravy TLS 1.3

• TLS je protokol.
• AES 256 GCM – overené šifrovanie s pripojenými údajmi (AEAD).
• SHA384 je algoritmus funkcie generovania hashovaných kľúčov (HKFD).

Už vieme, že budeme používať nejakú verziu efemérnej výmeny kľúčov Diffie-Hellman, ale nepoznáme parametre, takže prvé dva algoritmy v šifrovacej sade TLS 1.2 už nie sú potrebné. Tieto funkcie sú stále spustené, len ich už nie je potrebné vyjednávať počas podávania rúk.

Z vyššie uvedeného príkladu môžete vidieť, že AES (Advanced Encryption Standard) sa používa na šifrovanie veľkého množstva údajov. Funguje v režime počítadla Galois pomocou 256-bitových kľúčov.

Tu je päť šifrovacích balíkov, ktoré sú podporované v TLS 1.3:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

Čo sa zmenilo v TLS 1.3 v porovnaní s TLS 1.2?

Je dôležité si zapamätať, že pri vytváraní verzie 1.3 boli hlavným cieľom vylepšenia bezpečnosti a výkonu. Na tento účel TLS 1.3 prepracoval algoritmus generovania kľúčov a opravil známe zraniteľnosti.

Handshake TLS 1.3 tiež zlepšil niektoré procesy, ako je autentifikácia správ a digitálne podpisy.

Nakoniec, okrem postupného vyraďovania starých algoritmov generovania kľúčov alebo výmeny, TLS 1.3 eliminuje staré symetrické šifry. TLS 1.3 úplne odstránil blokové šifry. Jediný typ symetrickej šifry povolený v TLS 1.3 sa nazýva Auxiliary Authenticated Encryption (AEAD). Spája šifrovanie a autentifikáciu správ (MAC) do jednej funkcie.

Autentifikácia v TLS handshake

Historicky sú dve hlavné kľúčové burzy RSA a Diffie-Hellman (DH), v súčasnosti sa DH často spája s eliptickými krivkami (ECDH). Napriek niektorým základným podobnostiam existujú medzi týmito dvoma kľúčovými výmennými prístupmi zásadné rozdiely.

Inými slovami, handshake RSA TLS sa líši od handshake ECDH TLS.

RSA používa jednoduchú faktorizáciu a modulárnu aritmetiku. Veľké prvočísla vyžadujú na výpočet veľa výkonu CPU a je ťažké ich vyzdvihnúť.

Diffie-Hellman je niekedy označovaný ako exponenciálna výmena kľúčov, čo naznačuje umocnenie (okrem modulárnej aritmetiky), ale samotný DH v skutočnosti nešifruje ani nedešifruje vôbec nič. Takže nazývať to „metódou šifrovania“ namiesto „matematického zdôvodnenia“ môže byť trochu zavádzajúce.

Krátka odbočka do histórie môže tento bod objasniť.

Whitfield Diffie a Martin Hellman už v roku 1976 vytvorili protokol výmeny kľúčov na základe diela Ralpha Merkla, ktorého meno by sa podľa oboch malo objaviť aj v názve protokolu.

Pokúsili sa vyriešiť problém bezpečnej výmeny kľúčov cez nezabezpečený kanál, aj keď ho odpočúva útočník. Podarilo sa im to, ale malo to jednu vážnu nevýhodu: výmena DH kľúčov nezahŕňala autentifikáciu, takže nebolo možné overiť stranu na druhom konci spojenia.

To možno považovať za zrod kryptografie s verejným kľúčom a PKI. Krátko po tom, čo Diffie a Hellman predstavili svoj protokol na výmenu kľúčov, boli dokončené najskoršie verzie kryptosystému RSA. Diffie a Hellman vytvorili koncept šifrovania verejným kľúčom, ale ešte neprišli so skutočnou funkciou jednosmerného šifrovania.

Bol to Ron Rivest (R v RSA), ktorý vytvoril koncept, ktorý sa nakoniec stal kryptosystémom RSA.

RSA je v mnohých ohľadoch duchovným nástupcom DH. Vykonáva:

• generovanie kľúčov;
• výmena kľúčov;
• šifrovanie;
• dešifrovanie.

RSA je teda funkčnejší algoritmus, ktorý dokáže spracovať výmenu kľúčov aj digitálne podpisy, t. j. okrem bezpečnej výmeny kľúčov vykonáva aj autentifikáciu. Preto má RSA väčšie kľúče: pre digitálny podpis musí byť zabezpečená dostatočná bezpečnosť.

Zatiaľ čo RSA rieši autentifikáciu a výmenu kľúčov, Diffie-Hellman iba uľahčuje výmenu kľúčov. Existujú štyri bežné varianty rodiny DH:

• Diffie-Hellman (DH);
• efemérne (krátkodobé) Diffie-Hellman (DHE);
• eliptická krivka Diffie-Hellman (ECDH);
• eliptická krivka efemérna Diffie-Hellman (ECDHE).

Opäť platí, že Diffie-Hellman sám o sebe nič nepotvrdzuje. Musí sa používať v spojení s algoritmom digitálneho podpisu. Ak ste teda napríklad použili ECDH alebo ECDHE, väčšina šifrovacích súprav sa spáruje s algoritmom ECDSA (Eliptic Curve Digital Signature Algorithm) alebo RSA.

Overenie handshake TLS 1.2

Ako už bolo spomenuté, dodatočná funkcia RSA na overenie digitálneho podpisu vyžaduje veľké kľúče, ktoré sú odolné voči útokom hrubou silou. Veľkosť týchto kľúčov výrazne zvyšuje náklady na výpočtovú techniku, ich šifrovanie a dešifrovanie počas handshake.

Na druhej strane, ak sa Diffie-Hellman neoverí, čo potom urobí? Ako je uvedené vyššie, DH sa často používa v spojení s kryptografiou eliptickej krivky na zabezpečenie autentifikácie a výmeny kľúčov.

Eliptická kryptografia (ECC) má oveľa menšie veľkosti kľúčov, ktoré zodpovedajú eliptickej krivke, na ktorej sú založené. Pre tento kontext existuje päť vhodných kriviek:

• 192 bitov;
• 224 bitov;
• 256 bitov;
• 384 bitov;
• 521 bitov

Ale to nie je jediný rozdiel medzi verejnými/súkromnými kľúčmi ECC a kľúčmi RSA. Používajú sa na dva úplne odlišné účely počas podávania rúk TLS.

RSA používa pár verejných/súkromných kľúčov na autentifikáciu servera aj výmenu kľúčov symetrickej relácie. V skutočnosti je to úspešné použitie tajného kľúča na dešifrovanie tajomstva (predhlavného tajného kľúča), ktoré overuje server.

Pri Diffie-Hellman sa pár verejný/súkromný kľúč NEPOUŽÍVA na symetrickú výmenu kľúčov relácie. Keď je zapojený Diffie-Hellman, súkromný kľúč je v skutočnosti spojený so sprievodným podpisovým algoritmom (ECDSA alebo RSA).

RSA autentifikácia

Proces autentifikácie RSA je prepojený s procesom výmeny kľúčov. Presnejšie povedané, výmena kľúčov je súčasťou procesu autentifikácie.

Keď je klientovi poskytnutý certifikát SSL servera, kontroluje niekoľko metrík:

• digitálny podpis pomocou verejného kľúča;
• reťaz certifikátov, aby ste sa uistili, že certifikát pochádza z jedného z koreňových certifikátov v dôveryhodnom úložisku;
• dátum vypršania platnosti, aby ste sa uistili, že nevypršala;
• stav zrušenia certifikátu.

Ak všetky tieto kontroly prebehnú úspešne, vykoná sa posledný test – klient zašifruje pre-master tajomstvo verejným kľúčom servera a odošle ho. Každý server sa môže pokúsiť vydať akýkoľvek certifikát SSL/TLS za svoj vlastný. Ide predsa o verejné certifikáty. Klient tak môže autentifikovať server tak, že uvidí súkromný kľúč „v akcii“.

Ak teda server dokáže dešifrovať pred-hlavný tajný kľúč a použiť ho na výpočet kľúča relácie, je mu udelený prístup. Toto potvrdzuje, že server je vlastníkom použitého páru verejný/súkromný kľúč.

DH autentifikácia

Keď sa používajú Diffie-Hellman a ECDSA/RSA, autentifikácia a výmena kľúčov sú nasadené vedľa seba. A to nás privádza späť ku kľúčom a ich použitiu. Verejný/súkromný kľúč RSA sa používa na výmenu kľúčov aj autentifikáciu. V DH + ECDSA/RSA sa asymetrický pár kľúčov používa iba na digitálny podpis alebo autentifikačný krok.

Keď klient dostane certifikát, stále vykonáva štandardné kontroly:

• overí podpis na certifikáte,
• reťaz certifikátov
• platnosť,
• stav spätnej väzby.

Vlastníctvo súkromného kľúča sa však overuje inak. Počas výmeny TLS handshake kľúča (krok 4) server používa svoj súkromný kľúč na zašifrovanie náhodného čísla klienta a servera, ako aj jeho parametra DH. Funguje ako digitálny podpis servera a klient môže použiť priradený verejný kľúč na overenie, že server je právoplatným vlastníkom páru kľúčov.

Overenie handshake TLS 1.3

V TLS 1.3 hrá autentifikácia a digitálne podpisy stále dôležitú úlohu, ale boli odstránené zo šifrovacích balíkov, aby sa zjednodušilo vyjednávanie. Sú implementované na strane servera a používajú niekoľko algoritmov podporovaných serverom kvôli ich bezpečnosti a všadeprítomnosti. V TLS 1.3 sú povolené tri hlavné podpisové algoritmy:

• RSA (iba podpis),
• Algoritmus digitálneho podpisu eliptickej krivky (ECDSA),
• Edwardsov algoritmus digitálneho podpisu (EdDSA).

Na rozdiel od handshake TLS 1.2 nesúvisí overovacia časť handshaku TLS 1.3 so samotnou výmenou kľúčov. Skôr sa spracováva paralelne s výmenou kľúčov a autentifikáciou správ.

Namiesto spustenia symetrického MAC na kontrolu integrity handshake server podpíše celý dešifrovací hash, keď vráti "Server Hello" s jeho časťou verejného kľúča.

Klient dostane všetky informácie odoslané s "Server Hello" a vykoná štandardnú sériu kontrol SSL/TLS certifikátov. Zahŕňa overenie podpisu na certifikáte a následné overenie zhody podpisu, ktorý bol pridaný do dešifrovacieho hashu.

Zhoda potvrdzuje, že server vlastní súkromný kľúč.

Výmena kľúčov v TLS handshake

Ak zvýrazníte hlavnú myšlienku tejto časti, bude to znieť takto:

RSA uľahčuje výmenu kľúčov tým, že umožňuje klientovi zašifrovať zdieľané tajomstvo a odoslať ho na server, kde sa použije na výpočet zodpovedajúceho kľúča relácie. Výmena kľúča DH v skutočnosti vôbec nevyžaduje výmenu verejného kľúča, ale obe strany vytvárajú kľúč spoločne.

Ak to teraz znie trochu abstraktne, na konci tejto časti by to malo byť jasné.

Výmena kľúčov RSA

Nazvať to výmena kľúčov RSA je v skutočnosti nesprávne pomenovanie. Je to vlastne šifrovanie RSA. RSA používa na generovanie kľúča relácie asymetrické šifrovanie. Na rozdiel od DH zohráva veľkú úlohu kľúčový pár verejný/súkromný.

Tu je postup:

1. X A r
2. Klient generuje predmajstrovské tajomstvo(a) a potom použije verejný kľúč servera na jeho zašifrovanie a odoslanie na server.
3. Server dešifruje predmajstrovské tajomstvo s príslušným súkromným kľúčom. Teraz majú obe strany všetky tri vstupné premenné a zmiešajú ich s niektorými pseudonáhodnými funkciami (PRF), aby vytvorili hlavný kľúč.
4. Obe strany zmiešajú hlavný kľúč s ešte väčším počtom PRF a nakoniec získajú zodpovedajúce kľúče relácie.

Výmena kľúčov DH

ECDH funguje takto:

1. Klient a server si vymenia dve prvočísla ( X A r), ktoré sa nazývajú náhodné čísla.
2. Jedna strana si zvolí tajné volané číslo predmajstrovské tajomstvo a) a vypočíta: x a mod y. Potom pošle výsledok (A) inému účastníkovi.
3. Druhá strana robí to isté, vyberá si svoju vlastnú predmajstrovské tajomstvo b) a vypočíta x b mod y a potom odošle späť svoju hodnotu (B).
4. Obe strany ukončia túto časť prijatím daných hodnôt a zopakovaním operácie. Človek počíta b a mod y, druhý počíta a b mod y.

Existuje vlastnosť modulo exponents, ktorá hovorí, že každá strana dostane rovnakú hodnotu, ktorá bude kľúčom používaným na symetrické šifrovanie počas spojenia.

TLS 1.2 handshake pre DH

Teraz, keď sme videli, ako sa DH líši od RSA, poďme sa pozrieť na to, ako vyzerá handshake TLS 1.2 na báze DH.

Medzi týmito dvoma prístupmi je opäť veľa podobností. Na výmenu kľúčov použijeme ECDHE a na autentifikáciu ECDSA.

1. Rovnako ako v prípade RSA, klient začína správou „Client Hello“, ktorá obsahuje zoznam šifrovacích súprav, ako aj náhodné číslo klienta.
2. Server odpovie správou „Server Hello“, ktorá obsahuje vybraný šifrovací balík a náhodné číslo servera.
3. Server odošle svoj certifikát SSL. Rovnako ako pri handshake RSA TLS klient vykoná sériu kontrol overenia certifikátu, ale keďže samotný DH nedokáže overiť server, je potrebný ďalší mechanizmus.
4. Na overenie server vezme náhodné čísla klienta a servera, ako aj parameter DH, ktorý sa použije na výpočet kľúča relácie, a zašifruje ich svojím súkromným kľúčom. Výsledok bude fungovať ako digitálny podpis: klient použije verejný kľúč na overenie podpisu a toho, že server je právoplatným vlastníkom páru kľúčov, a odpovie vlastnou voľbou DH.
5. Server ukončí túto fázu správou „Server Hello Done“.
6. Na rozdiel od RSA, klient nemusí posielať pre-master tajný kľúč na server pomocou asymetrického šifrovania, namiesto toho klient a server používajú DH parametre, ktoré si vymenili predtým, aby získali pre-master tajomstvo. Každý potom použije predmajstrovský tajný kľúč, ktorý práve vypočítal, aby získal rovnaký kľúč relácie.
7. Klient odošle správu „Change Cipher Spec“ s cieľom informovať druhú stranu, že prešla na šifrovanie.
8. Klient odošle záverečnú správu „Dokončené“, aby oznámil, že dokončil svoju časť handshake.
9. Podobne server odošle správu „Change Cipher Spec“.
10. Podanie ruky sa končí správou „Dokončené“ zo servera.

Výhody DHE oproti RSA

Existujú dva hlavné dôvody, prečo kryptografická komunita uprednostňuje používanie DHE pred RSA: dokonalé dopredné utajenie a známe zraniteľnosti.

Dokonalé dopredné tajomstvo

Možno ste sa predtým pýtali, čo znamená slovo „efemérny“ na konci DHE a ECDHE. Ephemeral doslova znamená „krátkodobý“. A môže pomôcť porozumieť Perfect Forward Secrecy (PFS), čo je vlastnosť niektorých protokolov výmeny kľúčov. PFS zaisťuje, že kľúče relácie vymieňané medzi stranami nemôžu byť kompromitované, aj keď je ohrozený súkromný kľúč certifikátu. Inými slovami, chráni predchádzajúce relácie pred extrahovaním a dešifrovaním. PFS dostal najvyššiu prioritu po objavení chyby Heartbleed. Toto je základná súčasť TLS 1.3.

Zraniteľnosť výmeny kľúčov RSA

Existujú chyby zabezpečenia, ktoré by mohli zneužiť výplň ( vypchávka) používané počas výmeny kľúčov v starších verziách RSA (PKCS #1 1.5). Toto je jeden z aspektov šifrovania. V prípade RSA musí byť pred-master tajný kód zašifrovaný verejným kľúčom a dešifrovaný súkromným kľúčom. Ale keď sa toto menšie tajomstvo pred majstrom zmestí do väčšieho verejného kľúča, musí byť vyplnené. Vo väčšine prípadov, ak sa pokúsite uhádnuť výplň a odoslať falošnú požiadavku na server, pomýlite sa a rozpozná nesúlad a odfiltruje ju. Existuje však veľká šanca, že na server môžete odoslať dostatok požiadaviek na uhádnutie správnej výplne. Server by potom odoslal chybne dokončenú správu, ktorá by následne zúžila možnú hodnotu tajného tajomstva pred hlavným kľúčom. To umožní útočníkovi vypočítať a kompromitovať kľúč.

To je dôvod, prečo bol RSA odstránený v prospech DHE v TLS 1.3.

Výmena kľúčov v TLS 1.3 handshake

V TLS 1.3 handshake, kvôli obmedzenému výberu schém výmeny kľúčov, môže klient úspešne uhádnuť schému a poslať svoju časť zdieľaného kľúča počas úvodnej fázy (Client Hello) handshake.

RSA nebola jediná schéma výmeny kľúčov, ktorá bola odstránená v TLS 1.3. Boli tiež odstránené neefemérne schémy Diffie-Hellman, ako aj zoznam nedostatočne bezpečných parametrov Diffie-Hellman.

Čo znamená nedostatočne zabezpečené parametre? Bez toho, aby sme zachádzali do matematiky, zložitosť Diffie-Hellmana a väčšiny kryptosystémov s verejným kľúčom je zložitosťou riešenia diskrétnych logaritmických problémov. Kryptosystém musí byť dostatočne zložitý na to, aby sa dal vypočítať, ak vstupné parametre (náhodné čísla klienta a servera) nie sú známe, inak bude celá schéma zbytočná. Schémy Diffie-Hellman, ktoré nedokázali poskytnúť dostatočne veľké parametre, boli v TLS 1.3 zastarané.

1. Na začiatku handshake TLS 1.3, vediac, že ​​sa použije schéma dohody kľúča DHE, klient zahrnie svoju časť verejného kľúča na základe zamýšľanej schémy výmeny kľúčov do svojej správy Client Hello.
2. Server dostane tieto informácie a ak je klient správny, vráti svoju časť verejného kľúča v "Server Hello".
3. Klient a server vypočítajú kľúč relácie.

Je to veľmi podobné tomu, čo sa deje s DH pri handshake TLS 1.2, s výnimkou toho, že výmena kľúčov nastáva skôr v TLS 1.3.

Namiesto záveru

SSL/TLS handshake je vzrušujúci proces, ktorý je kľúčový bezpečný internet a predsa sa to deje tak rýchlo a potichu, že väčšina ľudí na to nikdy ani nepomyslí.

Aspoň kým sa niečo nepokazí.

Podľa požiadaviek ruskej legislatívy iba používanie spojení TLS vytvorených Ruskom kryptografické algoritmy GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 a GOST R 34.10-2001. Preto, ak potrebujete používať stránky, ktoré používajú šifrovanie podľa algoritmov GOST, musíte nainštalovať program " CryptoPro CSP» .

Na operačných sálach systémy Windows používa sa program CryptoPro CSP - sada kryptografických utilít na generovanie elektronický podpis, práca s certifikátmi

Ak chcete nainštalovať CryptoPro CSP, použite materiály z oficiálnej webovej stránky:

Po inštalácii CryptoPro Prehliadač CSP kontroluje existenciu a fungovanie tohto programu.

Stránky požadujúce šifrovanie GOST TLS

Ak stránka požaduje šifrovanie GOST TLS, prehliadač skontroluje, či je nainštalovaný CryptoPro CSP. Ak je program nainštalovaný, riadenie sa prenesie naň.

Príklady stránok požadujúcich šifrovanie: www.gosuslugi.ru , stránky na doméne .gov.ru, .kamgov.ru , .nalog.ru .

Ak stránka nie je v zozname, vyžaduje sa dodatočné potvrdenie. Ak stránke dôverujete a pripojenie sa musí uskutočniť pomocou šifrovania GOST TLS, kliknite na tlačidlo Pokračovať.

Všetky naše úvahy sú založené na skutočnosti, že používate Windows XP alebo novší (Vista, 7 alebo 8), ktorý má nainštalované všetky správne aktualizácie a záplaty. Teraz ešte jedna podmienka: dnes hovoríme o najnovších verziách prehliadačov a nie o „sférickom Ognelis vo vákuu“.

Nakonfigurujeme prehliadače tak, aby používali aktuálne verzie protokolu TLS a vôbec nepoužívali jeho zastarané verzie a SSL. V každom prípade, pokiaľ je to teoreticky možné.

A teória nám hovorí, že hoci internet Explorer od verzie 8 podporuje TLS 1.1 a 1.2, pod Windows XP a Vista ho k tomu nebudeme nútiť. Kliknite: Nástroje / Možnosti internetu / Rozšírené a v sekcii „Zabezpečenie“ nájdeme: SSL 2.0, SSL 3.0, TLS 1.0 ... našli ste niečo iné? Gratulujeme, budete mať TLS 1.1/1.2! Nenájdené – máte Windows XP alebo Vista a v Redmonde vás považujú za zaostalého.

Takže odstránime začiarknutia zo všetkých SSL, umiestnime ich na všetky dostupné TLS. Ak je k dispozícii iba TLS 1.0, tak áno, ak existujú aktuálnejšie verzie, je lepšie vybrať iba ich a zrušiť začiarknutie TLS 1.0 (a nečudovať sa neskôr, že niektoré stránky sa neotvárajú cez HTTPS) . Potom kliknite na tlačidlá "Použiť", "OK".

S Operou je to jednoduchšie – zorganizuje pre nás skutočný banket rôzne verzie protokoly: Nástroje/Všeobecné nastavenia/Rozšírené/Zabezpečenie/Bezpečnostné protokoly. čo vidíme? Celá množina, z ktorej ponecháme zaškrtávacie políčka len pre TLS 1.1 a TLS 1.2, potom klikneme na tlačidlo "Podrobnosti" a tam odškrtneme všetky riadky okrem tých, ktoré začínajú "256 bit AES" - sú na samom koniec. Na začiatku zoznamu je riadok „256 bit AES ( Anonymný DH/SHA-256), tiež zrušte začiarknutie. Kliknite na „OK“ a vychutnajte si bezpečnosť.

Opera má však jednu zvláštnu vlastnosť: ak je povolený TLS 1.0, tak ak je potrebné nadviazať zabezpečené spojenie, okamžite použije túto konkrétnu verziu protokolu, bez ohľadu na to, či stránka podporuje novšie. Akože, prečo sa namáhať – a všetko je v poriadku, všetko je chránené. Keď povolíte iba TLS 1.1 a 1.2, najprv sa pokúsi použiť pokročilejšiu verziu a iba ak ju stránka nepodporuje, prehliadač sa prepne na verziu 1.1.

Sférický Ognelis Firefox nás ale vôbec nepoteší: Nástroje / Nastavenia / Rozšírené / Šifrovanie: jediné, čo môžeme urobiť, je vypnúť SSL, TLS je k dispozícii len vo verzii 1.0, nedá sa nič robiť - nechávame to s tikotom.

V porovnaní s tým sa však dá zistiť zlé: Chrome a Safari neobsahujú vôbec žiadne nastavenia, ktorý šifrovací protokol použiť. Pokiaľ vieme, Safari nepodporuje verzie TLS novšie ako 1.0 vo verziách pod Windows, a keďže bolo prerušené vydávanie nových verzií pre tento OS, nebude.

Chrome, pokiaľ vieme, podporuje TLS 1.1, ale rovnako ako v prípade Safari nemôžeme odmietnuť používanie SSL. Zakázanie TLS 1.0 v prehliadači Chrome tiež nie je možné. Ale so skutočným používaním TLS 1.1 - veľká otázka: najprv bol zapnutý, potom vypnutý kvôli problémom v prevádzke a pokiaľ možno povedať, ešte nebol zapnutý. To znamená, že sa zdá, že podpora existuje, ale je, ako keby, vypnutá a neexistuje spôsob, ako ju znova zapnúť samotnému používateľovi. Rovnaký príbeh s Firefoxom - podpora TLS 1.1 v ňom v skutočnosti je, ale používateľovi ešte nie je k dispozícii.

Zhrnutie z vyššie uvedeného polylistu. Aké je nebezpečenstvo používania zastaraných verzií šifrovacích protokolov? To, že sa niekto iný dostane do vášho zabezpečeného pripojenia na stránku a získa prístup ku všetkým informáciám „tam“ a „tam“. Z praktického hľadiska bude plný prístup do krabice Email, účet v systéme klient-banka a pod.

Je nepravdepodobné, že sa bude možné náhodne dostať do zabezpečeného pripojenia niekoho iného, ​​hovoríme len o zlomyseľných akciách. Ak je pravdepodobnosť takýchto akcií nízka alebo informácie prenášané cez zabezpečené pripojenie nemajú osobitnú hodnotu, potom sa nemôžete obťažovať a používať prehliadače, ktoré podporujú iba TLS 1.0.

V opačnom prípade nie je na výber: iba Opera a iba TLS 1.2 (TLS 1.1 je len vylepšenie TLS 1.0, čiastočne zdedilo jeho bezpečnostné problémy). Naše obľúbené stránky však nemusia podporovať TLS 1.2 :(

TLS je nástupcom protokolu SSL, ktorý poskytuje bezpečné a zabezpečené pripojenie medzi uzlami na internete. Používa sa pri vývoji rôznych klientov, vrátane prehliadačov a aplikácií klient-server. Čo je TLS v Internet Exploreri?

Trochu o technológii

Používajú všetky podniky a organizácie, ktoré sa zaoberajú finančnými transakciami tento protokol vylúčiť odpočúvanie paketov a neoprávnený prístup narušiteľov. Táto technológia je navrhnutá tak, aby chránila dôležité spojenia pred škodlivými útokmi.

V podstate vo svojej organizácii používajú vstavaný prehliadač. V niektorých prípadoch - Mozilla Firefox.

Povoliť alebo zakázať protokol

Na niektoré stránky niekedy nie je možné pristupovať, pretože je zakázaná podpora technológií SSL a TLS. V prehliadači sa objaví upozornenie. Ako teda umožníte protokolom, aby naďalej používali zabezpečenú komunikáciu?
1. Otvorte Ovládací panel cez Štart. Iný spôsob: otvorte Prieskumníka a kliknite na ikonu ozubeného kolieska v pravom hornom rohu.

2. Prejdite do časti „Možnosti internetu“ a otvorte blok „Rozšírené“.

3. Začiarknite políčka vedľa položky „Použiť TLS 1.1 a TLS 1.2“.

4. Kliknutím na tlačidlo OK uložte zmeny. Ak chcete deaktivovať protokoly, čo sa dôrazne neodporúča, najmä ak používate Internet banking, zrušte začiarknutie rovnakých položiek.

Aký je rozdiel medzi 1.0 a 1.1 a 1.2? 1.1 je len mierne vylepšená verzia TLS 1.0, ktorá čiastočne zdedila svoje nedostatky. 1.2 je najbezpečnejšia verzia protokolu. Na druhej strane, nie všetky lokality sa môžu otvárať s touto povolenou verziou protokolu.

Ako viete, Skype messenger priamo súvisí s Internet Explorerom ako komponent Windows. Ak v nastaveniach nemáte zaškrtnutý protokol TLS, tak môžu nastať problémy so Skype. Program sa jednoducho nebude môcť pripojiť k serveru.

Ak je v nastaveniach Internet Explorera zakázaná podpora TLS, nebudú fungovať všetky sieťové funkcie programu. Okrem toho od tejto technológie závisí bezpečnosť vašich údajov. Nezanedbávajte to, ak áno finančné operácie v tomto prehliadači (nákupy v internetových obchodoch, prevody peňazí cez Internet banking alebo elektronickú peňaženku a pod.).