Asigurați-vă că protocoalele ssl și tls sunt activate. Protocolul TLS

În conformitate cu cerințele legislației ruse, este recunoscută doar utilizarea conexiunilor TLS stabilite conform algoritmilor criptografici ruși GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 și GOST R 34.10-2001. Prin urmare, dacă trebuie să utilizați site-uri care utilizează criptarea conform algoritmilor GOST, trebuie să instalați programul CryptoPro CSP.

Sistemele de operare Windows folosesc programul CryptoPro CSP - un set de utilitare criptografice pentru generarea semnăturilor electronice și lucrul cu certificate

Pentru a instala CryptoPro CSP, utilizați materialele de pe site-ul oficial:

Distribuție CSP CryptoPro
Un pachet de instrucțiuni pentru instalarea și utilizarea CryptoPro CSP

După instalarea CryptoPro CSP, browserul verifică prezența și funcționalitatea acestui program.

Site-uri care solicită criptarea GOST TLS

Dacă un site solicită criptarea GOST TLS, browserul verifică dacă programul CryptoPro CSP este instalat. Dacă programul este instalat, controlul este transferat acestuia.

Exemple de site-uri care solicită criptare: www.gosuslugi.ru, site-uri de pe domeniul .gov.ru, .kamgov.ru, .nalog.ru.

Dacă site-ul nu este pe listă, se solicită confirmare suplimentară. Dacă aveți încredere în site și conexiunea trebuie făcută folosind criptarea GOST TLS, faceți clic pe butonul Continuare.

Notă. Site-urile pot necesita instalarea de certificate. Instrucțiunile de instalare a certificatelor se află de obicei pe site-urile care le solicită.

Activarea și dezactivarea suportului pentru browser CryptoPro CSP

În mod implicit, browserul acceptă CryptoPro CSP. Vă recomandăm să verificați acest lucru.

Capitole ale cărții minunate „Rețea de browser de înaltă performanță” de Ilya Grigorik. Traducerea a fost realizată ca parte a scrierii unei lucrări de curs, prin urmare este foarte gratuită, dar cu toate acestea va fi utilă celor care nu au nicio idee ce este TLS și pentru ce este folosit.

Înțelegerea TLS

Protocolul TLS (transport layer security) se bazează pe protocolul SSL (Secure Sockets Layer), dezvoltat inițial de Netscape pentru a îmbunătăți securitatea comerțului electronic online. Protocolul SSL a fost implementat la nivelul aplicației, direct deasupra TCP (Transmission Control Protocol), ceea ce permite protocoalelor de nivel superior (cum ar fi HTTP sau protocolul de e-mail) să funcționeze fără modificări. Dacă SSL este configurat corect, un observator extern poate cunoaște doar parametrii conexiunii (de exemplu, tipul de criptare utilizat), precum și frecvența transferurilor și cantitatea aproximativă de date, dar nu le poate citi sau modifica.

Locul specific al TLS (SSL) în stiva de protocoale Internet este prezentat în diagramă:

După ce protocolul SSL a fost standardizat de către IETF (Internet Engineering Task Force), a fost redenumit TLS. Prin urmare, deși denumirile SSL și TLS sunt folosite interschimbabil, ele sunt totuși diferite, deoarece fiecare descrie o versiune diferită a protocolului.

Prima versiune a protocolului lansat s-a numit SSL 2.0, dar a fost rapid înlocuită cu SSL 3.0 din cauza vulnerabilităților descoperite. După cum am menționat, SSL a fost dezvoltat de Netscape, așa că în ianuarie 1999 IETF l-a standardizat în mod deschis sub numele TLS 1.0. Apoi, în aprilie 2006, a fost publicat TLS 1.1, care a extins capacitățile originale ale protocolului și a închis vulnerabilitățile cunoscute. Versiunea actuală a protocolului în acest moment este TLS 1.2, lansat în august 2008.

După cum am menționat, TLS a fost conceput pentru a funcționa peste TCP, dar pentru a funcționa cu protocoale de datagramă precum UDP (User Datagram Protocol), a fost dezvoltată o versiune specială a TLS numită DTLS (Datagram Transport Layer Security).

Criptare, autentificare și integritate

Protocolul TLS este conceput pentru a oferi trei servicii tuturor aplicațiilor care rulează pe el, și anume criptare, autentificare și integritate. Din punct de vedere tehnic, nu toate trei pot fi folosite, dar în practică, pentru a asigura securitatea, toate trei sunt de obicei folosite:

Criptare – ascunderea informațiilor transferate de la un computer la altul;
Autentificare – verificarea dreptului de autor al informațiilor transmise;
Integritate – detectarea înlocuirii informațiilor cu informații contrafăcute.

Pentru a stabili un canal de date criptografic sigur, nodurile de conectare trebuie să convină asupra metodelor de criptare și a cheilor care vor fi utilizate. Protocolul TLS definește clar această procedură; acest lucru este discutat mai detaliat în paragraful TLS Handshake. Trebuie remarcat faptul că TLS utilizează criptografia cu cheie publică, care permite nodurilor să stabilească o cheie de criptare secretă partajată fără cunoștințe prealabile unul despre celălalt.

De asemenea, ca parte a procedurii TLS Handshake, este posibilă autentificarea identității atât a clientului, cât și a serverului. De exemplu, un client poate fi sigur că serverul care îi furnizează informații despre contul bancar este într-adevăr un server bancar. Și invers: serverul companiei poate fi sigur că clientul care se conectează la acesta este un angajat al companiei, și nu o terță parte (acest mecanism se numește Chain of Trust și va fi discutat în secțiunea corespunzătoare).

În cele din urmă, TLS asigură că fiecare mesaj este trimis cu un cod MAC (Message Authentication Code), al cărui algoritm de creare este o funcție de hashing criptografic unidirecțional (de fapt o sumă de control), ale cărei chei sunt cunoscute de ambii participanți la comunicare. . De fiecare dată când este trimis un mesaj, este generată valoarea MAC a acestuia, care poate fi generată și de către receptor, aceasta asigură integritatea informațiilor și protecția împotriva înlocuirii acesteia.

Astfel, toate cele trei mecanisme care stau la baza criptosecurității protocolului TLS sunt revizuite pe scurt.

