Migrarea la TLS 1.3 și alegerea cifrurilor

Ce s-a schimbat în TLS 1.3

TLS 1.3 (RFC 8446, 2018) nu este o revizuire minoră a versiunii 1.2. A eliminat complet funcțiile care au produs vulnerabilități ani la rând: schimbul de chei RSA fără forward secrecy, Diffie-Hellman static, cifrurile în mod CBC, RC4, compresia și renegocierea. Fiecare conexiune TLS 1.3 folosește un schimb de chei efemer, adică o cheie nouă, valabilă doar pentru sesiunea respectivă. Consecința practică este simplă: o cheie de server furată nu mai poate decripta traficul înregistrat anterior.

Și handshake-ul a devenit vizibil mai rapid. O conexiune nouă are nevoie de un singur dus-întors înainte ca datele aplicației să înceapă să circule, față de două în TLS 1.2, iar o parte mult mai mare din handshake este criptată, inclusiv certificatul serverului. Modul opțional 0-RTT le permite clienților care revin să trimită date chiar din primul mesaj; prețul este că acele date timpurii pot fi reluate de un atacator.

Ce versiuni de protocol permiteți

RFC 8996 a retras oficial din uz TLS 1.0 și 1.1 în 2021, iar browserele mari scoseseră deja suportul pentru ele cu ceva timp înainte. Dacă le lăsați active, ajutați doar câțiva clienți foarte vechi, în schimb expuneți pe toată lumea la slăbiciuni legate de coborârea versiunii și picați scanările de conformitate. Pentru site-urile publice, baza practică este, prin urmare, TLS 1.2 împreună cu TLS 1.3.

O configurație numai cu TLS 1.3, adică profilul pe care Mozilla îl numește modern, este o alegere rezonabilă pentru API-uri și servicii interne ale căror clienți îi controlați dumneavoastră. Site-urile publice păstrează de obicei și TLS 1.2, din cauza sistemelor de operare vechi, a dispozitivelor încorporate și a unor proxy-uri corporative. Diferența ține mai mult de accesibilitate decât de securitate: un TLS 1.2 limitat la suitele corecte rămâne sigur și astăzi. Verificarea TLS arată ce versiune a negociat efectiv o conexiune.

Alegerea suitelor de cifrare

TLS 1.3

TLS 1.3 definește un set mic de suite, iar cele activate în mod obișnuit sunt toate puternice. Majoritatea serverelor vin cu valori implicite rezonabile, așa că de regulă nu aveți nimic de configurat aici. Suita alege doar cifrul AEAD și funcția de dispersie; schimbul de chei și algoritmii de semnătură se negociază separat, independent de ea.

TLS 1.2

TLS 1.2 este locul în care configurarea contează cu adevărat. Permiteți doar suitele cu schimb de chei ECDHE, pentru forward secrecy, și cu cifruri AEAD, iar restul scoateți-le complet. RFC 9325 (BCP 195) adună recomandările actuale ale IETF și se potrivește cu ceea ce folosesc profilurile întreținute.

Ce înseamnă rezultatele scanerelor

Scanerele TLS raportează problemele cu numele unor atacuri vechi, ceea ce face greu de înțeles care dintre ele contează cu adevărat. Vestea bună este că cele mai multe dispar deodată, în momentul în care dezactivați TLS 1.0 și 1.1 și limitați TLS 1.2 la ECDHE cu cifruri AEAD. Tabelul de mai jos leagă rezultatele frecvente de schimbarea de configurație care le elimină.

Rezultatele despre anteturile HTTP, cum ar fi lipsa unui antet HSTS, apar adesea în același raport, însă ele se rezolvă în configurația de anteturi a serverului web, nu în setările TLS. Separarea celor două vă ajută să urmăriți ce schimbare a închis care problemă. Verificarea anteturilor HTTP le listează separat.

Reluarea sesiunii și performanța

Un handshake complet costă un dus-întors și ceva timp de procesor, așa că, ori de câte ori pot, clienții preferă să reia o sesiune anterioară. TLS 1.3 a înlocuit vechile mecanisme cu identificator de sesiune și cu tichete prin chei preîmpărtășite derivate dintr-o sesiune precedentă și, în mod implicit, combină totuși reluarea cu un schimb de chei proaspăt. Astfel, forward secrecy se păstrează și pentru sesiunile reluate.

În TLS 1.2, în schimb, tichetele de sesiune criptate cu o cheie de lungă durată slăbesc forward secrecy, pentru că oricine obține acea cheie poate decripta ulterior sesiunile înregistrate ale căror tichete le-a protejat. Din acest motiv, profilurile Mozilla dezactivează tichetele de sesiune TLS 1.2, cu excepția cazului în care cheile de tichet sunt rotite des. Un cache de sesiune partajat pe server vă oferă cea mai mare parte a câștigului de performanță, fără acest compromis.

HTTP/2 și HTTP/3 reduc și mai mult numărul de handshake-uri TLS, reutilizând o singură conexiune pentru multe cereri. HTTP/3 rulează peste QUIC, care integrează TLS 1.3 direct în transport; activarea lui nu vă schimbă certificatul, dar are nevoie de portul UDP 443 deschis. Dacă regulile de firewall permit doar TCP, clienții revin în tăcere la HTTP/2 peste TCP.

Exemple de configurare a serverului

Exemplele urmează profilul intermediate de la Mozilla, așa cum arăta el în momentul redactării. Fiindcă recomandările se schimbă în timp, generați varianta actuală pentru versiunile exacte ale serverului și bibliotecilor dumneavoastră cu Mozilla SSL Configuration Generator. După fiecare modificare, reîncărcați serverul și verificați rezultatul cu o scanare din exterior.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

