Ssl tls prihvataju sve sertifikate. Uvjerite se da su ssl i tls omogućeni

Mrežni protokoli SSL i TLS su kriptografski protokoli koji obezbeđuju autentifikaciju i zaštitu od neovlašćenog pristupa, narušavanja integriteta prenetih podataka. SSL/TLS protokoli su dizajnirani da spreče lažiranje identiteta na strani klijenta ili servera, otkrivanje podataka ili izobličenje. U ove svrhe koristi se pouzdana metoda provjere autentičnosti, koriste se šifriranje komunikacijskih kanala i kodovi integriteta poruka. Podrazumevani port za SSL/TLS je port 443 za HTTPS, 465 za SMTPS (e-pošta), 636 za LDAPS, 563 za NNTPS, 994 za IRCS (čet), 995 za POP3S.

SSL protokol

SSL protokol je razvio Netscape kako bi osigurao podatke između servisnih i transportnih protokola. Prva objavljena verzija objavljena je 1995. godine. Široko se koristi za VoIP aplikacije, usluge razmjene trenutnih poruka. SSL je siguran kanal koji ima sljedeća svojstva:

Privatni kanal. Sve poruke se šifriraju nakon dijaloga potrebnog za određivanje ključa za šifriranje.
Kanal je autentificiran. Autentifikacija je opciona za klijentsku stranu, ali obavezna za stranu servera.
Pouzdanost kanala. Kada se poruke prenose, vrši se provjera integriteta pomoću MAC-a.

SSL protokol koristi i simetrične i asimetrične ključeve.

Karakteristike i svrha SSL protokola

SSL protokol pruža rješenje za dva problema - enkripciju prenesenih informacija i prijenos informacija točno tamo gdje je to potrebno (autentifikacija). Glavna svrha protokola je da pruži pouzdan način za razmjenu podataka između aplikacija. Implementacija SSL-a je implementirana kao višeslojno okruženje, koje se koristi za siguran prijenos informacija kroz nezaštićene komunikacione kanale.

Slojevita struktura je predstavljena slojem protokola za potvrdu veze i slojem protokola snimanja. Prvi sloj je transportni protokol, na primjer, TCP - zajedno sa protokolom SSL Record Protocol, ovi slojevi čine jezgro SSL-a, koji naknadno učestvuje u formiranju složene infrastrukture.

Među glavnim karakteristikama SSL protokola treba istaći nezavisnost softvera od platforme. Trenutno, SSL protokol ne pruža adekvatnu zaštitu - zamijenjen je TLS protokolom.

TLS protokol

TLS protokol je kriptografski protokol koji se koristi za siguran prijenos podataka između različitih čvorova na Internetu. Ovaj protokol je našao primenu u VoIP aplikacijama, web pretraživačima, aplikacijama za razmenu trenutnih poruka. TLS je implementiran na SSL 3.0 specifikaciji. IETF je uključen u razvoj i razvoj protokola.

Glavne sigurnosne mjere koje pruža TLS protokol uključuju:

Upotreba ključa za provjeru koda za provjeru autentičnosti poruke.
Eliminiše mogućnost degradacije TLS-a ili njegove zamjene manje sigurnim mrežnim protokolom.
Poruka rukovanja sadrži hash svih poruka razmijenjenih između strana.
Korištenje numeracije zapisa aplikacije koristeći MAC.
Upotreba pseudo-slučajne funkcije koja dijeli ulazne poruke na 2 dijela, od kojih se svaki obrađuje različitom hash funkcijom.

Karakteristike i svrha TLS protokola

TLS protokol koristi sljedeće algoritme:

RC4, Triple DES, SEED, IDEA, itd. za simetrično šifrovanje.
RSA, DSA, Diffie-Hellman i ECDSA za autentifikaciju ključa.
MD5, SHA i SHA-256/384 za hash funkcije.

Aplikacije razmjenjuju zapise koji pohranjuju podatke. Zapisi mogu biti komprimirani, podstavljeni, šifrirani ili identificirani. U ovom slučaju, svaki unos sadrži podatke o dužini paketa i verziji TLS-a koji se koristi.

Općenito, upotreba kriptografije u SSL/TLS protokolima značajno smanjuje performanse aplikacije, ali osigurava pouzdana zaštita prijenos podataka. Protokoli ne zahtijevaju gotovo nikakva podešavanja na strani klijenta i smatraju se najčešćim sigurnosnim protokolima na Internetu.

Šta je TLS rukovanje i kako funkcioniše

TLS je jedan od najčešće korištenih sigurnosnih alata na Internetu. Protokol aktivno radi s mnogim mrežnim procesima: prijenos datoteka, VPN veza (u nekim implementacijama za razmjenu ključeva), usluge razmjene trenutnih poruka ili IP telefonija.

Jedan od ključnih aspekata protokola je rukovanje. O njemu ćemo govoriti u ovom članku.

"SSL/TLS rukovanje" je naziv koraka postavljanja HTTPS veze. Većina posla vezanog za SSL/TLS protokol se obavlja u ovoj fazi. Prošle godine, IETF je finalizirao TLS 1.3 uz potpunu reviziju procesa rukovanja.
Članak će pokriti dvije vrste rukovanja - za protokole TLS 1.2 i TLS 1.3, koje ćemo razmotriti počevši od apstraktnog nivoa i postepeno se upuštajući u karakteristike:

koordinacija kriptografskih protokola;
autentifikacija sa SSL certifikatom;
generiranje ključa sesije.

Kako funkcionira TLS rukovanje?

Dvije su strane uključene u HTTPS vezu: klijent (pokretač veze, obično web pretraživač) i server. Svrha SSL/TLS rukovanja je da obavi sav kriptografski posao za uspostavljanje sigurne veze, uključujući provjeru autentičnosti korištenog SSL certifikata i generiranje ključa za šifriranje.