Strângere de mână TLS

Înainte de a începe schimbul de date prin TLS, clientul și serverul trebuie să convină asupra parametrilor de conectare, și anume: versiunea protocolului utilizat, metoda de criptare a datelor și, de asemenea, să verifice certificatele, dacă este necesar. Schema de inițiere a conexiunii se numește TLS Handshake și este prezentată în figură:

Să aruncăm o privire mai atentă la fiecare pas al acestei proceduri:

Deoarece TLS funcționează peste TCP, o conexiune TCP este stabilită mai întâi între client și server.
După instalarea TCP, clientul trimite specificația în text simplu (și anume, versiunea de protocol pe care dorește să o folosească, metodele de criptare acceptate etc.) către server.
Serverul aprobă versiunea protocolului utilizat, selectează o metodă de criptare din lista furnizată, îi atașează certificatul și trimite un răspuns clientului (dacă se dorește, serverul poate solicita și un certificat de client).
Versiunea protocolului și metoda de criptare sunt considerate aprobate în acest moment, clientul verifică certificatul trimis și inițiază fie schimbul de chei RSA, fie Diffie-Hellman, în funcție de parametrii setați.
Serverul procesează mesajul trimis de client, verifică MAC-ul și trimite mesajul final („Terminat”) clientului în formă criptată.
Clientul decriptează mesajul primit, verifică MAC-ul și, dacă totul este bine, conexiunea este considerată stabilită și începe schimbul de date aplicației.

Este clar că stabilirea unei conexiuni TLS este, în general, un proces consumator de timp și de muncă, așa că există mai multe optimizări în standardul TLS. În special, există o procedură numită „strângere de mână abreviată”, care vă permite să utilizați parametrii conveniți anterior pentru a restabili conexiunea (desigur, dacă clientul și serverul au stabilit o conexiune TLS în trecut). Această procedură este discutată mai detaliat în secțiunea „Reluarea unei sesiuni”.

Există, de asemenea, o extensie suplimentară la procedura Handshake numită TLS False Start. Această extensie permite clientului și serverului să înceapă schimbul de date criptate de îndată ce metoda de criptare este stabilită, reducând stabilirea conexiunii cu o iterație a mesajului. Acest lucru este discutat mai detaliat în paragraful „TLS False Start”.

Schimb de chei în protocolul TLS

Din diverse motive istorice și comerciale, cel mai des folosit schimb de chei în TLS este RSA: clientul generează o cheie simetrică, o semnează cu cheia publică a serverului și o trimite către server. La rândul său, pe server, cheia clientului este decriptată folosind cheia privată. După aceasta, schimbul de chei este declarat încheiat. Acest algoritm are un dezavantaj: aceeași pereche de chei publice și private este folosită și pentru autentificarea serverului. În consecință, dacă un atacator obține acces la cheia privată a serverului, el poate decripta întreaga sesiune de comunicare. Mai mult, un atacator poate pur și simplu să înregistreze întreaga sesiune de comunicare într-o versiune criptată și să o decripteze ulterior, când reușește să obțină cheia privată a serverului. În același timp, schimbul de chei Diffie-Hellman pare a fi mai sigur, deoarece cheia simetrică stabilită nu părăsește niciodată clientul sau serverul și, în consecință, nu poate fi interceptată de un atacator, chiar dacă acesta cunoaște cheia privată a serverului. Serviciul de reducere a riscului de a compromite sesiunile de comunicare anterioare se bazează pe acesta: pentru fiecare nouă sesiune de comunicare, este creată o nouă cheie simetrică, așa-numita „temporară”. În consecință, chiar și în cel mai rău caz (dacă atacatorul cunoaște cheia privată a serverului), atacatorul poate obține chei doar din sesiunile viitoare, dar nu poate decripta cele înregistrate anterior.

În prezent, la stabilirea unei conexiuni TLS, toate browserele preferă o combinație a algoritmului Diffie-Hellman și utilizarea cheilor temporare pentru a crește securitatea conexiunii.

Trebuie remarcat din nou că criptarea cheii publice este utilizată numai în procedura TLS Handshake în timpul configurării inițiale a conexiunii. După configurarea tunelului, intră în joc criptografia simetrică, iar comunicarea în cadrul sesiunii curente este criptată cu cheile simetrice stabilite. Acest lucru este necesar pentru a crește performanța, deoarece criptografia cu cheie publică necesită mult mai multă putere de calcul.

Reluarea unei sesiuni TLS

După cum sa menționat mai devreme, procedura completă TLS Handshake este destul de lungă și costisitoare din punct de vedere al calculului. Prin urmare, a fost dezvoltată o procedură care permite reluarea unei conexiuni întrerupte anterior pe baza datelor deja configurate.

De la prima versiune publică a protocolului (SSL 2.0), un server poate genera și trimite un identificator de sesiune de 32 de octeți ca parte a unui TLS Handshake (și anume mesajul inițial ServerHello). Desigur, în acest caz, serverul stochează un cache de identificatori generați și parametri de sesiune pentru fiecare client. La rândul său, clientul stochează identificatorul trimis și îl include (desigur, dacă există) în mesajul inițial ClientHello. Dacă atât clientul, cât și serverul au identificatori de sesiune identici, atunci stabilirea unei conexiuni comune are loc conform algoritmului simplificat prezentat în figură. Dacă nu, atunci este necesară versiunea completă a TLS Handshake.

Procedura de reluare a sesiunii vă permite să săriți peste etapa de generare a unei chei simetrice, ceea ce crește semnificativ timpul de configurare a conexiunii, dar nu afectează securitatea acesteia, deoarece sunt utilizate date necompromise anterior din sesiunea anterioară.

Cu toate acestea, există o limitare practică: deoarece serverul trebuie să stocheze date despre toate sesiunile deschise, aceasta duce la o problemă cu resursele populare care sunt solicitate simultan de mii sau milioane de clienți.

