SSL / TLS 101 pentru începători

O privire aprofundată asupra criptării care ne asigură conexiunile la internet


Deși Netscape a inventat inițial SSL la mijlocul anilor 90, nu a devenit obligatoriu ca fiecare site să instaleze un certificat SSL / TLS până în vara anului 2018, când Google a început să marcheze site-uri necriptate „Nu este securizat.“

În timp ce Google – cu motorul său de căutare, browserul Chrome și sistemul de operare Android – poate redefini unilateral internetul, nu a fost singur la acest mandat. Apple, Microsoft, Mozilla și celelalte părți interesate majore din industria tehnologică au luat o decizie concertată de a mandata certificatele SSL / TLS și HTTPS.

Motivul pentru asta este simplu: fără SSL / TLS și capacitatea de a se conecta în siguranță prin HTTPS, toate comunicările dintre site-urile web și vizitatorii lor ar fi schimbate în text clar și ușor de citit de către un terț.

Singurul dezavantaj al acestei recenzii recente pentru criptarea universală este faptul că a forțat un aflux de clienți noi pe o piață necunoscută, care face foarte puțin pentru a face mai puțin confuză pentru site-ul web sau proprietarul de afaceri..

Acest articol va servi drept ghid complet pentru toate lucrurile SSL / TLS, vom pune bazele trecând peste concepte de bază precum criptarea, HTTPS și natura conexiunilor la internet..

Sperăm, până la sfârșit, să vă simțiți încrezători în selectarea, achiziționarea și implementarea unui certificat TLS și să vă amintiți dacă aveți întrebări pe care le puteți lăsa în comentariile de mai jos..

Elemente fundamentale

Să începem prin a discuta conceptul care se află în centrul tuturor acestor lucruri: criptarea.

Criptarea, în cea mai simplă iterație a acesteia, este doar mai mult decât scrâșnirea datelor – folosind o cifră sau cheie predeterminată – astfel încât aceasta este redată de către oricine, cu excepția unei alte părți cu aceeași cheie privată..

De-a lungul istoriei, criptarea cheilor private a fost cel mai frecvent model utilizat. În criptarea cheilor private, ambele părți trebuie să dețină sau să schimbe cel puțin o cheie privată care poate fi folosită atât pentru criptarea, cât și pentru decriptarea informațiilor.

La început, majoritatea cifrelor care stau la baza acestor criptosisteme erau primitive, bazându-se pe substituții simple sau înlocuirea cuvintelor comune cu caractere. Însă, în timp, cifrele au devenit mai influențate de matematică și au crescut în complexitate.

De exemplu, la mijlocul anilor 1600 în Franța, criptograful regelui Ludovic al XIV-lea a creat un cifru atât de bine proiectat încât nu a fost spart decât după 250 de ani mai târziu și doar atunci parțial. Până în ziua de azi, există arhive în valoare de sute de ani în arhivele franceze care nu pot fi descifrate niciodată.

Cu toate că istoricul criptarea a fost un mijloc pentru a fi ascuns sau clandestin, apariția internetului a luat conceptul mai mult. Internetul este omniprezent și gestionează o serie de funcții critice. În fiecare zi, miliarde de oameni îl folosesc pentru a accesa și trimite informații sensibile, pentru a-și gestiona finanțele, pentru a tranzacționa cu întreprinderile – îl numiți.

Problema este că internetul nu a fost conceput în întregime pentru a se adapta la ceea ce a devenit. La început, în zilele în care academia și guvernul SUA au dezvoltat pentru prima dată protocoale de rețea, internetul a fost văzut doar ca un mecanism pentru schimbul gratuit de informații între guvern și instituțiile academice. În acel moment, activitatea comercială a fost ilegală online. Comerțul electronic nu a fost un cuvânt care chiar a fost inventat încă. Iar site-ul web era mai mult o noțiune geografică.

Așadar, când HTTP sau Protocolul de transfer de hipertext a fost introdus pentru prima dată în 1991, faptul că conexiunile pe care le-a format au schimbat date în textul clar nu a fost o problemă de descalificare..

Lucrurile sunt mult diferite astăzi. Informațiile schimbate online nu sunt cercetări academice sau informații disponibile gratuit, sunt informații de identificare personală și date sensibile care pot costa oamenilor bani sau chiar, în unele regiuni, viața lor. Aceasta a solicitat o abordare mai sigură.

Răspunsul a fost criptare.

Problema schimbului de chei

O problemă care a afectat istoric chiar și cele mai bune criptosisteme continuă până în zilele noastre.

Ceea ce am discutat anterior și ceea ce a fost în mod tradițional standard pentru criptare, este criptarea cu cheie privată. Aceasta se numește, de asemenea, criptare simetrică sau criptare în două sensuri – cu chei private care gestionează atât funcțiile de criptare cât și de decriptare necesare pentru a comunica.

Pentru ca criptarea cheii private să funcționeze, cheia privată trebuie transferată între părți sau ambele părți trebuie să dețină propria copie. Oricum ar fi, securitatea cheilor private a fost esențială pentru integritatea criptosistemului și, după cum nu puteți îndoși să crezi, schimbul de chei este o problemă la fel de veche ca criptarea.