Pregovaranje o skupu šifri

Svaki softver jedinstven. Stoga čak i najpopularniji web pretraživači imaju različite funkcionalnosti. Slično, na strani servera - Windows Server, Apache i NGINX su takođe različiti. Stvari postaju još složenije kada dodate prilagođene konfiguracije.

Zato je prvi korak TLS rukovanja razmjena informacija o njegovim mogućnostima između klijenta i servera za daljnji odabir podržanih kriptografskih funkcija.

Jednom kada se klijent i server dogovore oko paketa šifriranja koji će koristiti, server šalje svoj SSL certifikat klijentu.

Autentifikacija

Po dobijanju sertifikata, klijent proverava njegovu autentičnost. Ovo je izuzetno važan korak. Da bi veza bila sigurna, ne morate samo šifrirati podatke, već morate i osigurati da se šalju na ispravnu web stranicu. SSL/TLS certifikati pružaju ovu autentifikaciju, a način na koji to rade ovisi o korištenoj šifri.

Sve pouzdane SSL certifikate izdaje tijelo za izdavanje certifikata (CA). CA mora slijediti stroga pravila za izdavanje i provjeru valjanosti certifikata da bi mu se vjerovalo. Možete zamisliti CA kao nešto poput javnog bilježnika - njegov potpis znači da su podaci u certifikatu stvarni.

Tokom dijela provjere autentičnosti TLS rukovanja, klijent izvodi nekoliko kriptografski sigurnih provjera kako bi osigurao da je certifikat koji je izdao server originalan. Proces uključuje provjeru digitalni potpis i da li je certifikat izdao pouzdani CA.

U ovom koraku, klijent indirektno provjerava da li poslužitelj posjeduje privatni ključ povezan s certifikatom.

U RSA, najčešćem kriptosistemu javnog ključa, klijent koristi javni ključ za šifriranje nasumičnih podataka koji će se koristiti za generiranje ključa sesije. Server će moći dešifrirati i koristiti ove podatke samo ako ima privatni ključ, čije prisustvo osigurava autentičnost stranke.

Ako se koristi drugi kriptosistem, algoritam se može promijeniti, ali autentifikacija druge strane će i dalje ostati.

Razmjena ključeva

Posljednji dio TLS rukovanja uključuje kreiranje "ključa sesije" koji će se zapravo koristiti za sigurnu komunikaciju.

Ključevi sesije su "simetrični", što znači da se isti ključ koristi i za šifriranje i za dešifriranje.

Simetrična enkripcija je brža od asimetrične enkripcije, što je čini pogodnijom za slanje podataka preko HTTPS veze. Tačna metoda generiranja ključa ovisi o odabranom šifrantu, dvije najčešće su RSA i Diffie-Hellman.

Da bi završili rukovanje, svaka strana obavještava drugu da je završila sve neophodan rad, a zatim provjerava kontrolne sume kako bi se uvjerio da se rukovanje dogodilo bez ikakvih neovlaštenih manipulacija ili oštećenja.

Cijelo SSL rukovanje se događa za nekoliko stotina milisekundi. Ovo je prva stvar koja se dešava na HTTPS konekciji, čak i prije nego što se web stranica učita. Nakon SSL rukovanja, počinje šifrirana i autentificirana HTTPS veza, a svi podaci koje klijent i server šalju i primaju su zaštićeni.

Sve do TLS 1.3, svaki put kada ste posjetili stranicu, rukovanje se ponavljalo. TLS 1.3 rukovanje podržava 0-RTT ili nultu povratnu vožnju, što znatno poboljšava brzinu za posjetitelja koji se vraća.

Proces rukovanja korak po korak u TLS 1.2

Pogledajmo bliže TLS rukovanje koristeći RSA. Upotreba Diffie-Hellman algoritma će biti opisana u nastavku.

Prva poruka se zove "Client Hello". Ova poruka navodi klijentove opcije tako da server može izabrati šifru koju će koristiti za komunikaciju. Poruka također uključuje veliki nasumično odabran prost broj, nazvan "slučajni broj korisnika".
Server ljubazno odgovara porukom "Zdravo serveru". Tamo govori klijentu koje su opcije povezivanja odabrane i vraća njegov nasumično odabran prost broj, nazvan "slučajni broj servera". Ako klijent i server ne dijele pakete šifara, onda veza ne uspijeva.
U poruci "Certificate", server šalje svoj lanac SSL certifikata klijentu, koji uključuje listove i posredne certifikate. Nakon što ih primi, klijent vrši nekoliko provjera kako bi potvrdio certifikat. Klijent također mora osigurati da server ima privatni ključ sertifikat, koji se dešava tokom procesa razmene/generisanja ključeva.
Ovo je opciona poruka, potrebna samo za određene metode razmjene ključeva (kao što je Diffie-Hellman) koje zahtijevaju dodatne podatke sa servera.
Poruka "Server Hello Done" obavještava klijenta da je server završio sa slanjem podataka.
Klijent tada sudjeluje u generiranju ključa sesije. Specifičnosti ovog koraka zavise od načina razmjene ključeva koji je odabran u originalnim porukama "Zdravo". Pošto gledamo RSA, klijent će generisati nasumični niz bajtova koji se zove pre-master secret, šifrirati ga javnim ključem servera i poslati nazad.
Poruka "Promijeni specifikaciju šifre" daje drugoj strani do znanja da je ključ sesije generiran i da se može prebaciti na šifriranu vezu.
Zatim se šalje poruka "Završeno", što ukazuje da je rukovanje završeno na strani klijenta. Od tog trenutka, veza je zaštićena ključem sesije. Poruka sadrži podatke (MAC) koji se mogu koristiti za provjeru da rukovanje nije mijenjano.
Server sada dešifruje pre-master tajnu i izračunava ključ sesije. Zatim šalje poruku "Promijeni specifikaciju šifre" kako bi obavijestio da se prebacuje na šifriranu vezu.
Server također šalje poruku "Završeno" koristeći novogenerirani simetrični ključ sesije i provjerava kontrolnu sumu kako bi provjerio integritet cijelog rukovanja.

