Transport Layer Security (TLS) criptează datele trimise prin Internet pentru a se asigura că ascultătorii și hackerii nu pot vedea ceea ce transmiteți, ceea ce este deosebit de util pentru informații private și sensibile, cum ar fi parolele, numerele cardurilor de credit și corespondența personală. Această pagină explică ce este TLS, cum funcționează și de ce ar trebui să-l implementați.

internet

Ce este TLS?

TLS este un protocol criptografic care oferă securitate de la un capăt la altul a datelor trimise între aplicații prin Internet. Este cunoscut în mare parte utilizatorilor prin utilizarea sa în navigarea web securizată și, în special, pictograma lacăt care apare în browserele web atunci când este stabilită o sesiune sigură. Cu toate acestea, acesta poate și într-adevăr ar trebui să fie folosit și pentru alte aplicații, cum ar fi e-mail, transferuri de fișiere, video/audioconferințe, mesagerie instantanee și voce peste IP, precum și servicii de internet precum DNS și NTP.

TLS a evoluat din Secure Socket Layers (SSL), care a fost inițial dezvoltat de Netscape Communications Corporation în 1994 pentru securizarea sesiunilor web. SSL 1.0 nu a fost niciodată lansat public, în timp ce SSL 2.0 a fost rapid înlocuit de SSL 3.0 pe care se bazează TLS.

TLS a fost specificat pentru prima dată în RFC 2246 în 1999 ca aplicații de protocol independente și, deși nu a fost direct interoperabil cu SSL 3.0, a oferit un mod de rezervă dacă este necesar. Cu toate acestea, SSL 3.0 este acum considerat nesigur și a fost depreciat de RFC 7568 în iunie 2015, cu recomandarea ca TLS 1.2 să fie utilizat. TLS 1.3 este, de asemenea, în curs de dezvoltare (începând cu decembrie 2015) și va renunța la suport pentru algoritmi mai puțin siguri.

Trebuie remarcat faptul că TLS nu securizează datele pe sistemele finale. Pur și simplu asigură livrarea sigură a datelor pe Internet, evitând posibilele ascultări și/sau modificări ale conținutului.

TLS este implementat în mod normal pe partea de sus a TCP pentru a cripta protocoalele Application Layer, cum ar fi HTTP, FTP, SMTP și IMAP, deși poate fi implementat și pe UDP, DCCP și SCTP (de exemplu, pentru utilizări de aplicații bazate pe VPN și SIP) . Aceasta este cunoscută sub numele de Datagram Transport Layer Security (DTLS) și este specificată în RFC-urile 6347, 5238 și 6083.

De ce ar trebui să-mi pese de TLS?

Datele au fost transmise în mod istoric necriptate pe Internet, iar acolo unde a fost utilizată criptarea, acestea au fost utilizate în mod fragmentar pentru informații sensibile, cum ar fi parolele sau detaliile de plată. În timp ce în 1996 (prin RFC 1984) s-a recunoscut că creșterea internetului ar necesita protejarea datelor private, a devenit din ce în ce mai evident în perioada intermediară că capacitățile ascultătorilor și ale atacatorilor sunt mai mari și mai răspândite decât se credea anterior . Prin urmare, IAB a lansat o declarație în noiembrie 2014 prin care a solicitat proiectanților, dezvoltatorilor și operatorilor de protocol să facă criptarea normă pentru traficul pe Internet, ceea ce înseamnă, în esență, confidențialitatea acestuia în mod implicit.

Fără TLS, informațiile sensibile, cum ar fi datele de conectare, detaliile cardului de credit și detaliile personale pot fi ușor culese de alții, dar și obiceiurile de navigare, corespondența prin e-mail, chat-urile online și apelurile de conferință pot fi monitorizate. Permițând aplicațiilor client și server să accepte TLS, se asigură că datele transmise între ele sunt criptate cu algoritmi siguri și nu pot fi vizualizate de terți.

Versiunile recente ale tuturor browserelor web importante acceptă în prezent TLS și este din ce în ce mai frecvent ca serverele web să accepte TLS în mod implicit. Cu toate acestea, utilizarea TLS pentru e-mail și anumite alte aplicații nu este încă adesea obligatorie și, spre deosebire de browserele web care oferă indicii vizuale, nu este întotdeauna evident pentru utilizatori dacă conexiunile lor sunt criptate.

Prin urmare, se recomandă ca toți clienții și serverele să insiste asupra utilizării obligatorii a TLS în comunicațiile lor și, de preferință, cea mai recentă versiune a TLS 1.2. Pentru o securitate completă, este necesar să o utilizați împreună cu o infrastructură de cheie publică X.509 (PKI) de încredere publică și, de preferință, DNSSEC, de asemenea, pentru a autentifica că un sistem la care se face o conexiune este într-adevăr ceea ce pretinde că fi.

Cum funcționează TLS?