Apoi, în anii ’70 – din punct de vedere tehnic de două ori diferite, un ocean întreg în afară – a fost conceptualizată și adusă la viață o nouă formă de criptare: criptarea cu chei publice.

Întrucât criptarea cheilor private este o funcție bidirecțională, simetrică, cu cheia privată capabilă să cripteze și să decripteze datele, criptarea cheii publice este asimetrică; Într-un fel. În loc de o singură cheie privată, există o pereche de chei public-private. Cheia publică gestionează criptarea și este, după cum îi spune și numele, disponibil public, în timp ce cheia privată, care gestionează decriptarea, este păstrată secretă de către proprietarul său. Folosind cheia publică, puteți cripta o bucată de date și o puteți trimite proprietarului cheii, unde numai ei vor putea să o decripteze.

Grozav, dar cât de util este asta?

Ei bine, criptarea unidirecțională nu este ideală pentru criptarea conexiunilor la internet, este dificil de comunicat atunci când o parte poate cripta doar, iar cealaltă poate decripta. Nu, pentru a cripta o conexiune la internet, va trebui să utilizați criptare simetrică, cheie privată.

Dar cum schimbi cheile? Mai ales online?

Criptare cu cheie publică.

Și asta, distilată până la esența sa, este despre SSL / TLS: schimbul de chei sigur.

Aici vom lega toate aceste concepte împreună. Dacă doriți ca comunicarea dvs. cu un site web să fie privată, atunci trebuie să vă conectați la aceasta în siguranță. Dacă doriți să vă conectați în siguranță cu acel site web, atunci trebuie să schimbați chei private simetrice, astfel încât să le puteți utiliza pentru a comunica. SSL / TLS (și PKI în general) este doar un mecanism fantezist pentru crearea și schimbul acelei chei de sesiune.

Folosind SSL / TLS, puteți autentifica serverul sau organizația cu care sunteți pe cale să vă conectați și să vă asigurați că schimbați în siguranță cheile private pe care le veți utiliza pentru a cripta comunicarea cu partea dorită..

Din păcate, SSL / TLS și PKI au o mulțime de terminologii și piese mobile, care pot confunda cu ușurință oamenii, dar cei care cred că atunci când te îndepărtezi de toată matematica și jargonul tehnic, aceasta este doar o soluție tehnologică modernă modernă pentru o vârstă -bold problem: schimb de chei.

Acum să trecem peste câțiva termeni cheie

Înainte de a merge mai departe, să trecem peste câțiva alți termeni-cheie. Am introdus deja HTTP, protocolul de transfer de hipertext, care a fost coloana vertebrală a internetului de zeci de ani. Dar după cum am discutat, internetul a evoluat spre ceva mult diferit decât a fost când a fost publicată prima dată HTTP în 1991.

A fost nevoie de un protocol mai sigur. Astfel, HTTPS.

HTTPS, care este uneori denumit HTTP prin TLS, folosește criptarea pentru a face schimbul de date în timpul unei conexiuni care nu poate fi citită oricui, dar părții dorite. Acest lucru este deosebit de important atunci când aveți în vedere natura unei conexiuni moderne de internet.

În timp ce în primele zile ale internetului, o conexiune era rezonabilă, acum conexiunile sunt dirijate prin zeci de dispozitive în drum spre destinația finală. Dacă ați dorit vreodată o demonstrație practică, deschideți promptul de comandă de pe sistemul de operare și introduceți comanda „tracert geekflare.com”.

Ceea ce veți vedea este calea pe care conexiunea dvs. a parcurs-o pe ruta către destinația sa. Până la 30 de sărituri. Aceasta înseamnă că datele dvs. trec prin fiecare dintre aceste dispozitive înainte de a ajunge la orice site web sau aplicație la care vă conectați. Și dacă cineva are un sniffer de pachete sau un ascultător instalat pe oricare dintre aceste dispozitive, poate fura orice date transmise și chiar poate manipula conexiunea în unele cazuri.

Aceasta se numește atac de om în mijloc (MITM).

Dacă doriți să aflați despre atacul MITM, atunci consultați acest curs online.

Există mult mai multe suprafețe de acoperit cu conexiuni moderne la internet decât marea majoritate a oamenilor realizează, motiv pentru care datele criptate în timpul transmisiei sunt critice. Nu ai idee cine ar putea asculta sau cât de banal este ușor de făcut.

O conexiune HTTP se face prin port 80. În scopurile noastre, puteți gândi porturile ca construcții care indică un serviciu de rețea sau un protocol. Un site web standard servit prin HTTP folosește portul 80. HTTPS utilizează de obicei portul 443. Când un site web instalează un certificat, își poate redirecționa paginile HTTP către cele HTTPS, iar browserele utilizatorilor vor încerca să se conecteze în siguranță prin port 443, în așteptarea autentificării..