Pentru a evita această problemă, a fost dezvoltat mecanismul „Ticket de sesiune”, care elimină nevoia de a stoca datele fiecărui client pe server. Dacă clientul a indicat în timpul conexiunii inițiale că acceptă această tehnologie, atunci în timpul TLS Handshake clientul trimite așa-numitul Ticket de sesiune - parametrii de sesiune criptați cu cheia privată a serverului - către server. Data viitoare când se reia sesiunea, clientul trimite Tichetul de sesiune existent împreună cu ClientHello. Acest lucru elimină necesitatea ca serverul să stocheze date despre fiecare conexiune, dar conexiunea este în continuare sigură, deoarece Biletul de sesiune este criptat cu o cheie cunoscută doar de server.

TLS fals start

Tehnologia de reluare a sesiunii îmbunătățește fără îndoială performanța protocolului și reduce costurile de calcul, dar nu este aplicabilă în conexiunea inițială la server sau în cazul în care sesiunea anterioară a expirat deja.

Pentru a obține performanțe și mai mari, a fost dezvoltată tehnologia TLS False Start, care este o extensie opțională a protocolului și permite trimiterea datelor atunci când TLS Handshake este doar parțial finalizat. Schema detaliată TLS False Start este prezentată în figură:

Este important de reținut că TLS False Start nu modifică în niciun fel procedura TLS Handshake. Se bazează pe presupunerea că în momentul în care clientul și serverul știu deja despre parametrii de conectare și cheile simetrice, datele aplicației pot fi deja trimise și toate verificările necesare pot fi efectuate în paralel. Ca rezultat, conexiunea este gata de utilizare cu o iterație a mesajelor mai devreme.

Lanțul de încredere TLS

Autentificarea este o parte integrantă a fiecărei conexiuni TLS. Să ne uităm la cel mai simplu proces de autentificare dintre Alice și Bob:

Atât Alice, cât și Bob își generează propriile chei publice și private.
Alice și Bob fac schimb de chei publice.
Alice generează un mesaj, îl criptează cu cheia ei privată și îl trimite lui Bob.
Bob folosește cheia primită de la Alice pentru a decripta mesajul și astfel verifică autenticitatea mesajului primit.

Evident, această schemă este construită pe încrederea dintre Alice și Bob. Se presupune că schimbul de chei publice a avut loc, de exemplu, într-o întâlnire personală, și astfel Alice este încrezătoare că a primit cheia direct de la Bob, iar Bob, la rândul său, este încrezător că a primit cheia publică a lui Alice.

Lasă-l pe Alice să primească acum un mesaj de la Charlie, pe care nu-l cunoaște, dar care pretinde că este prieten cu Bob. Pentru a dovedi acest lucru, Charlie a cerut în prealabil să semneze propria sa cheie publică cu cheia privată a lui Bob și atașează această semnătură mesajului către Alice. Alice verifică mai întâi semnătura lui Bob pe cheia lui Charlie (ea este capabilă să facă acest lucru, deoarece știe deja cheia publică a lui Bob), se asigură că Charlie este cu adevărat prietenul lui Bob, acceptă mesajul lui și efectuează verificarea de integritate deja cunoscută, asigurându-se că mesajul chiar este de la Charlie:

Ceea ce este descris în paragraful anterior este crearea unui „lanț de încredere” (sau „lanț de încredere”, în limba engleză).
În protocolul TLS, aceste lanțuri de încredere se bazează pe certificate de autenticitate furnizate de autorități speciale numite autorități de certificare (CA). Autoritățile de certificare efectuează verificări și, dacă certificatul emis este compromis, certificatul este revocat.

Lanțul de încredere deja discutat este format din certificatele eliberate. Rădăcina sa este așa-numitul „certificat CA rădăcină” - un certificat semnat de un centru mare, a cărui credibilitate este incontestabilă. În general, lanțul de încredere arată cam așa:

Desigur, apar cazuri când un certificat deja emis trebuie să fie revocat sau revocat (de exemplu, cheia privată a unui certificat a fost compromisă sau întreaga procedură de certificare a fost compromisă). Pentru a realiza acest lucru, certificatele de autenticitate conțin instrucțiuni speciale pentru a se asigura că sunt actualizate. Prin urmare, atunci când se construiește un lanț de încredere, este necesar să se verifice relevanța fiecărui nod de încredere.

Mecanismul acestei verificări este simplu și se bazează pe așa-numitul. „Lista de revocare a certificatelor” (CRL – „Lista de revocare a certificatelor”). Fiecare dintre autoritățile de certificare menține această listă, care este o simplă listă de numere de serie ale certificatelor revocate. În consecință, oricine dorește să verifice autenticitatea unui certificat pur și simplu descarcă această listă și caută în ea numărul certificatului care este verificat. Dacă numărul este găsit, înseamnă că certificatul a fost revocat.

Există, evident, o ineficiență tehnică aici: pentru a verifica un singur certificat, trebuie să solicitați întreaga listă de certificate de revocare, ceea ce încetinește activitatea. Pentru a combate acest lucru, a fost dezvoltat un mecanism numit Online Certificate Status Protocol (OCSP). Vă permite să verificați starea certificatului în mod dinamic. Desigur, acest lucru reduce sarcina pe lățimea de bandă a rețelei, dar în același timp creează mai multe probleme:

CA trebuie să gestioneze sarcina în timp real;
CA trebuie să garanteze disponibilitatea lor în orice moment;
Datorită interogărilor în timp real, autoritățile de certificare primesc informații despre site-urile pe care le-a vizitat fiecare utilizator.

De fapt, în toate browserele moderne, ambele soluții (OCSP și CRL) se completează reciproc, în plus, de regulă, este posibilă configurarea politicii preferate pentru verificarea stării certificatului.

Astfel, acest articol discută toate caracteristicile cheie oferite de protocolul TLS pentru protejarea informațiilor. Îmi cer scuze pentru unele gaguri din articol; acestea sunt costurile scopului original al traducerii.

Protocoalele de rețea SSL și TLS sunt protocoale criptografice care oferă autentificare și protecție împotriva accesului neautorizat și a încălcării integrității datelor transmise. Protocoalele SSL/TLS sunt concepute pentru a preveni falsificarea identificatorului pe partea client sau server, dezvăluirea sau coruperea datelor. În aceste scopuri, se utilizează o metodă de autentificare fiabilă, se utilizează criptarea canalului de comunicație și codurile de integritate a mesajelor. Portul standard implicit pentru SSL/TLS este 443 pentru HTTPS, 465 pentru SMTPS (e-mail), 636 pentru LDAPS, 563 pentru NNTPS, 994 pentru IRCS (chat), 995 pentru POP3S.