example.com {
    tls {
        protocols tls1.2 tls1.3
    }
}

ssl_prefer_server_ciphers off lasă clientul să aleagă dintre suitele permise, iar aceasta este recomandarea actuală. Motivul este dublu: fiecare suită pe care o permiteți este oricum puternică, iar clientul știe mai bine decât serverul dacă are accelerare hardware pentru AES. Suitele TLS 1.3 se configurează printr-o setare separată în serverele bazate pe OpenSSL și rareori au nevoie de modificări.

În spatele unui CDN sau al unui echilibrator de sarcină, marginea rețelei este cea care termină TLS pentru vizitatori, așa că politica ei TLS este cea pe care o văd Verificarea TLS și browserele, nu cea a serverului dumneavoastră. Configurați acolo versiunea minimă și folosiți TLS și pe legătura dintre margine și serverul de origine.

Certificate și tipuri de chei

Păstrați cheile private doar pe serverele sau platformele de margine care termină TLS și faceți-le lizibile numai pentru contul de serviciu care are nevoie de ele. Când reemiteți un certificat după orice suspiciune de expunere, schimbați și cheia, nu doar certificatul. Un certificat reemis cu aceeași cheie lasă în uz exact materialul criptografic care s-ar putea să fi fost compromis.

Tipul de cheie al certificatului determină direct ce suite pot fi folosite. Certificatele ECDSA P-256 sunt mai mici și se verifică mai repede decât cele RSA; RSA 2048 rămâne în schimb acceptat practic peste tot. Multe servere pot servi ambele tipuri în paralel și pot alege unul pentru fiecare client, însă cu clienții de astăzi un singur certificat ECDSA sau RSA este perfect suficient.

• Serviți lanțul complet: certificatul frunză plus certificatele intermediare, fără rădăcină.
• Automatizați reînnoirea; durata de viață a certificatelor de încredere publică scade continuu, conform regulilor CA/Browser Forum.
• Monitorizați expirarea independent de procesul de reînnoire, de exemplu cu Verificarea TLS într-o verificare programată sau prin API-ul XGM.
• Adăugați HTTP Strict Transport Security după ce HTTPS funcționează peste tot; ghidul HSTS explică cum se face trecerea.

Testarea configurației

Testați întotdeauna din afara rețelei dumneavoastră, pentru că proxy-urile și rețelele CDN schimbă ceea ce văd vizitatorii. Verificați pe rând că TLS 1.3 și 1.2 se conectează, că 1.0 și 1.1 sunt refuzate și ce suite oferă efectiv serverul. Comenzile de mai jos folosesc OpenSSL și nmap, două unelte disponibile aproape peste tot.

# TLS 1.3 should connect
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'

# TLS 1.1 should fail (depending on your OpenSSL build, the client may refuse locally)
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# list offered protocol versions and suites
nmap --script ssl-enum-ciphers -p 443 example.com

Automatizați scanarea. Rularea acelorași verificări săptămânal, sau după fiecare schimbare de infrastructură, prinde din timp regresii precum un echilibrator de sarcină nou lăsat pe setările implicite sau un certificat reînnoit cu un lanț incomplet. Păstrați rezultatele, ca să puteți vedea nu doar că starea actuală este greșită, ci și momentul exact în care lucrurile s-au stricat.

Dacă o verificare eșuează doar din anumite locații, bănuiți un CDN sau o configurație anycast în care locațiile de margine rulează configurații diferite, ori o schimbare DNS care nu a ajuns încă la toate resolverele. Testarea, pe rând, a adreselor IP din spatele numelui de gazdă, cu --resolve în curl sau cu -connect către un IP anume în OpenSSL, restrânge foarte repede problema.

Nu uitați celelalte puncte finale TLS: serverele de e-mail pe porturile 25, 465 și 587, IMAP pe 993 și panourile de administrare pe porturi nestandard. Acolo rulează adesea alt software, cu valori implicite mai vechi. Scanerul de porturi arată ce porturi sunt accesibile din internet.

Compatibilitate și punere în producție

Dezactivarea TLS 1.0 și 1.1 afectează doar clienții care nu pot vorbi TLS 1.2, adică astăzi sisteme de operare foarte vechi, dispozitive încorporate neactualizate și câteva integrări moștenite. Dacă aveți jurnale de server cu versiunea de protocol, uitați-vă câte cereri mai folosesc versiunile vechi înainte de a le opri. Multe echipe constată că numărul este practic zero, în afara scanerelor automate.

1. Înregistrați timp de o săptămână protocolul și cifrul negociat, dacă serverul dumneavoastră permite asta.
2. Identificați clienții vechi rămași; contactați din timp responsabilii integrărilor importante.
3. Dezactivați TLS 1.0 și 1.1 și suitele TLS 1.2 slabe într-o singură modificare, apoi scanați.
4. Urmăriți câteva zile ratele de eroare și solicitările primite la suport.
5. Reluați anual comparația configurației cu profilul Mozilla actual.

Întrebări frecvente

Surse

• RFC 8446: Protocolul Transport Layer Security (TLS) versiunea 1.3
• RFC 8996: Retragerea din uz a TLS 1.0 și TLS 1.1
• RFC 9325: Recomandări pentru utilizarea sigură a TLS și DTLS (BCP 195)
• RFC 7568: Retragerea din uz a Secure Sockets Layer versiunea 3.0
• Mozilla SSL Configuration Generator
• Wiki Mozilla: TLS pe partea de server