Din păcate, termenii SSL / TLS, HTTPS, PKI și criptare se aruncă foarte mult, uneori sunt folosiți în mod interschimbabil, așa că pentru a elimina orice confuzie persistentă, iată un ghid rapid:

  • SSL – Secure Sockets Layer, protocolul original de criptare utilizat cu HTTPS
  • TLS – Transport Layer Security, cel mai recent protocol de criptare care a înlocuit SSL
  • HTTPS – Versiunea sigură a HTTP, folosită pentru a crea conexiuni cu site-uri web
  • PKI – Public Key Infrastructure, se referă la întregul model de încredere care facilitează criptarea cheilor publice

SSL / TLS funcționează împreună pentru a permite conexiunile HTTPS. Iar PKI se referă la întregul lucru când măriți.

Am înțeles? Nu vă faceți griji, veți face asta.

Construirea unei infrastructuri cheie publică

Acum că am pus bazele, măriți și privim arhitectura folosită de modelul de încredere din centrul SSL / TLS.

Când ajungeți pe un site web, primul lucru pe care îl face browserul dvs. este să verifice autenticitatea certificatului SSL / TLS pe ​​care îl prezintă site-ul. Vom ajunge la ceea ce se întâmplă după ce această autentificare are loc în câteva secțiuni, dar vom începe discutând modelul de încredere care face totul posibil.

Deci, vom începe prin a pune întrebarea: de unde știe computerul meu dacă are încredere într-un anumit certificat SSL / TLS?

Pentru a răspunde la aceasta, va trebui să discutăm PKI și diferitele elemente care îl fac să funcționeze. Vom începe cu autoritățile de certificare și programele Root.

Autoritățile de certificare

O autoritate de certificare este o organizație care respectă un set de standarde prestabilite în schimbul capacității de a emite certificate digitale de încredere.

Există zeci de CA-uri, atât gratuite, cât și comerciale, care pot emite certificate de încredere.

Toți trebuie să respecte un set de standarde care au fost dezbătute și legislative prin intermediul Forumului CA / Browser, care acționează ca organism de reglementare pentru industria TLS. Aceste standarde conturează lucruri precum:

  • Garanții tehnice care trebuie să existe
  • Cele mai bune practici pentru efectuarea validării
  • Cele mai bune practici de emitere
  • Proceduri și termene de revocare
  • Cerințe de înregistrare a certificatelor

Aceste ghiduri au fost stabilite de browsere, în combinație cu CA-urile. Browser-urile joacă un rol unic în ecosistemul TLS.

Nimeni nu poate ajunge nicăieri pe internet fără browser-ul său web. Ca atare, browserul va primi și valida certificatul digital TLS și apoi va schimba cheile cu serverul. Deci, având în vedere rolul lor primordial, aceștia poartă o influență considerabilă.

Și este important să rețineți că browserele au fost concepute pentru a fi cât mai sceptice. Să nu ai încredere în nimic. Acesta este cel mai bun mod de a-și păstra utilizatorii în siguranță. Așadar, dacă un browser va avea încredere într-un certificat digital – care poate fi folosit greșit în detrimentul utilizatorului – are nevoie de anumite asigurări că cine a eliberat acest certificat și-a făcut diligența.

Acesta este rolul și responsabilitatea autorităților de certificare. Și browserele nu respectă nici greșelile. Există un cimitir literal al fostelor CA care s-au derulat pe browsere și au fost puse la pășune.

Atunci când o autoritate de certificare și-a demonstrat conformitatea cu cerințele de bază ale Forumului CAB și a trecut toate auditurile și revizuirile necesare, poate solicita diferitelor programe root să adauge certificatele rădăcină..

Programe root

Un program root – cele mai importante sunt gestionate de Apple, Microsoft, Google și Mozilla – este aparatul care supraveghează și facilitează magazinele root (numite uneori trust store), care sunt colecții de certificate Root CA, care se află pe sistemul unui utilizator. Încă o dată, aceste rădăcini sunt incredibil de valoroase și incredibil de periculoase – la urma urmei pot emite certificate digitale de încredere – deci securitatea este de cea mai mare preocupare..

Acesta este motivul pentru care CA-urile nu emit aproape niciodată direct din certificatele Root CA în sine. În schimb, ele creează certificate intermediare rădăcină și le folosesc pentru a emite certificate de utilizator final sau de frunze. De asemenea, pot transmite aceste rădăcini către Sub-CA, care sunt autorități de certificare care nu au rădăcinile lor dedicate, dar pot totuși să elibereze certificate semnate încrucișate în afara intermediarilor lor.

Așadar, haideți să facem asta împreună. Atunci când un site web dorește să emită un certificat TLS, generează ceva pe numele de cerere de semnare a certificatului (CSR) pe serverul pe care este găzduit. În această solicitare sunt incluse toate detaliile pe care site-ul web dorește să fie inclus în certificat. După cum veți vedea un pic, cantitatea de informații poate varia de la detaliile complete ale afacerii la o simplă identitate a serverului, dar odată finalizată CSR, aceasta este trimisă către Autoritatea de certificare pentru emitere.

Înainte de eliberarea certificatului, CA va trebui să-și îndeplinească diligența obligatorie de către CA / Browser Forum și să valideze că informațiile conținute în CSR sunt corecte. După ce a fost verificat, semnează certificatul cu cheia privată și îl trimite înapoi proprietarului site-ului pentru instalare.