Protocolul SSL

Protocolul SSL a fost dezvoltat de Netscape pentru a proteja datele dintre protocoalele de serviciu și de transport. Prima versiune publică a fost lansată în 1995. Folosit pe scară largă pentru aplicații VoIP, servicii de mesagerie instantanee. SSL este un canal securizat care are următoarele proprietăți:

Canal privat. Se asigură că toate mesajele sunt criptate după dialogul necesar pentru a determina cheia de criptare.
Canalul este autentificat. Autentificarea este opțională pentru partea client, dar obligatorie pentru partea server.
Fiabilitatea canalului. Când mesajele sunt transportate, verificările de integritate sunt efectuate utilizând MAC.

Protocolul SSL utilizează atât chei simetrice, cât și chei asimetrice.

Caracteristicile și scopul protocolului SSL

Protocolul SSL oferă o soluție la două probleme - criptarea informațiilor transmise și transferul informațiilor exact acolo unde este necesar (autentificare). Scopul principal al protocolului este de a oferi o modalitate fiabilă de schimb de date între aplicații. Implementarea SSL se face sub forma unui mediu multi-strat, care este folosit pentru transmiterea securizata a informatiilor prin canale de comunicatie nesecurizate.

Structura multistrat este reprezentată de un strat de protocol de confirmare a conexiunii și un strat de protocol de înregistrare. Primul strat este un protocol de transport, de exemplu, TCP - împreună cu protocolul de înregistrare SSL, aceste straturi formează nucleul SSL, care participă ulterior la formarea infrastructurilor complexe.

Printre principalele caracteristici ale protocolului SSL, trebuie remarcată independența software-platformă. În prezent, protocolul SSL nu oferă securitate adecvată - a fost înlocuit cu protocolul TLS.

Protocolul TLS

Protocolul TLS este un protocol criptografic care este utilizat pentru transferul securizat de date între diferite noduri de pe Internet. Acest protocol este utilizat în aplicațiile VoIP, browserele web și aplicațiile de mesagerie instantanee. TLS este implementat pe baza specificației SSL 3.0. Protocolul este dezvoltat și dezvoltat de IETF.

Principalele măsuri de securitate oferite de protocolul TLS includ:

Folosind o cheie pentru a verifica codul de autentificare a mesajului.
Este eliminată posibilitatea de a downgrade versiunea TLS sau de a o înlocui cu un protocol de rețea mai puțin sigur.
Mesajul de strângere de mână conține un hash al tuturor mesajelor schimbate între părți.
Utilizarea numerotării înregistrărilor aplicației folosind MAC.
Utilizarea unei funcții pseudo-aleatoare care împarte mesajele de intrare în 2 părți, fiecare dintre acestea fiind procesată de o funcție hash diferită.

Caracteristicile și scopul protocolului TLS

Protocolul TLS utilizează următorii algoritmi:

RC4, Triple DES, SEED, IDEA etc. pentru criptare simetrică.
RSA, DSA, Diffie-Hellman și ECDSA pentru autentificarea cheii.
MD5, SHA și SHA-256/384 pentru funcții hash.

Aplicațiile fac schimb de înregistrări care stochează date. Înregistrările pot fi comprimate, mărite, criptate sau identificate. În acest caz, fiecare intrare indică lungimea pachetului și versiunea TLS utilizată.

În general, utilizarea criptografiei în protocoalele SSL/TLS reduce semnificativ performanța aplicației, dar oferă securitate fiabilă a transmiterii datelor. Protocoalele nu necesită practic setări din partea clientului și sunt considerate cele mai comune protocoale de securitate de pe Internet.

Toate argumentele noastre se bazează pe faptul că sistemul de operare este Windows XP sau mai recent (Vista, 7 sau 8), pe care sunt instalate toate actualizările și patch-urile corespunzătoare. Acum mai există o condiție: vorbim despre cele mai recente versiuni de browsere și nu despre „Ognelis sferic în vid”.

Așadar, configurăm browserele să utilizeze cele mai recente versiuni ale protocolului TLS și să nu utilizeze deloc versiunile sale învechite și SSL. Cel puțin, pe cât posibil în teorie.

Și teoria ne spune că, deși Internet Explorer acceptă TLS 1.1 și 1.2 deja din versiunea 8, sub Windows XP și Vista nu îl vom forța să facă acest lucru. Faceți clic pe: Tools/Internet Options/Advanced iar în secțiunea „Security” găsim: SSL 2.0, SSL 3.0, TLS 1.0... ați găsit altceva? Felicitări, veți avea TLS 1.1/1.2! Dacă nu l-au găsit, ai Windows XP sau Vista, iar în Redmond te consideră retardat.

Deci, debifați toate casetele SSL, bifați toate casetele TLS disponibile. Dacă este disponibil doar TLS 1.0, atunci așa să fie; dacă sunt disponibile mai multe versiuni actuale, este mai bine să le selectați doar pe acestea și să debifați TLS 1.0 (și să nu fiți surprins mai târziu că unele site-uri nu se deschid prin HTTPS). Apoi faceți clic pe butoanele „Aplicați” și „OK”.

Este mai ușor cu Opera - ne oferă un banchet real cu diferite versiuni de protocol: Instrumente/Setări generale/Avansat/Securitate/Protocol de securitate. Ce vedem? Întregul set, din care lăsăm casetele de selectare doar pentru TLS 1.1 și TLS 1.2, după care facem clic pe butonul „Detalii” și acolo debifăm toate liniile cu excepția celor care încep cu „256 biți AES” - sunt chiar la început. Sfârşit. La începutul listei există o linie „AES pe 256 de biți ( Anonim DH/SHA-256), debifați și el. Faceți clic pe „OK” și bucurați-vă de securitate.

Cu toate acestea, Opera are o proprietate ciudată: dacă TLS 1.0 este activat, atunci dacă este necesar să se stabilească o conexiune sigură, folosește imediat această versiune a protocolului, indiferent dacă site-ul acceptă altele mai actuale. De exemplu, de ce să te deranjezi – totul este bine, totul este protejat. Când sunt activate doar TLS 1.1 și 1.2, se va încerca mai întâi versiunea mai avansată și numai dacă nu este acceptată de site browserul va trece la versiunea 1.1.