TLS utilizează o combinație de criptografie simetrică și asimetrică, deoarece aceasta oferă un compromis bun între performanță și securitate atunci când transmiteți datele în siguranță.

Cu criptografia simetrică, datele sunt criptate și decriptate cu o cheie secretă cunoscută atât de expeditor, cât și de destinatar; de obicei 128, dar preferabil 256 de biți în lungime (ceva mai mic de 80 de biți este acum considerat nesigur). Criptografia simetrică este eficientă în ceea ce privește calculul, dar având o cheie secretă comună înseamnă că trebuie să fie partajată într-un mod sigur.

Criptografia asimetrică folosește perechi de chei - o cheie publică și o cheie privată. Cheia publică este legată matematic de cheia privată, dar având în vedere o lungime suficientă a cheii, este impracticabil din punct de vedere al calculului să derivăm cheia privată din cheia publică. Aceasta permite cheii publice a destinatarului să fie utilizate de către expeditor pentru a cripta datele pe care doresc să le trimită, dar aceste date pot fi decriptate numai cu cheia privată a destinatarului.

Avantajul criptografiei asimetrice este că procesul de partajare a cheilor de criptare nu trebuie să fie sigur, dar relația matematică dintre cheile publice și private înseamnă că sunt necesare dimensiuni de cheie mult mai mari. Lungimea minimă recomandată a cheii este de 1024 biți, cu 2048 biți preferați, dar aceasta este de până la o mie de ori mai intensă din punct de vedere computerizat decât tastele simetrice cu rezistență echivalentă (de exemplu, o cheie asimetrică de 2048 biți este aproximativ echivalentă cu o cheie simetrică de 112 biți) și face ca criptarea asimetrică să fie prea lentă pentru multe scopuri.

Din acest motiv, TLS folosește criptografie asimetrică pentru a genera și a schimba în siguranță o cheie de sesiune. Cheia de sesiune este apoi utilizată pentru criptarea datelor transmise de o parte și pentru decriptarea datelor primite la celălalt capăt. Odată ce sesiunea sa încheiat, cheia sesiunii este aruncată.

Se pot utiliza o varietate de metode diferite de generare și schimb de chei, inclusiv RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDH) și Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). DHE și ECDHE oferă, de asemenea, secretul înainte, prin care o cheie de sesiune nu va fi compromisă dacă una dintre cheile private este obținută în viitor, deși s-a postulat o generare slabă de numere aleatorii și/sau utilizarea unei game limitate de numere prime pentru a permite crăparea de chei DH chiar de 1024 biți, având în vedere resurse de calcul la nivel de stat. Cu toate acestea, acestea pot fi considerate mai degrabă implementare decât probleme de protocol și există instrumente disponibile pentru a testa suite de cifrare mai slabe.

Cu TLS, de asemenea, este de dorit ca un client care se conectează la un server să poată valida calitatea de proprietar al cheii publice a serverului. Acest lucru se realizează în mod normal utilizând un certificat digital X.509 emis de un terț de încredere cunoscut sub numele de Autoritate de certificare (CA) care afirmă autenticitatea cheii publice. În unele cazuri, un server poate utiliza un certificat autosemnat care trebuie să fie în mod explicit de încredere de către client (browserele ar trebui să afișeze un avertisment atunci când se întâlnește un certificat de încredere), dar acest lucru poate fi acceptabil în rețelele private și/sau în cazul în care certificatul securizat distribuția este posibilă. Totuși, este foarte recomandat să utilizați certificate emise de autorități de încredere publice.

Ce este un CA?

O autoritate de certificare (CA) este o entitate care emite certificate digitale conforme cu standardul X.509 al ITU-T pentru infrastructuri cu cheie publică (PKIs). Certificatele digitale certifică cheia publică a proprietarului certificatului (cunoscut sub numele de subiect) și că proprietarul controlează domeniul fiind securizat prin certificat. Prin urmare, o CA acționează ca o terță parte de încredere care oferă clienților (cunoscuți ca părți dependente) asigurarea că se conectează la un server operat de o entitate validată.

Certificatele de entitate finală sunt ele însele validate printr-un lanț de încredere provenind dintr-un certificat rădăcină, cunoscut și sub denumirea de ancoră de încredere. Cu criptografia asimetrică este posibil să se utilizeze cheia privată a certificatului rădăcină pentru a semna alte certificate, care pot fi apoi validate folosind cheia publică a certificatului rădăcină și, prin urmare, moștenesc încrederea CA emitent. În practică, certificatele entității finale sunt de obicei semnate de unul sau mai multe certificate intermediare (uneori cunoscute sub numele de subordonate sau sub-CA), deoarece protejează certificatul rădăcină în cazul în care un certificat de entitate finală este emis sau compromis incorect.