Înlănțuirea certificatelor

După instalarea certificatului TLS, oricând cineva vizitează site-ul pe serverul care îl găzduiește va prezenta browser-ul utilizatorului certificatul. Browser-ul va analiza semnătura digitală din certificat, cea realizată de autoritatea de certificare de încredere, care garantează faptul că toate informațiile conținute în certificat sunt corecte.

Aici intră în joc termenul înlănțuirea certificatelor.

Browserul va citi semnătura digitală și va muta un link pe lanț – în continuare, va verifica semnătura digitală pe certificatul intermediar a cărui cheie privată a fost folosită pentru a semna certificatul de frunze. Va continua în urma semnăturilor până când lanțul de certificate se va încheia la una dintre rădăcinile de încredere din magazinul său rădăcină sau până când lanțul nu se va încheia fără a ajunge la o rădăcină, caz în care va apărea o eroare de browser și conexiunea nu va reuși.

Acesta este motivul pentru care nu puteți emite și semna în sine certificatele.

Browser-urile vor avea încredere numai în certificatele SSL / TLS pe ​​care le pot transmite către magazinul lor root (ceea ce înseamnă că au fost emise de o entitate de încredere). Autoritățile de certificare sunt obligate să respecte standardele specifice pentru a-și menține încrederea și chiar atunci browserele nu pot avea încredere în ele.

Navigatorii nu au astfel de garanții cu privire la certificatele semnate cu sine, motiv pentru care ar trebui să fie dislocate doar în rețelele interne, în spatele firewall-urilor și în mediile de testare.

Tipuri și funcționalități ale certificatului SSL / TLS

Înainte de a privi SSL / TLS în mișcare, să vorbim despre certificate și diversele iterații disponibile. Certificatele TLS sunt cele care facilitează protocolul TLS și ajută la dictarea condițiilor conexiunilor HTTPS criptate pe care le face un site web.

Mai devreme am menționat că instalarea unui certificat TLS vă permite să configurați site-ul dvs. web pentru a face conexiuni HTTPS prin port 443. De asemenea, acționează ca un fel de insigna de nume pentru site-ul sau serverul cu care interacționați. Revenind la ideea că, în centrul său, SSL / TLS și PKI sunt toate forme rafinate de schimb de chei sigure, certificatul SSL / TLS ajută la notificarea browserului despre cine trimite cheia sesiunii – cui este partea la celălalt capăt al conexiunea este.

Și atunci când descompun diferitele iterații ale certificatelor SSL / TLS, acesta este un lucru relevant de reținut. Certificatele variază în ceea ce privește nivelul de funcționalitate și de validare. Sau pentru a spune altfel, acestea variază în funcție de:

  • Câte identități să se afirme
  • La ce puncte finale se afirmă identitatea

Răspunsul la aceste două întrebări vă va oferi o indicație destul de clară a tipului de certificat de care aveți nevoie.

Câte identități pentru Assert

Există trei niveluri diferite de validare disponibile cu certificate SSL / TLS și variază în funcție de informațiile de identitate pe care site-ul dvs. web dorește să le afirme..

  • Certificări SSL de validare a domeniului – identitate server asertare
  • Certificarea SSL – Validare organizație – Identificare parțială a organizației
  • Certificate de SSL de validare extinsă – Afirmați identitatea completă a organizației

Certificările SSL de validare a domeniului sunt de departe cele mai populare datorită prețului și vitezei cu care pot fi emise. Certificatele DV SSL / TLS necesită o simplă verificare a controlului de domeniu, care poate fi realizată în mai multe moduri diferite, dar imediat ce este certificatul poate fi eliberat. Puteți obține, de asemenea, câteva versiuni de 30 de zile și 90 de zile în mod gratuit, ceea ce a adăugat, fără îndoială, cota lor de piață.

Dezavantajul este că certificatele DV SSL afirmă o identitate minimă. Și având în vedere că aproape jumătate din toate site-urile de tip phishing au acum un certificat DV SSL instalat pe ele, acestea nu vă cumpără neapărat multe în calea de încredere.

Validarea organizației Certificările SSL sunt tipul original de certificat SSL / TLS. Acestea sunt, de asemenea, singurul tip de certificat SSL care poate securiza o adresă IP în urma unei decizii din 2016 de către CAB Forum de a invalida toate certificatele SSL intranet. Validarea organizației necesită o verificare ușoară a afacerilor și poate fi de obicei emisă într-o zi sau două – uneori mai rapid. Certificatele OV SSL afirmă unele informații organizaționale, dar un utilizator de internet ar trebui să facă clic pe pictograma lacatului și să o caute. În prezent, vedeți o mulțime de certificate SSV OV desfășurate în rețele mari de întreprinderi și companii, pentru conexiunile făcute în spatele firewall-urilor, de exemplu.

Deoarece nici certificatele DV și OV SSL nu afirmă identitate suficientă pentru a satisface majoritatea browserelor, acestea primesc tratament neutru.