Nakon ovih koraka, SSL rukovanje je završeno. Obje strane sada imaju ključ sesije i mogu komunicirati preko šifrirane i autentificirane veze.

U ovom trenutku se mogu poslati prvi bajtovi web aplikacije (podaci koji se odnose na stvarnu uslugu - HTML, Javascript, itd.).

Proces rukovanja korak po korak u TLS 1.3

TLS 1.3 rukovanje je znatno kraće od svog prethodnika.

Kao i kod TLS 1.2, poruka "Client Hello" pokreće rukovanje, ali ovaj put sadrži mnogo više informacija. TLS 1.3 je smanjio broj podržanih šifara sa 37 na 5. To znači da klijent može da pogodi koji će se sporazum o ključu ili protokol razmene koristiti, pa pored poruke šalje i svoj deo javnog ključa iz pretpostavljenog protokola.
Server će odgovoriti porukom "Server Hello". Kao i kod rukovanja 1.2, certifikat se šalje u ovom trenutku. Ako je klijent ispravno pogodio protokol šifriranja sa priloženim podacima i server je pristao na to, potonji šalje svoj dio javnog ključa, izračunava ključ sesije i završava prijenos porukom "Server je završio".
Sada kada klijent ima sve potrebne informacije, on provjerava SSL certifikat i koristi dva javna ključa da izračuna svoju kopiju ključa sesije. Kada se završi, šalje se poruka "Klijent je završio".

TLS rukovanje iznad glave

Istorijski gledano, jedna od pritužbi na SSL/TLS bila je da je preopteretio servere dodatnim troškovima. Ovo je doprinijelo sada nefunkcionalnoj ideji da je HTTPS sporiji od HTTP-a.

Rukovanje prije TLS-a 1.2 zahtijevalo je puno resursa i u velikim razmjerima moglo je ozbiljno opteretiti server. Čak i TLS 1.2 rukovanja mogu usporiti stvari ako se mnogo njih dešava u isto vrijeme. Autentifikacija, šifriranje i dešifriranje su skupi procesi.

Na manjim web stranicama to vjerovatno neće značajno usporiti stvari, ali za korporativni sistemi, gde svakodnevno dolaze stotine hiljada posetilaca, to može biti veliki problem. Svaki nova verzija rukovanje čini proces mnogo lakšim: TLS 1.2 ima dvije faze, dok se TLS 1.3 uklapa u samo jednu i podržava 0-RTT.

TLS 1.3 poboljšanja rukovanja u odnosu na TLS 1.2

U gornjem objašnjenju, rukovanje je podijeljeno u deset zasebnih koraka. U stvarnosti, mnoge od ovih stvari se dešavaju istovremeno, pa se često grupišu i nazivaju fazama.

TLS 1.2 rukovanje ima dvije faze. Ponekad mogu biti potrebni dodatni, ali kada je u pitanju količina, zadana vrijednost je najbolji scenario.

Za razliku od 1.2, TLS 1.3 rukovanje se uklapa u jednu fazu, iako bi bilo preciznije reći jednu i po, ali je ipak mnogo brže od TLS 1.2.

Smanjenje paketa šifri

Niko nikada nije nameravao da koristi 37 skupova za šifrovanje podataka, tako je evoluirao protokol. Svaki put kada je dodan novi algoritam, dodane su nove kombinacije, a ubrzo je IANA administrirala 37 različitih paketa šifri.

Ovo je loše iz dva razloga:

Ova varijabilnost dovodi do pogrešnih konfiguracija koje ostavljaju korisnike Interneta ranjivim na poznate eksploatacije.
Ovo je učinilo postavku SSL-a još zbunjujućom.

IETF je uklonio podršku za sve algoritme osim najsigurnijih u TLS 1.3, uklanjajući zabunu ograničavanjem izbora. Posebno je uklonjen izbor metode razmjene ključeva. Efemerna Diffie-Hellman šema postala je jedini način da klijent pošalje svoje ključne informacije zajedno sa "Client Hello" u prvom dijelu rukovanja. RSA enkripcija je u potpunosti uklonjena zajedno sa svim ostalim šemama razmjene statičkih ključeva.

Imajući to u vidu, postoji jedna potencijalna Ahilova peta u TLS 1.3.

Nulto vrijeme retransmisije - 0-RTT

0-RTT je ono čemu cijeli svijet tehnologije teži, a evo ga sa TLS 1.3. Kao što je već spomenuto, TLS rukovanje je istorijski bilo sporo, pa je bilo važno ubrzati ga. 0-RTT to radi tako što pohranjuje neke tajne informacije o klijentu, obično ID sesije ili karte za sesiju, za upotrebu na sledećoj vezi.

Uprkos svim prednostima 0-RTT, on sadrži nekoliko potencijalnih zamki. Režim čini klijente podložnim napadima ponovne reprodukcije, pri čemu napadač koji na neki način uspe da dobije pristup šifrovanoj sesiji može dobiti 0-RTT podatke, uključujući i prvi zahtev klijenta, i poslati ih nazad serveru.

Međutim, eksploatacija nije jednostavna za korištenje. Vjerovatno je takav rizik mala cijena za izuzetno korisnu funkciju.

Sigurnost

Od samog početka, količina informacija poslanih u čistom tekstu tokom rukovanja bila je zabrinjavajuća. Ovo je očito nesigurno, pa što se više koraka rukovanja dogodi u šifriranom obliku, to bolje.

U TLS 1.2 rukovanju, koraci pregovaranja nisu bili sigurni, umjesto toga je korištena jednostavna MAC funkcija kako bi se spriječilo da bilo ko ometa prijenos. Faza pregovora uključuje poruke "Client Hello" i "Server Hello".