Dar Ognelis Firefox sferic nu ne va multumi deloc: Tools/Settings/Advanced/Encryption: tot ce putem face este sa dezactivam SSL, TLS este disponibil doar in versiunea 1.0, nu este nimic de facut - il lasam cu bifa.

Totuși, cel mai rău se învață prin comparație: Chrome și Safari nu conțin setări deloc pentru protocolul de criptare care să fie utilizat. Din câte știm, Safari nu acceptă versiuni TLS mai actuale decât 1.0 în versiunile pentru sistemul de operare Windows și, deoarece lansarea de noi versiuni pentru acest sistem de operare a fost întreruptă, nu va mai fi.

Chrome, din câte știm, acceptă TLS 1.1, dar, ca și în cazul Safari, nu putem refuza utilizarea SSL. Nu există nicio modalitate de a dezactiva TLS 1.0 în Chrome. Dar, odată cu utilizarea efectivă a TLS 1.1, există o mare întrebare: a fost mai întâi pornit, apoi oprit din cauza unor probleme operaționale și, din câte se poate aprecia, nu a fost încă repornit. Adică, pare să existe suport, dar pare să fie dezactivat și nu există nicio modalitate ca utilizatorul să-l pornească din nou. Aceeași poveste este și cu Firefox - de fapt are suport pentru TLS 1.1, dar nu este încă disponibil pentru utilizator.

Rezumat din multilitera de mai sus. Care sunt pericolele generale ale utilizării versiunilor învechite ale protocoalelor de criptare? Faptul că altcineva va intra în conexiunea dumneavoastră securizată la site și va avea acces la toate informațiile „acolo” și „acolo”. În termeni practici, el va avea acces deplin la căsuța sa de e-mail, contul din sistemul client-bancă etc.

Este puțin probabil că veți pătrunde accidental în conexiunea sigură a altcuiva; vorbim doar despre acțiuni rău intenționate. Dacă probabilitatea unor astfel de acțiuni este scăzută sau informațiile transmise printr-o conexiune securizată nu sunt deosebit de valoroase, atunci nu trebuie să vă deranjați și să utilizați browsere care acceptă doar TLS 1.0.

Altfel, nu ai de ales: doar Opera și doar TLS 1.2 (TLS 1.1 este doar o îmbunătățire față de TLS 1.0, moștenind parțial problemele de securitate). Cu toate acestea, este posibil ca site-urile noastre preferate să nu accepte TLS 1.2 :(

TLS și SSL au fost menționate din ce în ce mai recent, utilizarea certificatelor digitale a devenit mai relevantă și au apărut chiar și companii care sunt gata să ofere certificate digitale gratuite tuturor pentru a se asigura că traficul dintre site-urile vizitate și browserul clientului este criptat. Desigur, acest lucru este necesar pentru securitate, astfel încât nimeni din rețea să nu poată primi datele care sunt transmise de la client la server și înapoi. Cum funcționează toate acestea și cum să le folosești? Pentru a înțelege acest lucru, trebuie, probabil, să începem cu teorie și apoi să o arătăm în practică. Deci, SSL și TLS.

Ce este SSL și ce este TLS?

SSL - Secure Socket Layer, un strat de prize securizate. TLS - Transport Layer Security, securitate la nivel de transport. SSL este un sistem anterior, TLS a venit mai târziu și se bazează pe specificația SSL 3.0 dezvoltată de Netscape Communications. Cu toate acestea, aceste protocoale au o singură sarcină - să asigure transferul securizat de date între două computere de pe Internet. Acest transfer este folosit pentru diverse site-uri web, pentru e-mail, pentru mesagerie și multe altele. În principiu, puteți transmite orice informație în acest mod; mai multe despre asta mai jos.

Transmiterea securizată este asigurată prin autentificarea și criptarea informațiilor transmise. În esență, aceste protocoale, TLS și SSL, funcționează la fel; nu există diferențe fundamentale. Se poate spune că TLS este succesorul SSL-ului, deși pot fi folosite simultan, chiar și pe același server. Un astfel de suport este necesar pentru a asigura funcționarea atât cu clienții noi (dispozitive și browsere), cât și cu cei vechi care nu acceptă TLS. Secvența de apariție a acestor protocoale arată astfel:

SSL 1.0 - niciodată publicat
SSL 2.0 - februarie 1995
SSL 3.0 - 1996
TLS 1.0 - ianuarie 1999
TLS 1.1 - aprilie 2006
TLS 1.2 - august 2008

Cum funcționează SSL și TLS

Principiul de funcționare a SSL și TLS, așa cum am spus, este același. Un canal criptat este stabilit peste protocolul TCP/IP, în cadrul căruia datele sunt transferate prin protocolul de aplicație - HTTP, FTP și așa mai departe. Iată cum poate fi reprezentat grafic:

Protocolul de aplicație este „împachetat” în TLS/SSL, care, la rândul său, este împachetat în TCP/IP. În esență, datele protocolului de aplicație sunt transmise prin TCP/IP, dar sunt criptate. Și numai mașina care a stabilit conexiunea poate decripta datele transmise. Pentru toți ceilalți care primesc pachetele transmise, aceste informații vor fi lipsite de sens dacă nu le pot decripta.

Conexiunea se stabilește în mai multe etape:

1) Clientul stabilește o conexiune la server și solicită o conexiune securizată. Acest lucru poate fi realizat fie prin stabilirea unei conexiuni la un port care inițial este destinat să funcționeze cu SSL/TLS, de exemplu, 443, fie prin solicitarea suplimentară a clientului să stabilească o conexiune securizată după stabilirea uneia obișnuite.

2) Când stabilește o conexiune, clientul oferă o listă de algoritmi de criptare pe care îi „știe”. Serverul verifică lista primită cu lista de algoritmi pe care serverul însuși îi „știe” și selectează cel mai de încredere algoritm, după care îi spune clientului ce algoritm să folosească

3) Serverul trimite clientului certificatul său digital, semnat de autoritatea de certificare, și cheia publică a serverului.