Certificatele SSL de validare extinsă sunt de departe cele mai controversate, deoarece unii din comunitatea tehnică consideră că trebuie să se facă mai mult pentru a consolida validarea de care depind. Dar, EV SSL afirmă identitatea maximă. Pentru a finaliza validarea extinsă, autoritatea de certificare pune organizația printr-un proces riguros de verificare, care poate dura mai mult de o săptămână în unele cazuri.

Dar beneficiul este incontestabil: deoarece afirmă o identitate suficientă, un site web cu certificat EV SSL primește un tratament unic pentru browser, inclusiv numele său prezentat în bara de adrese a browserului.

Nu există altă modalitate de a realiza acest lucru și nu puteți falsifica unul – bara de adrese EV este unul dintre cei mai puternici indicatori vizuali pe care îi avem astăzi.

La ce puncte finale se afirmă Identitatea

Celălalt mod în care certificatele SSL / TLS variază este în ceea ce privește funcționalitatea. Site-urile web au evoluat destul de mult încă din primele zile ale internetului, cu diverse companii care implementează site-uri în moduri diferite. Unele au mai multe domenii pentru diferite verticale ale companiei; alții folosesc subdomenii pentru mai multe funcții și aplicații web. Unii le folosesc pe amândouă.

Indiferent care este contextul, există un certificat SSL / TLS care vă poate ajuta la securizarea acestuia.

Domeniu unic

Site-ul principal și certificatul SSL standard sunt doar un singur domeniu. Majoritatea certificatelor moderne SSL / TLS vor asigura atât versiunile WWW, cât și cele non-WWW ale domeniului, dar sunt limitate la un singur domeniu. Poti comparați aici certificatele SSL.

Multi-domeniu

Certificate multi-domeniu sau Certificările de comunicare unificate (în cazul serverelor Microsoft Exchange și Office Communications) există, de asemenea, pentru a oferi organizațiilor posibilitatea de a cripta mai multe domenii cu un singur certificat. Aceasta poate fi o opțiune atractivă, deoarece economisește bani și simplifică gestionarea certificatelor (expirări / reînnoiri).

Certificatele cu mai multe domenii și UCC folosesc SAN, câmpul Nume alternativ subiect din CSR, pentru a adăuga domenii suplimentare la certificat. Majoritatea CA permit până la 250 de SAN diferite pe un singur certificat. Și majoritatea certificatelor Multi-Domain vin cu 2-4 SAN-uri gratuite, cu restul disponibil pentru achiziționare, după cum este necesar.

Certificative SSL Wildcard

Certificări SSC cu wildcard sunt un tip de certificat extrem de util, deoarece pot cripta un număr nelimitat de subdomenii la același nivel al adresei URL. De exemplu, dacă aveți un site web care folosește subdomenii precum:

  • app.website.com
  • portal.website.com
  • user.website.com

Le puteți cripta pe toate cu același certificat Wildcard folosind un asterisc în câmpul FQDN al CSR: * .website.com

Acum, orice sub-domeniu, chiar și cele pe care nu le-ați adăugat încă, poate fi securizat cu acel certificat.

Cu toate acestea, există două dezavantaje ale certificatelor Wildcard. Primul este că folosind aceeași cheie publică în anumite puncte finale, sunteți mai vulnerabil la anumite exploatări precum atacurile Bleichenbacher.

Cealaltă este că nu există nicio opțiune Wildcard EV. Datorită naturii deschise a funcționalității Wildcard, browserele nu sunt în acord cu delegarea acelui nivel de încredere. Dacă doriți Bara de adrese EV în subdomeniile dvs., va trebui să le criptați individual sau să utilizați un certificat EV Multi-Domain.

Wildcard multi-domeniu

Un plus relativ nou la ecosistemul SSL / TLS, Multi-Domain Wildcard poate cripta până la 250 de domenii diferite, dar poate utiliza și un asterisc în câmpurile SAN, care vă permite, de asemenea, să criptați 250 de domenii diferite și toate primele lor însoțitoare. -level sub-domenii.

Un alt caz de utilizare pentru Wildcard Multi-Domain este ca Wildcard multi-nivel, unde poate cripta subdomenii la mai multe niveluri ale adresei URL (un wildcard standard le poate cripta doar la un nivel).

Datorită funcționalității Wildcard, Wildcard-urile cu mai multe domenii nu sunt disponibile nici în EV.

SSL / TLS în mișcare

Acum că am acoperit toate conceptele semnificative pe care le-am machiat SSL / TLS și PKI, să le punem la capăt și să le vedem în mișcare.

Validare și emitere

Să începem la început cu un site web care achiziționează un certificat SSL / TLS de la un CA sau un distribuitor. În urma achiziției, contactul organizațional care gestionează achiziția de certificate creează o cerere de semnare a certificatului pe serverul în care va fi instalat certificatul (serverul care găzduiește site-ul web).

Alături de CSR, serverul va genera, de asemenea, o pereche de chei publice / private și va salva cheia privată local. Când CA primește CSR și Cheia Publică, aceasta efectuează etapele de validare necesare pentru a se asigura că orice informație conținută în certificat este corectă. În general, pentru certificatele de autentificare de afaceri (nu DV), aceasta implică căutarea informațiilor de înregistrare și a înregistrărilor publice ale unei organizații în bazele de date ale guvernului.