Încrederea certificatului rădăcină este stabilită în mod normal prin distribuirea fizică a certificatelor rădăcină în sistemele de operare sau browsere. Principalele programe de certificare sunt rulate de Microsoft (Windows și Windows Phone), Apple (OSX și iOS) și Mozilla (Firefox și Linux) și necesită CA pentru a se conforma cerințelor tehnice stricte și pentru a completa un WebTrust, ETSI EN 319 411-3 TS 102 042) sau ISO 21188: 2006 audit pentru a fi inclus în distribuțiile lor. WebTrust este un program dezvoltat de Institutul American al Contabililor Publici Autorizați și Institutul Canadian al Expertilor Contabili, ETSI este Institutul European de Standarde în Telecomunicații, în timp ce ISO este Organizația Internațională de Standardizare.

Se spune că certificatele de bază distribuite cu sistemele de operare și browserele majore sunt de încredere publică sau globală, iar cerințele tehnice și de audit înseamnă, în esență, că autoritățile emitente sunt corporații multinaționale sau guverne. În prezent, există în jur de cincizeci de CA de încredere publică, deși majoritatea/toate au mai mult de un certificat rădăcină și majoritatea sunt, de asemenea, membri ai CA/Browser Forum, care dezvoltă linii directoare din industrie pentru emiterea și gestionarea certificatelor.

Cu toate acestea, este de asemenea posibil să se creeze CA private și să se stabilească încrederea prin distribuirea și instalarea în siguranță a certificatelor rădăcină pe sistemele client. Exemplele includ CA RPKI operate de registrele regionale de internet (AfriNIC, APNIC, ARIN, LACNIC și RIPE NCC) care emit certificate către registrele de internet locale care atestă adresele IP și numerele AS pe care le dețin; precum și International Grid Trust Federation (IGTF), care oferă o ancoră de încredere pentru emiterea certificatelor de server și client utilizate de mașini în calculele științifice distribuite. În aceste cazuri, certificatele rădăcină pot fi descărcate și instalate în siguranță de pe site-uri folosind un certificat emis de o autoritate de încredere publică.

Un punct slab al sistemului PKI X.509 este acela că părțile terțe (CA) sunt capabile să emită certificate pentru orice domeniu, indiferent dacă entitatea solicitantă îl deține sau nu sau îl controlează. Validarea se efectuează de obicei prin validarea domeniului - și anume trimiterea unui e-mail cu un link de autentificare la o adresă cunoscută ca fiind responsabilă administrativ pentru domeniu. Aceasta este de obicei una dintre adresele de contact standard, cum ar fi „[e-mail protected]” sau contactul tehnic listat într-o bază de date WHOIS, dar aceasta se lasă deschisă atacurilor om-în-mijloc asupra protocoalelor DNS sau BGP, sau mai simplu, utilizatorii care înregistrează adrese administrative pe domenii care nu au fost rezervate. Poate mai important, certificatele validate de domeniu (DV) nu afirmă că un domeniu are vreo relație cu o entitate juridică, chiar dacă un domeniu poate părea să aibă una.

Din acest motiv, autoritățile competente încurajează din ce în ce mai mult utilizarea certificatelor de validare a organizației (OV) și de validare extinsă (EV). Cu certificatele OV, entitatea solicitantă este supusă verificărilor suplimentare, cum ar fi confirmarea numelui organizației, a adresei și a numărului de telefon, utilizând baze de date publice. Cu certificatele EV, există verificări suplimentare privind stabilirea legală, locația fizică și identitatea persoanelor care pretind să acționeze în numele entității solicitante. Browserele afișează în mod obișnuit numele organizației validate în verde atunci când se întâlnește un certificat EV valid, deși, din păcate, nu există o modalitate ușoară de a distinge un OV de un certificat DV.

Desigur, acest lucru nu împiedică încă CA să emită în mod accidental sau în mod fraudulos certificate incorecte și au existat, de asemenea, incidente de încălcări ale securității în care CA au fost păcălite să emită certificate false. În ciuda înăspririi substanțiale a procedurilor de securitate ca urmare a mai multor incidente de profil înalt, sistemul rămâne bazat pe încrederea terților, ceea ce a dus la dezvoltarea protocolului de autentificare a entităților numite (DANE) bazat pe DNS, așa cum se specifică în RFC-urile 6698, 7671, 7672 și 7673.

Cu DANE, un administrator de domeniu își poate certifica cheile publice stocându-le în DNS sau specificând alternativ ce certificate ar trebui acceptate de un client. Acest lucru necesită utilizarea DNSSEC, care afirmă criptografic validitatea înregistrărilor DNS, deși DNSSEC nu are încă implementare pe scară largă, iar browserele majore necesită în prezent instalarea unui supliment pentru a sprijini DANE. Mai mult, DNSSEC și DANE vor necesita în continuare validarea deținătorilor de domenii care probabil vor trebui întreprinse de registrele de domenii și/sau registratori în loc de CA.