MAC funkcija djeluje kao indikator, ali ne daje nikakve sigurnosne garancije. Možda ste čuli za napad koji prisiljava strane da koriste manje sigurne protokole i funkcije (napad na nižu verziju). Ako i server i klijent podržavaju zastarjele pakete šifara - to se lako postiže slušanjem veze - napadač može promijeniti enkripciju koju odabere server u slabiju. Takvi napadi sami po sebi nisu opasni, ali otvaraju vrata drugim poznatim eksploatacijama onih paketa šifri u koje je prvobitno odabrana promijenjena.

TLS 1.3 rukovanje koristi digitalni potpis u ranim fazama veze, što ga čini sigurnijim i štiti od napada koji mijenjaju šifru. Potpis takođe omogućava bržu i efikasniju autentifikaciju servera.

Sada da vidimo kako će ova ažuriranja TLS 1.3 rukovanja biti implementirana u sve tri glavne karakteristike samog SSL/TLS rukovanja.

TLS paketi šifriranja rukovanja

Šifrarski paket je skup algoritama koji određuju parametre sigurne veze.

Na početku bilo koje veze, prva interakcija, "Client Hello", je lista podržanih paketa šifriranja. Server bira najbolju, najsigurniju opciju koju podržava i koja ispunjava njegove zahtjeve. Možete pogledati paket šifriranja i shvatiti sve parametre rukovanja i veze.

TLS 1.2 paketi šifri

TLS je protokol.
ECDHE je algoritam za razmjenu ključeva.
ECDSA je algoritam za autentifikaciju.
AES 128 GCM je simetrični algoritam šifriranja.
SHA256 je algoritam za heširanje.

Gornji primjer koristi Diffie-Hellman (DH) sistem efemerne eliptičke krive za razmjenu ključeva i algoritam digitalnog potpisa eliptičke krive za autentifikaciju. DH se također može povezati na RSA (koji funkcionira kao algoritam za digitalni potpis) radi provjere autentičnosti.

Evo liste najšire podržanih TLS 1.2 paketa šifri:

TLS 1.3 paketi šifri

TLS je protokol.
AES 256 GCM - Autentificirano šifriranje s priloženim podacima (AEAD).
SHA384 je algoritam funkcije generiranja heširanih ključeva (HKFD).

Već znamo da ćemo koristiti neku verziju efemerne Diffie-Hellmanove razmjene ključeva, ali ne znamo parametre, tako da prva dva algoritma u TLS 1.2 paketu šifri više nisu potrebna. Ove funkcije još uvijek rade, samo o njima više ne treba pregovarati tokom rukovanja.

Iz gornjeg primjera možete vidjeti da se AES (Advanced Encryption Standard) koristi za šifriranje velike količine podataka. Radi u načinu Galois brojača koristeći 256-bitne ključeve.

Evo pet paketa šifara koji su podržani u 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.

Šta se promijenilo u TLS 1.3 u odnosu na TLS 1.2?

Važno je zapamtiti da su prilikom kreiranja verzije 1.3, sigurnost i poboljšanja performansi bili glavni fokus. Da bi to uradio, TLS 1.3 je redizajnirao algoritam za generisanje ključeva i ispravio poznate ranjivosti.

TLS 1.3 rukovanje je također poboljšalo neke procese, kao što su autentikacija poruka i digitalni potpisi.

Konačno, pored postepenog ukidanja starih algoritama za generiranje ili razmjenu ključeva, TLS 1.3 eliminira stare simetrične šifre. TLS 1.3 je u potpunosti eliminisao blok šifre. Jedini tip simetrične šifre dozvoljen u TLS-u 1.3 zove se Auxiliary Authenticated Encryption (AEAD). Kombinira šifriranje i autentifikaciju poruke (MAC) u jednu funkciju.

Autentifikacija u TLS rukovanju

Istorijski gledano, dvije glavne ključne razmjene su RSA i Diffie-Hellman (DH), ovih dana DH se često povezuje sa eliptičnim krivuljama (ECDH). Uprkos nekim osnovnim sličnostima, postoje fundamentalne razlike između dva ključna pristupa razmjeni.

Drugim riječima, RSA TLS rukovanje se razlikuje od ECDH TLS rukovanja.

RSA koristi jednostavnu faktorizaciju i modularnu aritmetiku. Veliki prosti brojevi zahtijevaju mnogo CPU snage za računanje i teško ih je pokupiti.

Diffie-Hellman se ponekad naziva eksponencijalna razmjena ključeva, što ukazuje na eksponencijaciju (pored modularne aritmetike), ali sam DH zapravo ne šifrira ili dešifruje ništa. Dakle, nazivati ga "metodom šifriranja" umjesto "matematičkim opravdanjem" moglo bi biti malo pogrešno.

Kratka digresija u istoriju može razjasniti ovu stvar.

Već 1976. Whitfield Diffie i Martin Hellman kreirali su protokol za razmjenu ključeva zasnovan na radu Ralpha Merklea, čije bi se ime, prema obojici, također trebalo pojaviti u nazivu protokola.

Pokušali su riješiti problem sigurne razmjene ključeva preko nesigurnog kanala, čak i ako ga napadač prisluškuje. Uspjeli su, ali je postojao jedan ozbiljan nedostatak: razmjena DH ključeva nije uključivala autentifikaciju, tako da nije bilo moguće provjeriti stranu na drugom kraju veze.

Ovo se može smatrati rođenjem kriptografije javnog ključa i PKI-ja. Ubrzo nakon što su Diffie i Hellman predstavili svoj protokol za razmjenu ključeva, dovršene su najranije verzije RSA kriptosistema. Diffie i Hellman su stvorili koncept šifriranja javnog ključa, ali još nisu došli do stvarne funkcije jednosmjerne enkripcije.