După finalizarea validării, CA folosește una din cheile private ale unuia dintre certificatele sale emitente, de obicei o rădăcină intermediară și semnează certificatul înainte de a-l returna proprietarului site-ului.

Acum, proprietarul site-ului poate să ia certificatul SSL / TLS nou emis, să îl instaleze pe serverul lor și să configureze site-ul pentru a realiza conexiuni HTTPS pe portul 443 (folosind 301 redirecții pentru a trimite trafic din paginile HTTP preexistente către noile lor omologi HTTPS).

Autentificare și strângere de mână SSL

Acum că certificatul SSL / TLS este instalat și site-ul web a fost configurat pentru HTTPS, să ne uităm la modul în care va facilita conexiunile criptate cu vizitatorii site-ului..

La sosirea pe site-ul web, serverul va prezenta certificatul SSL / TLS browser-ului utilizatorului. Browserul utilizatorului efectuează apoi o serie de verificări.

În primul rând, va autentifica certificatul prin vizualizarea semnăturii sale digitale și urmând lanțul de certificate. De asemenea, se va asigura că certificatul nu a expirat și va verifica jurnalele de transparență a certificatelor (CT) și Listele de revocare a certificatelor (CRL). Cu condiția ca lanțul să revină la una dintre rădăcinile din depozitul de încredere al sistemului și dacă este valabil, browserul va avea încredere în certificat.

Acum este timpul de strângere de mână.

Strângerea de mână SSL / TLS este seria de pași în care clientul (utilizatorul) și serverul (site-ul web) negociază parametrii conexiunii lor sigure, generează și schimbă apoi cheile de sesiune simetrice..

În primul rând, vor decide cu privire la o suită de cifrare. O suită de cifrare este grupul de algoritmi și cifre care vor fi utilizate pentru conexiune. Certificatul SSL / TLS oferă o listă de suite de cifrare pe care le acceptă serverul. În general, o suită de criptare include un algoritm de criptare a cheilor publice, un algoritm de generare de chei, un algoritm de autentificare a mesajelor și un algoritm de criptare simetric sau în vrac – deși acesta a fost rafinat în TLS 1.3.

După ce i se prezintă lista cu cifrele acceptate, clientul va alege una agreabilă și o va comunica serverului. De acolo, clientul va genera o cheie de sesiune simetrică, o va cripta folosind cheia publică și apoi o va trimite către server, care deține cheia privată necesară pentru a decripta cheia de sesiune..

Odată ce ambele părți au o copie a cheii de sesiune, comunicarea poate începe.

Și acesta este SSL / TLS.

Puteți vedea cum toate conceptele prin care am trecut mai devreme interacționează între ele pentru a crea un sistem sofisticat, dar elegant pentru securizarea conexiunilor la internet. Folosim criptografia cu chei publice pentru a schimba cheile de sesiune în siguranță cu care vom comunica. Certificatele care afirmă serverul sau identitatea organizațională pot fi de încredere datorită infrastructurii pe care o avem în cadrul diverselor CA, browsere și programe root.

Și comunicarea se produce ca urmare a criptării simetrice, a cheilor private, descendentă din criptosistemele clasice ale antichității.

Există o mulțime de piese mobile, dar atunci când încetiniți și le înțelegeți pe toate individual, este mult mai ușor să vedeți cum funcționează toate împreună.

Înainte de a merge, terminăm cu câteva mișcări legate de SSL / TLS, pe care le puteți face post-instalare / configurare pentru a beneficia la maxim de investiții.

După SSL / TLS – Obținerea la maxim a implementării dvs.

Pur și simplu, instalarea unui certificat și configurarea corectă a site-ului dvs. nu înseamnă că site-ul dvs. este sigur. TLS este doar o componentă a unei strategii mai largi, holistice de apărare cibernetică. Dar o componentă importantă, cu toate acestea. Haideți să acoperim câteva lucruri pe care le puteți face pentru a vă asigura că beneficiați la maxim de implementare.

Dezactivați asistența serverului pentru protocoale vechi

Revenind la conversația pe care am avut-o mai devreme despre Cipher Suites, o parte din configurarea serverului dvs. este să decideți ce apartamente de cifrare și versiunile SSL / TLS să fie acceptate. Este imperativ să dezactivați asistența pentru versiunile mai vechi SSL / TLS, precum și algoritmi specifici pentru a preveni vulnerabilitatea la mai multe exploatări cunoscute.

SSL 2.0 și SSL 3.0 au ambii peste 20 de ani. Cele mai bune practici au fost să depreciezi sprijinul pentru ei cu ani în urmă, dar până în ziua de azi, aproximativ 7% din topul 100.000 de Alexa le mai permit. Acest lucru este periculos, deoarece te expune la atacuri de tip SSL și retrogradare precum POODLE.

TLS 1.0 și TLS 1.1 sunt de asemenea împrumutate.

Companiile majore de tehnologie, Apple, Microsoft, Google și Mozilla, au făcut un anunț comun în această toamnă că vor depreța suportul pentru TLS 1.0 și 1.1 la începutul anului 2020.