4) Clientul poate contacta serverul autorității de certificare de încredere care a semnat certificatul de server și poate verifica dacă certificatul de server este valid. Dar poate că nu. Sistemul de operare are deja instalate certificate rădăcină ale autorităților de certificare, față de care semnăturile certificatelor de server sunt verificate, de exemplu, de browsere.

5) O cheie de sesiune este generată pentru o conexiune sigură. Acest lucru se face după cum urmează:
— Clientul generează o secvență digitală aleatorie
— Clientul îl criptează cu cheia publică a serverului și trimite rezultatul către server
— Serverul decriptează secvența primită folosind cheia privată
Având în vedere că algoritmul de criptare este asimetric, doar serverul poate decripta secvența. Când utilizați criptarea asimetrică, sunt utilizate două chei - privată și publică. Un mesaj trimis public este criptat, iar un mesaj trimis privat este decriptat. Este imposibil să decriptați un mesaj dacă aveți o cheie publică.

6) Aceasta stabilește o conexiune criptată. Datele transmise prin aceasta sunt criptate și decriptate până la terminarea conexiunii.

Certificat rădăcină

Chiar mai sus am menționat certificatul rădăcină. Acesta este un certificat de centru de autorizare, a cărui semnătură confirmă că certificatul care este semnat este cel care aparține serviciului corespunzător. Certificatul în sine conține de obicei un număr de câmpuri de informații care conțin informații despre numele serverului căruia i-a fost emis certificatul și perioada de valabilitate a acestui certificat. Dacă certificatul a expirat, acesta este invalidat.

Solicitare de semnătură (CSR, Cerere de semnare a certificatului)

Pentru a obține un certificat de server semnat, trebuie să generați o cerere de semnătură (CSR, Certificate Sign Request) și să trimiteți această solicitare la centrul de autorizare, care va returna un certificat semnat instalat direct pe server. Mai jos vom vedea cum se face acest lucru in practica. Mai întâi, este generată o cheie de criptare, apoi, pe baza acestei chei, este generată o cerere de semnătură, un fișier CSR.

Certificat de client

Un certificat de client poate fi generat atât pentru utilizarea dispozitivului, cât și a utilizatorului. De obicei, astfel de certificate sunt utilizate în verificarea bidirecțională, în care clientul verifică dacă serverul este cine spune că este, iar serverul face același lucru în schimb. Această interacțiune se numește autentificare în două sensuri sau autentificare reciprocă. Autentificarea bidirecțională îmbunătățește nivelul de securitate în comparație cu autentificarea unidirecțională și poate servi, de asemenea, ca înlocuitor pentru autentificarea utilizând o autentificare și o parolă.

Lanț de acțiuni pentru generarea certificatelor

Să aruncăm o privire practică asupra modului în care acțiunile asociate cu generarea certificatelor apar de la bun început și în practică.

Primul lucru de făcut este să generați un certificat rădăcină. Certificatul rădăcină este autosemnat. Și apoi alte certificate vor fi semnate cu acest certificat.

$ openssl genrsa -out root.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți .......+++ ....... ............... .........+++ e este 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dvs. de certificat . Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiune) : Nume comun al serviciului IT (de exemplu, FQDN al serverului sau numele DVS.) : Adresa de e-mail a certificatului rădăcină al companiei mele : [email protected] Vă rugăm să introduceți următoarele atribute „extra” pentru a fi trimise împreună cu solicitarea dvs. de certificat. O parolă de provocare: Un nume opțional de companie: Compania mea $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Semnătura ok subiect=/C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=Certificatul rădăcină al companiei mele/ [email protected] Obținerea cheii private

Astfel, am generat mai întâi o cheie privată, apoi o cerere de semnătură, apoi am semnat propria cerere cu cheia noastră și am primit propriul certificat digital, eliberat timp de 10 ani. Nu trebuie să introduceți o parolă de provocare atunci când generați un certificat.

Cheia privată TREBUIE să fie stocată într-un loc sigur; având-o, puteți semna orice certificat în numele dvs. Și certificatul rădăcină rezultat poate fi folosit pentru a identifica că certificatul, de exemplu, al serverului a fost semnat de noi și nu de altcineva. Acestea sunt acțiunile pe care centrele de autorizare le efectuează atunci când își generează propriile certificate. După crearea certificatului rădăcină, puteți începe generarea certificatului de server.

Vizualizați informațiile despre certificat

Conținutul certificatului poate fi vizualizat după cum urmează:

$ openssl x509 -noout -issuer -enddate -in root.pem emiter= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/ [email protected] notAfter=22 ianuarie 11:49:41 2025 GMT

Vedem cine a eliberat acest certificat și când expiră data de expirare a acestuia.

Certificat de server

Pentru a semna un certificat pentru server trebuie să facem următoarele:

1) Generați o cheie
2) Generați o cerere de semnătură
3) Trimiteți dosarul CSR la centrul de autorizare sau semnați-l singur

Un certificat de server poate include lanțul de certificate care semnează certificatul de server, dar poate fi și stocat într-un fișier separat. În principiu, totul arată aproximativ la fel ca atunci când se generează un certificat rădăcină

$ openssl genrsa -out server.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți ......................... ....... ................................................. . +++ .........................+++ e este 65537 (0x10001) $ openssl req -new -key server.key - out server .csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiune) : Nume comun al serviciului IT (de exemplu, FQDN al serverului sau numele DVS.) :www.compania mea.com Adresă de e-mail : [email protected] Vă rugăm să introduceți următoarele atribute „extra” care vor fi trimise împreună cu solicitarea dvs. de certificat. O parolă de provocare: Un nume de companie opțional: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Semnătura ok subiect=/C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=www.mycompany.com/ [email protected] Obținerea cheii private CA $ openssl x509 -noout -issuer -subject -enddate -in server.pem emiter= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Certificatul rădăcină al companiei mele/ [email protected] subiect= /C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=www.compania mea.com/ [email protected] notAfter=25 ianuarie 12:22:32 2016 GMT

În acest fel certificatul de server este semnat și vom ști care organizație a emis acest certificat. După semnare, certificatul terminat poate fi utilizat în scopul propus, de exemplu, instalat pe un server web.

Instalarea unui certificat SSL/TLS pe un server cu nginx