Ron Rivest (R u RSA) je stvorio koncept koji je na kraju postao RSA kriptosistem.

Na mnogo načina, RSA je duhovni nasljednik DH. Obavlja:

generiranje ključeva;
razmjena ključeva;
enkripcija;
dešifrovanje.

Dakle, RSA je funkcionalniji algoritam koji može rukovati i razmjenom ključeva i digitalnim potpisima, tj. izvršiti autentifikaciju uz sigurnu razmjenu ključeva. Stoga RSA ima veće ključeve: mora se obezbijediti dovoljna sigurnost za digitalni potpis.

Dok RSA upravlja autentifikacijom i razmjenom ključeva, Diffie-Hellman samo olakšava razmjenu ključeva. Postoje četiri uobičajene varijante DH porodice:

Diffie-Hellman (DH);
efemerni (kratkoročni) Diffie-Hellman (DHE);
eliptička kriva Diffie-Hellman (ECDH);
eliptička krivulja efemerna Diffie-Hellman (ECDHE).

Opet, Diffie-Hellman sam po sebi ne potvrđuje ništa. Mora se koristiti zajedno sa algoritmom za digitalni potpis. Tako, na primjer, ako ste koristili ECDH ili ECDHE, većina paketa šifri će se upariti s algoritmom digitalnog potpisa eliptične krivulje (ECDSA) ili RSA.

TLS 1.2 provjera autentičnosti rukovanja

Kao što je upravo spomenuto, dodatna RSA funkcionalnost za autentifikaciju digitalnim potpisom zahtijeva velike ključeve koji su otporni na brute-force napade. Veličina ovih ključeva uvelike povećava troškove računanja, šifriranja i dešifriranja tijekom rukovanja.

S druge strane, ako Diffie-Hellman ne autentifikuje, šta onda radi? Kao što je gore spomenuto, DH se često koristi zajedno sa kriptografijom eliptičke krivulje kako bi se osigurala autentikacija i razmjena ključeva.

Eliptična kriptografija (ECC) ima mnogo manje veličine ključeva koji odgovaraju eliptičnoj krivulji na kojoj se zasnivaju. Postoji pet prikladnih krivulja za ovaj kontekst:

192 bita;
224 bita;
256 bita;
384 bita;
521 bita

Ali to nije jedina razlika između ECC javnih/privatnih ključeva i RSA ključeva. Koriste se u dvije potpuno različite svrhe tokom TLS rukovanja.

RSA koristi par javni/privatni ključ i za autentifikaciju servera i za simetričnu razmjenu ključeva sesije. U stvari, uspješna upotreba tajnog ključa za dešifriranje tajne (premaster secret) provjerava autentičnost servera.

Kod Diffie-Hellmana, par javni/privatni ključ NE koristi se za simetričnu razmjenu ključeva sesije. Kada je Diffie-Hellman uključen, privatni ključ je zapravo povezan s pratećim algoritmom potpisa (ECDSA ili RSA).

RSA autentikacija

RSA proces autentifikacije je povezan s procesom razmjene ključeva. Tačnije, razmjena ključeva je dio procesa autentifikacije.

Kada klijent dobije serverov SSL certifikat, on provjerava nekoliko metrika:

digitalni potpis pomoću javnog ključa;
lanac certifikata kako biste bili sigurni da certifikat dolazi iz jednog od korijenskih certifikata u skladištu povjerenja;
datum isteka kako biste bili sigurni da nije istekao;
status opoziva certifikata.

Ako sve ove provjere prođu, tada se izvodi posljednji test - klijent šifrira pre-master tajnu sa javnim ključem servera i šalje je. Svaki server može pokušati da prosledi bilo koji SSL/TLS certifikat kao svoj. Na kraju krajeva, ovo su javni certifikati. I tako klijent može autentifikovati server tako što će vidjeti privatni ključ "u akciji".

Stoga, ako server može dešifrirati pre-master tajnu i koristiti je za izračunavanje ključa sesije, odobrava mu se pristup. Ovo potvrđuje da je server vlasnik javnog/privatnog para ključeva koji se koristi.

DH autentifikacija

Kada se koriste Diffie-Hellman i ECDSA/RSA, autentifikacija i razmjena ključeva se postavljaju uporedo. I to nas vraća na ključeve i njihovu upotrebu. RSA javni/privatni ključ se koristi i za razmjenu ključeva i za autentifikaciju. U DH + ECDSA/RSA, asimetrični par ključeva se koristi samo za korak digitalnog potpisa ili provjere autentičnosti.

Kada klijent primi certifikat, on i dalje obavlja standardne provjere:

ovjerava potpis na certifikatu,
lanac sertifikata
valjanost,
status povratne informacije.

Ali posjedovanje privatnog ključa se provjerava drugačije. Tokom TLS razmjene ključeva rukovanja (korak 4), server koristi svoj privatni ključ da šifrira slučajni broj klijenta i servera, kao i svoj DH parametar. Djeluje kao digitalni potpis servera, a klijent može koristiti pridruženi javni ključ da potvrdi da je server zakoniti vlasnik para ključeva.

TLS 1.3 provjera autentičnosti rukovanja

U TLS-u 1.3 autentifikacija i digitalni potpisi i dalje igraju važnu ulogu, ali su uklonjeni iz paketa šifriranja kako bi se pojednostavilo pregovaranje. Implementirani su na strani servera i koriste nekoliko algoritama koje server podržava zbog njihove sigurnosti i sveprisutnosti. Postoje tri glavna algoritma potpisa dozvoljena u TLS 1.3:

RSA (samo potpis),
Algoritam digitalnog potpisa eliptične krivulje (ECDSA),
Edwardsov algoritam digitalnog potpisa (EdDSA).

Za razliku od TLS 1.2 rukovanja, dio provjere autentičnosti TLS 1.3 rukovanja nije povezan sa samom razmjenom ključeva. Umjesto toga, obrađuje se paralelno s razmjenom ključeva i autentifikacijom poruke.