Versiunile de protocol sunt sensibile la vulnerabilități precum POODLE, FREAK, BEAST și CRIME (toate acestea sunt acronime). TLS 1.2 a fost scos de zece ani și ar trebui să fie standardul. TLS 1.3 a fost finalizată vara trecută, iar adopția a evoluat într-un ritm constant de atunci.

În plus, există algoritmi specifici care nici nu trebuie folosiți. DES, de exemplu, poate fi spart în câteva ore. RC4 este mai vulnerabil decât credea o dată și a fost deja scoasă în afara legii conform standardelor de securitate a datelor din industria cardurilor de plată. Și în final, având în vedere știrile despre exploatările recente, nu este recomandat să mai utilizăm RSA pentru schimbul de chei.

Algoritmi / cifrări sugerate:

  • Schimb de chei: curba eliptică Diffie-Helman (ECDH)
  • Autentificare: Algoritm de semnătură digitală cu curb eliptic (ECDSA)
  • Criptare simetrică / în vrac: AES 256 în modul contor Galois (AES256-GCM)
  • Algoritmul MAC: SHA-2 (SHA384)

SSL întotdeauna

În trecut, site-urile web au migrat uneori doar paginile web care colectează informații către HTTPS, în timp ce serveau restul site-ului prin HTTP. Aceasta este o practică proastă.

Pe lângă faptul că Google va marca acele pagini „Nu sunt sigure”, de asemenea, expuneți potențial vizitatorii site-ului dvs. la risc, prin faptul că browserele lor sărită înainte și înapoi între paginile criptate și cele HTTP..

Ar trebui să configurați întregul site web pentru HTTPS. Aceasta se numește Always-on SSL. La urma urmei, nu este ca și cum plătiți prin pagină, certificatul dvs. SSL / TLS vă poate cripta întregul site. Așa că faceți așa.

Configurați o înregistrare de autorizare a autorității de certificare (CAA)

Unul dintre cele mai semnificative riscuri pe care le prezintă certificatele digitale, în general, este emiterea greșită. În cazul în care unei alte părți decât ți se eliberează un certificat SSL / TLS pentru site-ul dvs. web, acestea vă pot răspunde în mod eficient și vă pot provoca tot felul de probleme.

Înregistrările CAA ajută la atenuarea acestui risc prin limitarea a ceea ce autoritățile de certificare pot emite certificate digitale pentru site-ul dvs. web. Autoritățile de certificare sunt solicitate de către CA / Browser Forum pentru a verifica înregistrările CAA înainte de a emite orice certificat. Dacă CA nu are autorizația de eliberare pentru site-ul respectiv, nu se poate. Dacă faceți acest lucru, vom fi considerați o eroare de emisiune și ar provoca mânia comunității browserului.

Adăugarea unei înregistrări CAA este relativ ușoară, este o înregistrare DNS simplă care poate fi adăugată prin interfața majorității platformelor de găzduire. Puteți restricționa CA-urile care pot fi emise pentru domeniul dvs., precum și dacă pot fi emise certificate Wildcard pentru acesta.

Adăugați site-ul dvs. web la Lista de preîncărcare HSTS

HTTP Strict Transport Security sau HSTS este un antet HTTP care obligă browserele să realizeze conexiuni HTTPS cu un site dat. În acest fel, chiar dacă utilizatorul web încearcă să meargă la versiunea HTTP a paginii, va ajunge să viziteze versiunea HTTPS. Acest lucru este important pentru că închide fereastra pentru mai multe exploatări cunoscute, cum ar fi atacurile de downgrade și deturnarea cookie-urilor.

Din păcate, un vector minuscul de atac rămâne cu HSTS, motiv pentru care ar trebui să adăugați site-ul dvs. pe lista de preîncărcare. În mod obișnuit, atunci când un vizitator ajunge pe site-ul dvs. web, browserul său va descărca antetul HTTP și va respecta-l pentru oricât timp a fost stabilită politica. Dar chiar în prima vizită, înainte de primirea antetului, există încă o deschidere minusculă pentru un atacator.

Lista de preîncărcare HSTS este înregistrată de Google și unele variații ale acestora sunt utilizate de toate browserele principale. Aceste browsere știu să se conecteze doar prin HTTPS la orice site web care figurează pe listă – chiar dacă nu a fost niciodată vizitat acolo. Poate dura o săptămână sau două pentru ca site-ul dvs. să apară pe listă, din cauza faptului că actualizările la listă sunt interzise împreună cu programele de lansare ale browserelor..

Întrebări frecvente SSL / TLS

Ce este un certificat X.509?

X.509 se referă la tipul de certificat digital care este utilizat cu SSL / TLS și alte tipuri de PKI. X.509 este un standard de criptare a cheilor publice. Ocazional, veți vedea că companiile folosesc certificatul X.509 în locul „certificatului digital” sau „certificat PKI”.

De ce expiră certificatele SSL / TLS?

Există două motive pentru aceasta.