Pentru a instala un certificat SSL/TLS pe serverul web nginx, trebuie să urmați câțiva pași simpli:

1) Copiați fișierele .key și .pem pe server. Pe diferite sisteme de operare, certificatele și cheile pot fi stocate în directoare diferite. În Debian, de exemplu, acesta este directorul /etc/ssl/certs pentru certificate și /etc/ssl/private pentru chei. Pe CentOS, acesta este /etc/pki/tls/certs și /etc/pki/tls/private

2) Scrieți setările necesare în fișierul de configurare pentru gazdă. Cam așa ar trebui să arate (doar un exemplu):

Server ( asculta 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl activat; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 nu este recomandat aici!!! de exemplu numai ssl_protocols SSLv3 TLSv1;ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers activat; locație / ( try_files/ =4 $uri; ) )

3) Reporniți nginx

4) Accesați portul server 443 cu un browser - https://www.mycompany.com și verificați funcționalitatea acestuia.

Instalarea unui certificat SSL/TLS pe un server care rulează Apache

Instalarea unui certificat SSL/TLS pe Apache arată similar.

1) Copiați fișierele cheie și certificate pe server în directoarele corespunzătoare

2) Activați modulul ssl pentru Apache cu comanda „a2enmod ssl” dacă nu este deja activat

3) Creați o gazdă virtuală care va asculta portul 443. Configurația va arăta cam așa:

ServerAdmin [email protected] DocumentRoot /var/www Opțiuni FollowSymLinks AllowOverride Nici unul Opțiuni Indexuri FollowSymLinks MultiViews AllowOverride Niciunul Comanda permite, interzice permite din toate ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride Niciunul Opțiuni +ExecCGI -MultiViews +SymLinksIfOwnerMatch Ordinea permite, refuza Permite din toate ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel warn CustomLog $(APACHE_LOG_DIR)/ssl_access.log combinat SSLEngine pe SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/Această directivă/server. fișier , care conține o listă # cu toate certificatele care au semnat certificatul de server #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch „MSIE” \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch „MSIE ” ssl-unclean-shutdown

În același timp, mai este ceva de făcut. Găsiți în fișierul httpd.conf, sau apache2.conf, sau ports.conf, în funcție de sistem, următoarea secțiune a config:

Ascultă 443

Dacă nu există o astfel de condiție, trebuie adăugată la config. Și încă un lucru: trebuie să adăugați linia

NameVirtualHost *:443

Această linie poate fi în fișierul httpd.conf, apache2.conf sau ports.conf

4) Reporniți serverul web Apache

Crearea unui certificat de client

Un certificat de client este creat în aproape același mod ca un certificat de server.

$ openssl genrsa -out client.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți ........................+++ ..... .............................................++ e este 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere) :RU Numele statului sau provinciei (numele complet) :Sankt-Petersburg Numele localității (de exemplu, orașul) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petrersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiunea) :Nume comun de inginerie (de exemplu, FQDN-ul serverului sau numele DVS.) :Ivan Ivanov Adresa de e-mail : [email protected] Vă rugăm să introduceți următoarele atribute „extra” care vor fi trimise împreună cu cererea dumneavoastră de certificat. O parolă de provocare: Un nume de companie opțional: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -zile 365 Semnătura ok subiect=/C=RU/ST=N/A/L=Saint-Petrersburg/O=Compania mea/OU=Inginerie/CN=Ivan Ivanov/ [email protected] Obținerea cheii private CA $ openssl x509 -noout -issuer -subject -enddate -in client.pem emiter= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Certificatul rădăcină al companiei mele/ [email protected] subiect= /C=RU/ST=N/A/L=Saint-Petrersburg/O=Compania mea/OU=Inginerie/CN=Ivan Ivanov/ [email protected] notAfter=25 ianuarie 13:17:15 2016 GMT

Dacă aveți nevoie de un certificat de client în format PKCS12, creați-l:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Introduceți parola de export: Verificare - Introduceți parola de export:

Acum puteți utiliza certificatul de client pentru a lucra cu serverul nostru.

Configurarea nginx pentru a utiliza certificate client

Cel mai adesea, așa cum am spus deja, se folosește autentificarea unidirecțională, de obicei se verifică doar certificatul serverului. Să vedem cum să forțezi serverul web nginx să verifice certificatul client. Este necesar să adăugați opțiuni la secțiunea de server pentru a lucra cu certificate de client:

# Certificat(e) rădăcină(e) cu care clientul este semnat ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Opțiuni posibile: on | oprit | optional | optional_no_ca ssl_verify_client optional; # Profunzimea de verificare a lanțului de certificate cu care este semnat clientul ssl_verify_depth 2;

După aceasta, trebuie să reporniți setările sau întregul server și puteți verifica funcționarea.

Configurarea Apache pentru a utiliza certificate client

Apache poate fi configurat și prin adăugarea de opțiuni suplimentare la secțiunea gazdă virtuală:

# Director care conține certificate rădăcină pentru verificarea clientului SSLCARevocationPath /etc/apache2/ssl.crl/ # sau fișier care conține certificate SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Opțiune de verificare a clientului. Opțiuni posibile: # none, optional, require și optional_no_ca SSLVerifyClient require # View depth of the signature chain. Implicit 1 SSLVerifyDepth 2

După cum puteți vedea, opțiunile sunt aproximativ aceleași ca pentru nginx, deoarece procesul de verificare este organizat uniform.

Ascultarea informațiilor despre certificat folosind openssl

Pentru a testa modul în care serverul interacționează cu certificatele client, puteți verifica dacă conexiunea este stabilită folosind TLS/SSL.

Pe partea de server, începem să ascultăm pe port folosind openssl:

Openssl s_server -accept 443 -cert server.pem -key server.key -state

Pe partea de client, accesăm serverul, de exemplu, cu culr:

Curl -k https://127.0.0.1:443

În consola de pe partea serverului, puteți observa procesul de schimb de informații între server și client.

De asemenea, puteți utiliza opțiunile -verify [verification depth] și -Verify [verification depth]. Opțiunea pentru cazuri mici solicită clientului un certificat, dar nu este necesar să furnizeze unul. Cu majuscule - Dacă nu este furnizat un certificat, va apărea o eroare. Să începem să ascultăm din partea serverului astfel:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Din partea serverului, eroarea arată astfel:

140203927217808:error:140890C7:Rutine SSL:SSL3_GET_CLIENT_CERTIFICATE:peer nu a returnat un certificat:s3_srvr.c:3287:

Din partea clientului astfel:

Curl: (35) eroare:14094410:Rutine SSL:SSL3_READ_BYTES:sslv3 eșec strângere de mână alertă

Să adăugăm un certificat și un nume de domeniu pe partea client (puteți introduce numele gazdei pentru adresa 127.0.0.1 în fișierul /etc/hosts pentru a verifica):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Acum conexiunea va avea succes și puteți instala certificatul de server pe serverul web, puteți oferi clientului certificatul de client și puteți lucra cu ei.

Siguranță

Când utilizați SSL/TLS, una dintre metodele principale este metoda MITM (Man In The Middle). Această metodă se bazează pe utilizarea unui certificat de server și a unei chei pe un nod care va asculta traficul și va decripta informațiile schimbate între server și client. Pentru a organiza ascultarea, puteți folosi, de exemplu, programul sslsniff. Prin urmare, este de obicei recomandabil să stocați certificatul rădăcină și cheia pe o mașină care nu este conectată la rețea; pentru semnare, aduceți cereri de semnătură pe o unitate flash, semnați și luați-o de asemenea. Și, desigur, faceți copii de rezervă.

În termeni generali, așa sunt utilizate certificatele digitale și protocoalele TLS și SSL. Dacă aveți întrebări/completări, scrieți în comentarii.

Intrarea a fost publicată de autor în categoria etichetată , .

Post navigare

: 29 de comentarii

cl-service.com
Clientul generează însuși CSR-ul când comandă un certificat, unde clientul decide și să stocheze cheia privată; pentru a emite un certificat nu avem nevoie de cheia privată și clientul nu ne-o dă în niciun fel. Desigur, dacă acest lucru se întâmplă pe un server virtual obișnuit, atunci administratorii cu acces root la server au și acces la cheile care sunt stocate acolo.
binevoitor.
Tema sânilor nu este acoperită, deoarece tehnologia PKI descrisă nu are nimic de-a face cu titlul subiectului. Cel puțin din motive întemeiate, am furnizat link-uri către rfc.
P.S. Era o glumă despre un câine și un purice.
binevoitor.
Nu am vrut să te jignesc în niciun fel. Am căutat informații despre diferența dintre SSl și TLS în practică și linkul tău a fost primul pe Google. Am fost intrigat de titlul subiectului. Totul e misto, tine-o tot asa!
DrAibolit
Vă mulțumim pentru explicațiile dvs. perspicace despre certificarea digitală. Sunt nou in asta =)
Sper că puteți clarifica următoarea întrebare.
Deoarece subiectul fraudei este foarte dezvoltat în industria internetului, aș dori să învăț cum să determin „păduchii” site-urilor pe care le vizitez pe cont propriu (în special acolo unde există numerar și plăți, investiții etc.) și pe baza aceasta determină gradul de încredere (trebuie să mă înregistrez adesea, să las informații personale, să fac achiziții, tranzacții, investiții). Dacă am înțeles bine, deținerea acestei certificări vă permite să faceți o astfel de evaluare. Ei bine, pe de altă parte, obținerea acestuia nu este o problemă și este chiar gratuită.
Cum sau cu ce program puteți determina dacă un site web are un certificat digital? și de preferință categoria acesteia, care este atribuită atunci când o autoritate specială emite SSL DV (certificatul se eliberează cu verificarea doar a domeniului), SSL OV (cu verificarea organizației), EV (cu verificare extinsă a persoanei juridice). Site-urile frauduloase cel mai probabil nu vor folosi cea mai recentă opțiune de certificare.
M-aș bucura dacă mi-ați spune mai multe modalități de a determina fiabilitatea site-urilor))
1. mnorin Autorul postului
  Nu am întâlnit încă niciun program specific pentru aceste scopuri, dar pot da câteva sfaturi în acest sens.
  Puteți utiliza, de exemplu, Chromium sau Google Chrome. Să luăm, de exemplu, site-ul https://www.thawte.com/ - o companie care se ocupă de fapt cu certificate digitale.
  Bara de adrese va conține numele companiei și un lacăt verde. Aceasta înseamnă că organizația este verificată, acesta este cel puțin SSL OV.
  Dacă faceți clic pe lacăt, iar în fereastra drop-down „Detalii”, apoi „Vizualizare certificat”, puteți vedea informații despre certificat. Pentru Thawte, certificatul este semnat de următorul certificat: „thawte Extended Validation SHA256 SSL CA”, iar certificatul pentru click.alfabank.ru este semnat tot de Thawte, dar cu alt certificat. Acesta este „thawte EV SSL CA - G3”, adică au trecut și validarea extinsă.
  Ceva de genul.
Ruslan
Secțiunea „Cum funcționează SSL și TLS”, „Clientul generează o secvență digitală aleatorie.”

Eram sigur că clientul generează chei private și, în consecință, publice de sesiune (pe care, evident, le-ați numit „secvență digitală”). Cheia publică este transmisă serverului, iar serverul criptează pachetele către client cu cheia publică de sesiune a clientului.

Clarifica.
Incepator
Articolul este foarte util! Există chiar și exemple practice =) Dar nu am înțeles un lucru - care este diferența dintre un certificat rădăcină și un certificat de server? sau este acelasi lucru?
Vitalia
Buna ziua.
Hosterul a oferit un serviciu - SSL pentru servere virtuale. Noi am profitat de ea. S-a dovedit că pentru al treilea nivel, adică. Certificatul http://www.site.ru este invalid, numai pentru site.ru. În plus, vizitatorii trec în mod persistent la protocolul https, indiferent dacă merg la site.ru sau http://www.site.ru. Desigur, în al doilea caz, browserul începe să înjure sfâșietor, iar vizitatorul nu ajunge niciodată pe site.
Dar pentru cei care au ajuns pe site, site-ul a început să arate strâmb, o parte din meniu a dispărut, iar unele dintre imaginile din rezultatele căutării au încetat să fie afișate de unele componente.