Configurarea corectă a TLS și HTTPS

Pe scurt: O configurare TLS solidă pentru servere web oferă doar TLS 1.2 și TLS 1.3, folosește cipher suites cu Forward Secrecy și criptare autentificată (AES-GCM, ChaCha20-Poly1305) și un certificat cu cheie ECDSA sau RSA suficient de lungă, care se reînnoiește automat. Orientare oferă directiva BSI TR-02102-2 (BSI, Oficiul Federal German pentru Securitatea Informațiilor) și recomandările Server-Side TLS de la TLSRef. Verificați rezultatul din exterior și nu uitați conexiunile pe care le inițiază PHP însuși.

De ce supraviețuiesc atât de mult setările TLS vechi

Lăcătul din browser este acolo, deci criptarea se consideră rezolvată. Așa gândesc mulți operatori și de aceea configurarea TLS rămâne adesea neschimbată ani de zile. Ea provine atunci din perioada instalării serverului, dintr-un șablon copiat sau din valorile implicite ale unui panou.

Problema: recomandările se schimbă. Versiunile de protocol sunt înlocuite, unele proceduri sunt considerate slabe, apar noi proceduri de schimb de chei. BSI a publicat ultima dată TR-02102 în versiunea 2026-01 din 27.01.2026 și face deja trimitere acolo la procedurile hibride post-cuantice pentru TLS 1.3. Cine nu și-a mai privit setările de ani de zile nu mai este, cu probabilitate mare, la zi.

Cine oricum verifică acum serverele după PHP2Shell poate privi configurarea TLS în aceeași trecere. Ea nu închide vulnerabilitatea PHP, dar aparține oricărei întăriri corecte.

După ce se orientează o configurare TLS bună pentru servere web

Două surse sunt deosebit de utile pentru operatorii din Europa. BSI TR-02102 evaluează procedurile criptografice; partea 2 tratează TLS. Se adresează mai ales dezvoltatorilor și planificatorilor și este adesea reperul pentru autorități și domenii reglementate. Recomandările Server-Side TLS, întreținute înainte în wiki-ul Mozilla, sunt continuate astăzi la TLSRef și oferă profiluri concrete, care pot fi copiate.

TLSRef distinge în versiunea 6.0 două profiluri:

Pentru site-urile publice, Intermediate este punctul de plecare obișnuit. Profilul exclude dispozitivele foarte vechi, dar acoperă browserele și sistemele de operare actuale. Grupul hibrid X25519MLKEM768 presupune o bibliotecă TLS actuală. Verificați dacă versiunea dumneavoastră de OpenSSL o cunoaște, înainte de a o înscrie.

Nginx și Apache: un punct de plecare sigur

Exemplele următoare implementează profilul Intermediate. Căile sunt substituenți, lista de cipher suites se aplică pentru TLS 1.2; TLS 1.3 aduce proceduri implicite proprii, sigure.

server {
    listen 443 ssl;
    server_name www.example.de;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    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;
}

server {
    listen 80;
    server_name www.example.de;
    return 301 https://$host$request_uri;
}

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

Al doilea bloc server redirecționează permanent apelurile necriptate către HTTPS. Redirecționarea ar trebui să indice direct adresa finală și să nu treacă prin mai multe etape intermediare. Verificați după aceea și resursele încorporate: imaginile, scripturile sau fonturile încă încărcate prin HTTP declanșează avertismente în browser sau sunt blocate.

Setarea prin care clientul alege ordinea corespunde recomandării TLSRef: toate procedurile oferite sunt considerate sigure, iar dispozitivele fără accelerare AES pot astfel prefera ChaCha20. După fiecare modificare, testați configurarea (nginx -t, respectiv apachectl configtest) și reîncărcați serviciul. Antetul HSTS potrivit și alte reguli pentru browser le descrie ghidul Antete de securitate pentru site-uri web.

Certificate: cheie, lanț, reînnoire

O mare parte din problemele TLS din practică nu au legătură cu cipher suites, ci cu certificatele. Greșeli tipice sunt un lanț incomplet, în care lipsește certificatul intermediar, certificate expirate pe domenii secundare și chei private cu drepturi de fișier prea largi.

Trei reguli ajută:

1. Reînnoiți automat și monitorizați reînnoirea. Duratele scurte, așa cum le recomandă TLSRef, sunt practicabile doar cu automatizare.
2. Protejați cheile private: lizibile doar pentru root și procesul serverului web, niciodată în webroot, niciodată într-un depozit (repository).
3. Inventariați toate numele: domeniul principal, www, subdomeniile pentru magazin, staging, interfața web de e-mail și panouri.

Cine folosește certificate în mai multe locuri, de exemplu pe CDN, load balancer și server de origine, ar trebui să țină o evidență: ce certificat este instalat unde, cine îl reînnoiește și când expiră. Dacă lipsește această evidență, un certificat expirat devine adesea vizibil abia când se anunță clienții.

Cum vă verificați configurarea din exterior

Comenzile următoare sunt simple verificări și nu modifică nimic. Înlocuiți numele de host cu al dumneavoastră:

# TLS 1.3 și TLS 1.2 ar trebui să funcționeze
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# TLS 1.1 sollte scheitern
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Valabilitatea și titularul certificatului livrat
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Un eșec la testul TLS 1.1 poate fi cauzat și de faptul că versiunea dumneavoastră locală de OpenSSL nu mai oferă deloc vechiul protocol. Pentru un raport complet despre toate procedurile oferite se potrivește un scanner TLS specializat. Verificați fiecare subdomeniu în parte, deoarece ele rulează adesea cu setări proprii.

Uitat: TLS acolo unde PHP însuși este client

Aplicațiile PHP inițiază singure multe conexiuni: către furnizori de plăți, servicii de expediere, interfețe, servere de e-mail și baze de date. Aici, cea mai frecventă greșeală nu este o setare slabă, ci o verificare dezactivată a certificatului, adesea ca soluție rapidă pentru o problemă din dezvoltare.

<?php
// Sigur: certificatul și numele de host sunt verificate (păstrați comportamentul implicit)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
    CURLOPT_TIMEOUT        => 10,
]);
$antwort = curl_exec($ch);

Căutați în cod CURLOPT_SSL_VERIFYPEER cu false și verify_peer în contexte de stream. Fiecare apariție anulează practic protecția TLS pentru acea conexiune. Acolo unde serviciile se află în spatele unui CDN, și segmentul dintre CDN și serverul de origine ar trebui să folosească un certificat valid, verificat. Alte setări de server web pentru configurații PHP găsiți la Configurarea sigură a Nginx pentru PHP, repere pentru întreaga întărire la Benchmark-uri CIS și module BSI.

Cum ajută PHP SOS concret?

• Inventariem toate numele de host și serviciile cu TLS, inclusiv panouri, staging și interfețe web de e-mail.
• Comparăm setările cu TR-02102 și cu profilul TLSRef potrivit și documentăm abaterile deliberate.
• Trecem certificatele la reînnoire automată cu monitorizare.
• Căutăm în codul aplicației verificările dezactivate ale certificatelor și arătăm corecția.

TLS este un element al întăririi serverului pentru servere web PHP oferite de noi; legătura cu situația actuală o explică Ce este PHP2Shell?.

Întrebări frecvente

Surse

• BSI TR-02102: Proceduri criptografice, partea 2 TLS
• TLSRef: Server-Side TLS Guidelines
• Documentația Nginx
• Apache HTTP Server: documentație