Prima este că internetul este în continuă schimbare, site-urile vin și site-urile web. Și având în vedere cât de sensibile sunt browserele despre încrederea acestor certificate în primul rând, ei vor să știe că site-urile web care prezintă certificatele sunt supuse unor validări periodice. Nu este diferit de modul în care trebuie să te înregistrezi ocazional pentru a actualiza informațiile din permisul de conducere.

Celălalt motiv este mai tehnic. Este mai greu să proliferezi actualizările și modificările tehnice atunci când certificatele nu expiră timp de 3-5 ani. Întrucât, dacă certificatele expiră la fiecare 24 de luni, cel mai lung certificat poate fi depășit este de doi ani. În 2017, valabilitatea maximă a fost redusă de la trei ani la doi. Acesta va fi probabil scurtat la 12 luni în scurt timp.

Cum reînnoiești un certificat SSL / TLS?

Reînnoirea poate fi un pic greșit, deoarece înlocuiți vechiul certificat cu unul nou emis. Făcând acest lucru în mod regulat, vă permite să fiți la curent cu noile avansări ale tehnologiei de criptare și vă asigură că informațiile dvs. de validare rămân la zi. CA-urile pot reutiliza doar informațiile de validare care au fost furnizate inițial cu mult timp înainte ca cerințele de bază să le oblige să le revalideze.

Când reînnoiți, puteți păstra același tip de certificat pe care l-ați avut înainte sau puteți merge cu ceva nou, puteți chiar să modificați CA-uri. Marele lucru este cât timp ai rămas pe certificatul de expirare – poți prelungi până la trei luni. Atâta timp cât reînnoiți înainte de expirarea certificatului, puteți prelua orice timp rămas și reutilizați toate informațiile de validare care nu au scurs de la ultima validare. Dacă îl lași să expire, pornești de la zero.

Ce este HTTPS Inspection?

Multe companii mai mari cu rețele mai mari le place să aibă vizibilitate în traficul lor. În această privință, HTTPS este o sabie cu două tăișuri. Protejează confidențialitatea oamenilor, dar poate ajuta și ciberneticii să se ascundă. Multe organizații își vor decripta traficul HTTPS la un dispozitiv de margine sau la o cutie de mijloc și apoi îl vor trimite în text în spatele firewallului sau îl vor cripta și o vor trimite pe drum. Când nu criptați traficul, se numește Terminare SSL. Când re-criptați, acesta este numit “SSL”.

Ce este descărcarea SSL?

Descărcarea SSL este o altă practică a întreprinderii. La scară, efectuarea de mii de strângeri de mână și apoi criptarea și decriptarea tuturor datelor care pot impozita resursele unei rețele. Așadar, o mulțime de rețele mai mari vor descărca funcțiile SSL pe un alt dispozitiv, astfel încât serverul de aplicații să se poată concentra asupra sarcinilor sale principale. Aceasta este uneori denumită echilibrare a sarcinii.

De ce CA mi-a trimis un certificat intermediar?

Amintiți-vă mai devreme când am discutat despre programele root?

Foarte OS are un magazin root pe care îl folosește pentru a face judecăți de încredere PKI. Dar CA nu emite certificate de utilizator final din aceste rădăcini, de teamă de ceea ce s-ar întâmpla dacă cineva ar trebui revocat. În schimb, ele formează rădăcini intermediare și le eliberează. Problema este că rădăcinile intermediare nu se află în depozitul de încredere al unui sistem.

Așadar, dacă site-ul web nu prezintă certificatul intermediar împreună cu certificatul SSL / TLS din foi, multe browsere nu vor putea finaliza lanțul de certificate și vor emite un avertisment. Unele browsere au certificate intermediare în memoria cache, dar încă se consideră cea mai bună practică instalarea oricărui intermediar împreună cu certificatul dvs. de frunze.

Ce documentație am nevoie pentru un certificat SSL de validare extinsă?

În cele mai multe cazuri, Autoritatea de certificare care efectuează validarea extinsă va încerca mai întâi să acceseze informațiile prin resurse disponibile „public”.

Cu toate acestea, în unele locații, acest lucru ar putea să nu fie posibil. Cu toate acestea, există câteva lucruri care vă pot ajuta în accelerarea validării. În timp ce numărul de verificări de validare pe care îl poate satisface o scrisoare de opinie profesională a fost redus recent, având un avocat sau un contabil în semn de bună poziție, încă se poate ajuta considerabil.

În plus, puteți furniza o acreditare de afaceri emisă de guvern sau un document „Dovada dreptului” care oferă organizației dvs. dreptul de a face afaceri sub numele enumerat. Câteva exemple din aceste documente sunt:

  • Actul constitutiv
  • Certificate de formare
  • Licențe de afaceri / vânzător / comerciant
  • Documente charter
  • Acorduri de parteneriat
  • Înregistrarea comerțului sau a numelui presupus
  • Registro Mercantil

În încheiere

Sper că asta vă oferă o idee despre SSL / TLS. Dacă sunteți interesat să aflați mai multe, aș recomanda luând acest curs online.

Această postare a fost contribuită de Patrick Nohe, editor al Hashed Out de magazinul SSL, un blog care acoperă știri și tendințe în domeniul cibersecurității.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map