Umjesto pokretanja simetričnog MAC-a za provjeru integriteta rukovanja, server potpisuje cijeli heš dešifriranja kada vrati "Server Hello" svojim dijelom javnog ključa.

Klijent prima sve informacije poslane sa "Server Hello" i obavlja standardnu seriju provjera autentičnosti SSL/TLS certifikata. To uključuje provjeru potpisa na certifikatu, a zatim provjeru da se potpis koji je dodan u heš dešifriranja podudara.

Podudaranje potvrđuje da server posjeduje privatni ključ.

Razmjena ključeva u TLS rukovanju

Ako istaknete glavnu ideju ovog odjeljka, to će zvučati ovako:

RSA olakšava razmjenu ključeva omogućavajući klijentu da šifrira zajedničku tajnu i pošalje je na server, gdje se koristi za izračunavanje odgovarajućeg ključa sesije. Razmjena DH ključeva zapravo uopće ne zahtijeva razmjenu javnog ključa, već obje strane kreiraju ključ zajedno.

Ako ovo sada zvuči pomalo apstraktno, do kraja ovog odjeljka sve bi trebalo postati jasno.

RSA razmjena ključeva

Nazivati to RSA razmjenom ključeva zapravo je pogrešan naziv. To je zapravo RSA enkripcija. RSA koristi asimetričnu enkripciju za generiranje ključa sesije. Za razliku od DH, par javni/privatni ključ igra veliku ulogu.

Evo kako to ide:

x I y
Klijent generiše predmajstorska tajna(a) a zatim koristi javni ključ servera da ga šifrira i pošalje serveru.
Server dešifruje predmajstorska tajna sa odgovarajućim privatnim ključem. Sada obje strane imaju sve tri ulazne varijable i miješaju ih s nekim pseudo-slučajnim funkcijama (PRF) kako bi stvorili glavni ključ.
Obje strane miješaju glavni ključ sa još više PRF-ova i završavaju s odgovarajućim ključevima sesije.

Razmjena DH ključeva

Evo kako ECDH radi:

Klijent i server razmjenjuju dva prosta broja ( x I y), koji se nazivaju slučajni brojevi.
Jedna strana bira tajni broj tzv predmajstorska tajna(a) i izračunava: x a mod y. Zatim šalje rezultat (A) drugom učesniku.
Druga strana čini isto, birajući svoje predmajstorska tajna(b) i izračunava x b mod y, a zatim šalje natrag svoju vrijednost (B).
Obje strane završavaju ovaj dio prihvatanjem datih vrijednosti i ponavljanjem operacije. Čovjek računa b a mod y, drugi računa a b mod y.

Postoji svojstvo modulo exponents koje kaže da će svaka strana dobiti istu vrijednost, koja će biti ključ koji se koristi za simetrično šifriranje tokom veze.

TLS 1.2 rukovanje za DH

Sada kada smo vidjeli kako se DH razlikuje od RSA, hajde da pogledamo kako izgleda rukovanje zasnovano na DH TLS 1.2.

Opet, postoji mnogo sličnosti između ova dva pristupa. Koristit ćemo ECDHE za razmjenu ključeva i ECDSA za autentifikaciju.

Kao i kod RSA, klijent počinje porukom "Client Hello", koja uključuje listu šifrovanih paketa, kao i slučajni broj klijenta.
Server odgovara svojom porukom "Server Hello", koja uključuje odabranu šifru i nasumični broj servera.
Server šalje svoj SSL certifikat. Kao i kod RSA TLS rukovanja, klijent će izvršiti niz provjera autentičnosti certifikata, ali pošto sam DH ne može autentifikovati server, potreban je dodatni mehanizam.
Za autentifikaciju, server uzima nasumične brojeve klijenta i servera, kao i DH parametar koji će se koristiti za izračunavanje ključa sesije, i šifrira ih svojim privatnim ključem. Rezultat će djelovati kao digitalni potpis: klijent koristi javni ključ za provjeru potpisa i da je server zakoniti vlasnik para ključeva, te će odgovoriti svojom vlastitom DH opcijom.
Server završava ovu fazu porukom "Server Hello Done".
Za razliku od RSA, klijent ne mora da šalje pre-master tajnu serveru koristeći asimetričnu enkripciju, umesto toga klijent i server koriste DH parametre koje su ranije razmenili da bi dobili pre-master tajnu. Svi tada koriste pre-master tajnu koju su upravo izračunali da bi dobili isti ključ sesije.
Klijent šalje poruku "Change Cipher Spec" kako bi obavijestio drugu stranu da je prešao na šifriranje.
Klijent šalje konačnu poruku "Završeno" kako bi označio da je završio svoj dio rukovanja.
Slično, server šalje poruku "Change Cipher Spec".
Rukovanje se završava porukom "Završeno" sa servera.

Prednosti DHE u odnosu na RSA

Dva su glavna razloga zašto kriptografska zajednica radije koristi DHE u odnosu na RSA: savršena tajnost naprijed i poznate ranjivosti.

Savršena tajnost naprijed

Ranije ste se možda pitali šta znači riječ "efemerno" na kraju DHE i ECDHE. Efemerno doslovno znači "kratkotrajan". I može pomoći u razumijevanju savršene prosljeđene tajnosti (PFS), koja je karakteristika nekih protokola za razmjenu ključeva. PFS osigurava da ključevi sesije koji se razmjenjuju između strana ne mogu biti kompromitovani, čak i ako je kompromitovan privatni ključ certifikata. Drugim riječima, štiti prethodne sesije od ekstrahiranja i dešifriranja. PFS je dobio najveći prioritet nakon otkrića Heartbleed buba. Ovo je osnovna komponenta TLS-a 1.3.

Ranjivost RSA razmjene ključeva

