Ispravno konfigurirati TLS i HTTPS

Ukratko: Solidna TLS konfiguracija web-poslužitelja nudi samo TLS 1.2 i TLS 1.3, koristi cipher suites s Forward Secrecy i autentificiranim šifriranjem (AES-GCM, ChaCha20-Poly1305) te certifikat s ECDSA ključem ili dovoljno dugim RSA ključem koji se automatski produljuje. Orijentaciju daju smjernica BSI-ja TR-02102-2 (BSI je njemački Savezni ured za informacijsku sigurnost) i Server-Side-TLS preporuke iz TLSRef-a. Rezultat provjerite izvana i ne zaboravite veze koje PHP sam uspostavlja.

Zašto stare TLS postavke tako dugo opstaju

Lokot u pregledniku je tu, dakle šifriranje se smatra riješenim. Tako misle mnogi operateri i zato TLS konfiguracija često godinama ostaje nepromijenjena. Tada potječe iz vremena postavljanja poslužitelja, iz kopiranog predloška ili iz zadanih vrijednosti panela.

Problem: preporuke se mijenjaju. Verzije protokola se zamjenjuju, postupci se smatraju slabima, dodaju se novi postupci razmjene ključeva. BSI je TR-02102 zadnji put objavio u verziji 2026-01 od 27. 1. 2026. i u njoj već upućuje na hibridne postkvantne postupke za TLS 1.3. Tko godinama nije pogledao svoje postavke, s velikom vjerojatnošću više nije na aktualnom stanju.

Tko ionako upravo provjerava poslužitelje nakon PHP2Shella, TLS konfiguraciju može pogledati u istom koraku. Ona ne zatvara PHP ranjivost, ali pripada svakom urednom ojačavanju.

Na što se oslanja dobra TLS konfiguracija web-poslužitelja

Dva su izvora za operatere u Europi osobito korisna. BSI TR-02102 ocjenjuje kriptografske postupke; dio 2 obrađuje TLS. Namijenjen je ponajprije razvojnim inženjerima i planerima, a za tijela javne vlasti i regulirana područja često je mjerilo. Server-Side-TLS preporuke, nekad održavane na Mozilla wikiju, danas se nastavljaju pod TLSRef-om i daju konkretne profile koji se mogu kopirati.

TLSRef u verziji 6.0 razlikuje dva profila:

Za javne web-stranice Intermediate je uobičajeno polazište. Profil isključuje vrlo stare uređaje, ali pokriva aktualne preglednike i operacijske sustave. Hibridna grupa X25519MLKEM768 traži aktualnu TLS biblioteku. Provjerite poznaje li je Vaša verzija OpenSSL-a prije nego je upišete.

Nginx i Apache: siguran polazni položaj

Sljedeći primjeri provode Intermediate profil. Putanje su rezervirana mjesta, a popis cipher suites vrijedi za TLS 1.2; TLS 1.3 donosi vlastite sigurne zadane postupke.

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 server blok trajno preusmjerava nešifrirane pozive na HTTPS. Preusmjeravanje bi trebalo upućivati izravno na konačnu adresu, a ne ići preko više usputnih postaja. Nakon toga provjerite i ugrađene resurse: slike, skripte ili fontovi koji se još učitavaju preko HTTP-a u pregledniku izazivaju upozorenja ili se blokiraju.

Postavka prema kojoj klijent bira redoslijed odgovara TLSRef preporuci: svi ponuđeni postupci smatraju se sigurnima, a uređaji bez AES ubrzanja tako mogu davati prednost ChaCha20. Nakon svake promjene testirajte konfiguraciju (nginx -t odnosno apachectl configtest) i ponovno učitajte uslugu. Odgovarajuće HSTS zaglavlje i druge preglednikove zadane postavke opisuje vodič Sigurnosna zaglavlja za web-stranice.

Certifikati: ključ, lanac, produljenje

Velik dio TLS problema u praksi nema veze s cipher suites, nego s certifikatima. Tipične su pogreške nepotpun lanac u kojem nedostaje međucertifikat, istekli certifikati na sporednim domenama i privatni ključevi sa preširokim pravima datoteka.

Pomažu tri pravila:

1. Produljivati automatski i nadzirati produljenje. Kratka trajanja, kakva preporučuje TLSRef, praktična su samo uz automatizaciju.
2. Zaštititi privatne ključeve: čitljivi samo za root i proces web-poslužitelja, nikad u webrootu, nikad u repozitoriju.
3. Obuhvatiti sva imena: glavnu domenu, www, poddomene za shop, staging, web-sučelje e-pošte i panele.

Tko certifikate koristi na više mjesta, primjerice na CDN-u, load balanceru i izvornom poslužitelju, trebao bi voditi pregled: koji je certifikat gdje instaliran, tko ga produljuje i kada istječe. Bez tog pregleda istekli certifikat često se uoči tek kad se jave kupci.

Kako provjeriti konfiguraciju izvana

Sljedeće naredbe su čiste provjere i ništa ne mijenjaju. Naziv hosta zamijenite svojim:

# TLS 1.3 i TLS 1.2 trebali bi raditi
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 treba propasti
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Trajanje i vlasnik isporučenog certifikata
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Neuspjeh pri TLS 1.1 testu može biti i zato što Vaša lokalna verzija OpenSSL-a stari protokol uopće više ne nudi. Za potpuno izvješće o svim ponuđenim postupcima prikladan je specijalizirani TLS skener. Pritom provjerite svaku poddomenu zasebno, jer često rade s vlastitim postavkama.

Zaboravljeno: TLS tamo gdje je PHP sam klijent

PHP aplikacije same uspostavljaju mnoge veze: prema pružateljima plaćanja, dostavnim službama, sučeljima, poslužiteljima e-pošte i bazama podataka. Ovdje najčešća pogreška nije slaba postavka, nego isključena provjera certifikata, često kao brzo rješenje problema u razvoju.

<?php
// Sigurno: certifikat i naziv hosta se provjeravaju (zadržati standardno ponašanje)
$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);

Potražite u kodu CURLOPT_SSL_VERIFYPEER s vrijednošću false i verify_peer u kontekstima streamova. Svako nalazište praktički ukida zaštitu TLS-a za tu vezu. Gdje usluge stoje iza CDN-a, i dionica između CDN-a i izvornog poslužitelja trebala bi koristiti valjan, provjeren certifikat. Dodatne postavke web-poslužitelja za PHP okruženja nalaze se u članku Sigurno konfigurirati Nginx za PHP, a mjerila za cjelokupno ojačavanje u članku CIS Benchmarks i BSI moduli.

Kako PHP SOS konkretno pomaže?

• Bilježimo sve nazive hostova i usluge s TLS-om, uključujući panele, staging i web-sučelja e-pošte.
• Postavke uspoređujemo s TR-02102 i odgovarajućim TLSRef profilom te dokumentiramo svjesna odstupanja.
• Certifikate prebacujemo na automatsko produljenje uz nadzor.
• U aplikacijskom kodu tražimo isključene provjere certifikata i pokazujemo ispravak.

TLS je modul našeg ojačavanja poslužitelja za PHP web-poslužitelje; vezu s aktualnom situacijom objašnjava članak Što je PHP2Shell?.

Česta pitanja

Izvori

• BSI TR-02102: Kriptografski postupci, dio 2 TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx dokumentacija
• Apache HTTP Server: dokumentacija