Pravilna konfiguracija TLS in HTTPS

Na kratko: Trdna konfiguracija TLS za spletne strežnike ponuja samo TLS 1.2 in TLS 1.3, uporablja šifrirne pakete s forward secrecy in overjenim šifriranjem (AES-GCM, ChaCha20-Poly1305) ter potrdilo s ključem ECDSA ali dovolj dolgim ključem RSA, ki se samodejno podaljšuje. Usmeritev dajeta smernica TR-02102-2 urada BSI (nemški zvezni urad za informacijsko varnost) in priporočila Server-Side TLS pri TLSRef. Rezultat preverite od zunaj in ne pozabite povezav, ki jih vzpostavi sam PHP.

Zakaj stare nastavitve TLS tako dolgo preživijo

Ključavnica v brskalniku je tam, torej velja šifriranje za opravljeno. Tako razmišljajo mnogi upravljavci, zato konfiguracija TLS pogosto ostane leta nespremenjena. Izvira iz časa postavitve strežnika, iz kopirane predloge ali iz privzetih vrednosti nadzorne plošče.

Težava: priporočila se spreminjajo. Različice protokolov se nadomeščajo, postopki veljajo za šibke, pridejo novi postopki izmenjave ključev. BSI je TR-02102 nazadnje objavil v različici 2026-01 z dne 27. 1. 2026 in v njej že opozarja na hibridne postkvantne postopke za TLS 1.3. Kdor svojih nastavitev že leta ni pogledal, z veliko verjetnostjo ni več na aktualnem stanju.

Kdor po PHP2Shell tako ali tako preverja strežnike, lahko konfiguracijo TLS pogleda v istem koraku. Ranljivosti PHP ne zapre, a sodi v vsako skrbno utrjevanje.

Na kaj se opira dobra konfiguracija TLS za spletne strežnike

Dva vira sta za upravljavce v Nemčiji posebej uporabna. BSI TR-02102 ocenjuje kriptografske postopke; 2. del obravnava TLS. Namenjen je predvsem razvijalcem in načrtovalcem ter je za organe in regulirana področja pogosto merilo. Priporočila Server-Side TLS, nekoč vzdrževana v wikiju Mozille, se danes nadaljujejo pri TLSRef in dajejo konkretne profile, ki jih je mogoče kopirati.

TLSRef v različici 6.0 ločuje dva profila:

Za javne spletne strani je Intermediate običajno izhodišče. Profil izključuje zelo stare naprave, a pokriva aktualne brskalnike in operacijske sisteme. Hibridna skupina X25519MLKEM768 zahteva sodobno knjižnico TLS. Preverite, ali jo vaša različica OpenSSL pozna, preden jo vpišete.

Nginx in Apache: varno izhodišče

Naslednja primera uvajata profil Intermediate. Poti so nadomestni znaki, seznam šifrirnih paketov velja za TLS 1.2; TLS 1.3 prinaša lastne, varne privzete postopke.

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

Drugi blok server nešifrirane klice trajno preusmeri na HTTPS. Preusmeritev naj kaže neposredno na končni naslov in naj ne teče prek več vmesnih postaj. Nato preverite tudi vložena sredstva: slike, skripte ali pisave, ki se še nalagajo prek HTTP, v brskalniku sprožijo opozorila ali so blokirane.

Nastavitev, da vrstni red izbere odjemalec, ustreza priporočilu TLSRef: vsi ponujeni postopki veljajo za varne, naprave brez pospeševanja AES pa tako lahko dajo prednost ChaCha20. Po vsaki spremembi konfiguracijo preizkusite (nginx -t oziroma apachectl configtest) in storitev znova naložite. Ustrezno glavo HSTS in druge napotke za brskalnike opisuje vodnik Varnostne glave za spletne strani.

Potrdila: ključ, veriga, podaljševanje

Velik del težav s TLS v praksi nima nič skupnega s šifrirnimi paketi, ampak s potrdili. Tipične napake so nepopolna veriga z manjkajočim vmesnim potrdilom, potekla potrdila na stranskih domenah in zasebni ključi s preširokimi pravicami datotek.

Pomagajo tri pravila:

1. Podaljšujte samodejno in podaljševanje nadzorujte. Kratke veljavnosti, kot jih priporoča TLSRef, so izvedljive samo z avtomatizacijo.
2. Zaščitite zasebne ključe: berljivi samo za root in proces spletnega strežnika, nikoli v webrootu, nikoli v repozitoriju.
3. Zajemite vsa imena: glavno domeno, www, poddomene za trgovino, staging, spletni vmesnik za pošto in nadzorne plošče.

Kdor potrdila uporablja na več mestih, na primer na CDN, load balancerju in izvornem strežniku, naj vodi pregled: katero potrdilo je kje nameščeno, kdo ga podaljšuje in kdaj poteče. Brez tega pregleda se poteklo potrdilo pogosto opazi šele, ko se oglasijo stranke.

Tako konfiguracijo preverite od zunaj

Naslednji ukazi so zgolj preverjanja in ničesar ne spreminjajo. Ime gostitelja zamenjajte z lastnim:

# TLS 1.3 in TLS 1.2 morata delovati
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 mora spodleteti
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Veljavnost in imetnik dostavljenega potrdila
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Neuspeh pri preizkusu TLS 1.1 je lahko tudi posledica tega, da vaša lokalna različica OpenSSL starega protokola sploh več ne ponuja. Za popolno poročilo o vseh ponujenih postopkih je primeren specializiran skener TLS. Pri tem preverite vsako poddomeno posebej, ker pogosto tečejo z lastnimi nastavitvami.

Pozabljeno: TLS tam, kjer je PHP sam odjemalec

Aplikacije PHP same vzpostavljajo številne povezave: k ponudnikom plačil, dobaviteljem dostave, vmesnikom, poštnim strežnikom in bazam podatkov. Tu najpogostejša napaka ni šibka nastavitev, ampak izklopljeno preverjanje potrdila, pogosto kot hitra rešitev težave pri razvoju.

<?php
// Varno: potrdilo in ime gostitelja se preverita (ohranite privzeto vedenje)
$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);

V kodi poiščite CURLOPT_SSL_VERIFYPEER z vrednostjo false in verify_peer v kontekstih tokov. Vsaka najdba za to povezavo zaščito TLS praktično odpravi. Kjer storitve ležijo za CDN, naj tudi odsek med CDN in izvornim strežnikom uporablja veljavno, preverjeno potrdilo. Nadaljnje nastavitve spletnega strežnika za okolja PHP najdete v prispevku Varna konfiguracija Nginx za PHP, merila za celotno utrjevanje pa v Primerjalnih testih CIS in modulih BSI.

Kako konkretno pomaga PHP SOS?

• Zajamemo vsa imena gostiteljev in storitve s TLS, vključno z nadzornimi ploščami, stagingom in spletnimi vmesniki za pošto.
• Nastavitve primerjamo s TR-02102 in ustreznim profilom TLSRef ter dokumentiramo zavestna odstopanja.
• Potrdila preusmerimo na samodejno podaljševanje z nadzorom.
• V aplikacijski kodi iščemo izklopljena preverjanja potrdil in pokažemo popravek.

TLS je sestavni del našega utrjevanja strežnikov PHP; povezavo z aktualnim stanjem pojasnjuje Kaj je PHP2Shell?.

Pogosta vprašanja

Viri

• BSI TR-02102: kriptografski postopki, 2. del TLS
• TLSRef: Server-Side TLS Guidelines
• Dokumentacija Nginx
• Apache HTTP Server: dokumentacija