Postoje ranjivosti koje bi mogle iskoristiti padding ( padding) koji se koristi tokom razmjene ključeva u starijim verzijama RSA (PKCS #1 1.5). Ovo je jedan aspekt enkripcije. Kod RSA, pre-master tajna mora biti šifrirana javnim ključem i dešifrirana privatnim ključem. Ali kada se ova manja pre-master tajna uklopi u veći javni ključ, mora biti dopunjena. U većini slučajeva, ako pokušate pogoditi dopunu i poslati lažni zahtjev serveru, pogriješit ćete, a on će prepoznati neusklađenost i filtrirati je. Ali postoji velika šansa da možete poslati dovoljno zahtjeva serveru da pogodite ispravan padding. Server bi tada poslao pogrešno završenu poruku, koja bi zauzvrat suzila moguću vrijednost pre-master tajne. Ovo će omogućiti napadaču da izračuna i kompromituje ključ.

Zbog toga je RSA uklonjen u korist DHE u TLS 1.3.

Razmjena ključeva u TLS 1.3 rukovanju

U TLS 1.3 rukovanju, zbog ograničenog izbora šema za razmjenu ključeva, klijent može uspješno pogoditi šemu i poslati svoj dio zajedničkog ključa tokom početne faze (Client Hello) rukovanja.

RSA nije bila jedina šema za razmjenu ključeva koja je uklonjena u TLS 1.3. Takođe su eliminisane ne-efemerne Diffie-Hellman šeme, kao i lista nedovoljno sigurnih Diffie-Hellmanovih parametara.

Šta se podrazumijeva pod nedovoljno sigurnim parametrima? Bez da ulazimo u matematiku, složenost Diffie-Hellman-a i većine kriptosistema s javnim ključem je složenost rješavanja problema diskretnog logaritma. Kriptosistem mora biti dovoljno složen za izračunavanje ako su ulazni parametri (slučajni brojevi klijenta i servera) nepoznati, inače će cijela šema biti beskorisna. Diffie-Hellman šeme koje nisu mogle pružiti dovoljno velike parametre zastarjele su u TLS-u 1.3.

Na početku TLS 1.3 rukovanja, znajući da će se koristiti šema ugovora o DHE ključu, klijent uključuje svoj dio javnog ključa na osnovu namjeravane šeme razmjene ključeva u svoju poruku Client Hello.
Server prima ove informacije i, ako je klijent ispravan, vraća svoj dio javnog ključa u "Server Hello".
Klijent i server izračunavaju ključ sesije.

Ovo je vrlo slično onome što se dešava sa DH u TLS 1.2 rukovanju, osim što se razmjena ključeva događa ranije u TLS 1.3.

Umjesto zaključka

SSL/TLS rukovanje je uzbudljiv proces koji je ključan siguran internet a ipak se dešava tako brzo i tiho da većina ljudi o tome ni ne razmišlja.

Barem dok nešto ne krene po zlu.

Prema zahtjevima ruskog zakonodavstva, samo korištenje TLS veza uspostavljenih od strane Rusije kriptografski algoritmi GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 i GOST R 34.10-2001. Stoga, ako trebate koristiti stranice koje koriste šifriranje prema GOST algoritmima, morate instalirati program " CryptoPro CSP» .

U operacionim salama Windows sistemi koristi se CryptoPro CSP program - skup kriptografskih uslužnih programa za generiranje elektronski potpis, rad sa sertifikatima

Da biste instalirali CryptoPro CSP, koristite materijale sa službene web stranice:

Nakon instaliranja CryptoPro CSP Browser provjerava postojanje i rad ovog programa.

Web lokacije koje zahtijevaju GOST TLS enkripciju

Ako web lokacija zahtijeva GOST TLS enkripciju, pretraživač provjerava da li je CryptoPro CSP instaliran. Ako je program instaliran, kontrola se prenosi na njega.

Primeri sajtova koji zahtevaju šifrovanje: www.gosuslugi.ru, sajtovi na domenu .gov.ru, .kamgov.ru, .nalog.ru.

Ako sajt nije na listi, traži se dodatna potvrda. Ako vjerujete stranici i veza mora biti uspostavljena korištenjem GOST TLS enkripcije, kliknite na dugme Nastavi.

Sva naša razmišljanja zasnivaju se na činjenici da koristite Windows XP ili noviji (Vista, 7 ili 8), koji ima instalirane sve ispravne nadogradnje i zakrpe. Sada još jedan uslov: govorimo o najnovijim verzijama pretraživača danas, a ne o “sferičnom Ognelisu u vakuumu”.

Dakle, konfigurišemo pretraživače da koriste trenutne verzije TLS protokola i uopšte ne koriste njegove zastarele verzije i SSL. U svakom slučaju, koliko je to u teoriji moguće.

I teorija nam to ipak govori Internet Explorer pošto verzija 8 podržava TLS 1.1 i 1.2, pod Windows XP i Vista nećemo ga prisiljavati na to. Kliknite na: Alati / Internet opcije / Napredno i u odjeljku "Sigurnost" nalazimo: SSL 2.0, SSL 3.0, TLS 1.0 ... pronašli ste nešto drugo? Čestitamo, imat ćete TLS 1.1/1.2! Nije pronađeno - imate Windows XP ili Vista, au Redmondu se smatrate zaostalim.

Dakle, uklanjamo kvačice sa svih SSL-ova, stavljamo ih na sve dostupne TLS-ove. Ako je dostupan samo TLS 1.0, neka bude, ako ima ažuriranijih verzija, bolje je odabrati samo njih, a poništiti TLS 1.0 (i da se kasnije ne čudite što se neke stranice ne otvaraju preko HTTPS-a) . Zatim kliknite na dugme "Primeni", "U redu".

Sa Operom je lakše - ona nam priređuje pravi banket od različite verzije protokoli: Alati/Opšta podešavanja/Napredni/Sigurnosni/Sigurnosni protokoli. šta vidimo? Cijeli set iz kojeg ostavljamo potvrdne okvire samo za TLS 1.1 i TLS 1.2, nakon čega kliknemo na dugme "Detalji" i tamo poništavamo sve redove osim onih koji počinju sa "256 bit AES" - oni su na samom kraj. Na početku liste nalazi se red "256 bit AES ( Anonymous DH/SHA-256), poništite i njega. Kliknite "OK" i uživajte u sigurnosti.

Međutim, Opera ima jedno čudno svojstvo: ako je TLS 1.0 omogućen, onda ako je potrebno uspostaviti sigurnu vezu, odmah koristi ovu konkretnu verziju protokola, bez obzira na to podržava li stranica novije. Kao, zašto se naprezati - i sve je u redu, sve je zaštićeno. Kada omogućite samo TLS 1.1 i 1.2, prvo će pokušati da koristi napredniju verziju, a samo ako je ne podržava stranica, pretraživač će se prebaciti na verziju 1.1.

Ali sferični Ognelis Firefox nam se nimalo neće svidjeti: Alati / Postavke / Napredno / Šifriranje: sve što možemo učiniti je isključiti SSL, TLS je dostupan samo u verziji 1.0, nema šta raditi - ostavljamo ga sa kvačicom.

Međutim, loše se uči u poređenju: Chrome i Safari uopće ne sadrže postavke, koji protokol šifriranja koristiti. Koliko znamo, Safari ne podržava TLS verzije novije od 1.0 u verzijama pod Windowsom, a pošto je izdavanje novih verzija za ovaj OS prekinuto, neće.

Chrome, koliko znamo, podržava TLS 1.1, ali, kao iu slučaju Safarija, ne možemo odbiti korištenje SSL-a. Onemogućavanje TLS 1.0 u Chromeu također nije način. Ali sa stvarnom upotrebom TLS 1.1 - veliko pitanje: prvo je bio uključen, pa isključen zbog problema u radu, i, koliko se može zaključiti, još nije ponovo uključen. Odnosno, čini se da podrška postoji, ali je, takoreći, isključena i nema načina da je ponovo uključite samom korisniku. Ista priča sa Firefoxom - TLS 1.1 podrška u njemu, u stvari, jeste, ali još nije dostupna korisniku.

Sažetak iz gornjeg poliletera. Koja je opasnost od korištenja zastarjelih verzija protokola za šifriranje? Činjenica da će neko drugi ući u vašu sigurnu vezu sa sajtom i dobiti pristup svim informacijama "tamo" i "tamo". U praktičnom smislu, hoće pun pristup u kutiju Email, račun u sistemu klijent-banka itd.

Malo je vjerovatno da će biti moguće slučajno ući u tuđu sigurnu vezu, govorimo samo o zlonamjernim radnjama. Ako je vjerovatnoća takvih radnji mala ili informacije koje se prenose preko sigurne veze nemaju posebnu vrijednost, onda se ne možete truditi i koristiti pretraživače koji podržavaju samo TLS 1.0.

U suprotnom, nema izbora: samo Opera i samo TLS 1.2 (TLS 1.1 je samo poboljšanje TLS-a 1.0, djelimično naslijeđujući njegove sigurnosne probleme). Međutim, naše omiljene stranice možda ne podržavaju TLS 1.2 :(

TLS je nasljednik SSL-a, protokola koji pruža sigurno i sigurnu vezu između čvorova na Internetu. Koristi se u razvoju različitih klijenata, uključujući pretraživače i klijent-server aplikacije. Šta je TLS u Internet Exploreru?

Malo o tehnologiji

Koriste se sva preduzeća i organizacije koje se bave finansijskim transakcijama ovaj protokol kako bi se isključilo prisluškivanje paketa i neovlašteni pristup uljeza. Ova tehnologija je dizajnirana da zaštiti važne veze od zlonamjernih napada.

U osnovi, u svojoj organizaciji koriste ugrađeni pretraživač. U nekim slučajevima - Mozilla Firefox.

Omogućite ili onemogućite protokol

Nekim sajtovima se ponekad ne može pristupiti zbog činjenice da je podrška za SSL i TLS tehnologije onemogućena. U pretraživaču se pojavljuje obavijest. Dakle, kako omogućiti protokolima da nastave koristiti sigurnu komunikaciju?
1.Otvorite Control Panel preko Start. Drugi način: otvorite Explorer i kliknite na ikonu zupčanika u gornjem desnom uglu.

2. Idite na odjeljak "Internet Options" i otvorite blok "Advanced".

3. Označite kućice pored "Koristi TLS 1.1 i TLS 1.2".

4. Kliknite OK da sačuvate promjene. Ako želite da onemogućite protokole, što je veoma obeshrabreno, posebno ako koristite internet bankarstvo, poništite iste stavke.

Koja je razlika između 1.0 i 1.1 i 1.2? 1.1 je samo malo poboljšana verzija TLS 1.0, koja je djelimično naslijedila njegove nedostatke. 1.2 je najsigurnija verzija protokola. S druge strane, ne mogu se otvoriti sve stranice s omogućenom verzijom ovog protokola.

Kao što znate, Skype messenger je direktno povezan sa Internet Explorerom kao Windows komponentom. Ako nemate potvrđen TLS protokol u postavkama, može doći do problema sa Skypeom. Program jednostavno neće moći da se poveže sa serverom.

Ako je podrška za TLS onemogućena u postavkama Internet Explorera, sve funkcije programa povezane s mrežom neće raditi. Štoviše, sigurnost vaših podataka ovisi o ovoj tehnologiji. Nemojte to zanemariti ako to učinite finansijske operacije u ovom pretraživaču (kupovine u online prodavnicama, prenos novca putem Internet bankarstva ili elektronskog novčanika, itd.).