TLS és HTTPS helyes konfigurálása

Röviden: Egy szilárd TLS-konfiguráció webszerverhez csak a TLS 1.2-t és a TLS 1.3-at kínálja, Forward Secrecy-vel és hitelesített titkosítással (AES-GCM, ChaCha20-Poly1305) rendelkező cipher suite-okat használ, és olyan tanúsítványt, amelynek ECDSA-kulcsa vagy kellően hosszú RSA-kulcsa van, és amely automatikusan megújul. Eligazítást a BSI (a német Szövetségi Információbiztonsági Hivatal) TR-02102-2 irányelve és a TLSRef Server-Side-TLS-ajánlásai adnak. Ellenőrizze az eredményt kívülről, és ne feledkezzen meg azokról a kapcsolatokról sem, amelyeket maga a PHP épít fel.

Miért élnek túl olyan sokáig a régi TLS-beállítások

A lakat ott van a böngészőben, tehát a titkosítás elintézettnek számít. Sok üzemeltető így gondolkodik, ezért a TLS-konfiguráció gyakran évekig változatlan marad. Ilyenkor a szerver üzembe helyezésének idejéből, egy bemásolt sablonból vagy egy panel alapértékeiből származik.

A gond: az ajánlások változnak. A protokollverziókat leváltják, egyes eljárások gyengének számítanak, új kulcscsere-eljárások jönnek. A BSI a TR-02102-t legutóbb a 2026-01-es változatban tette közzé 2026. január 27-én, és ott már a TLS 1.3-hoz tartozó hibrid poszt-kvantum eljárásokra is utal. Aki évek óta nem nézte meg a beállításait, nagy valószínűséggel már nincs az aktuális szinten.

Aki a PHP2Shell után amúgy is ellenőrzi a szervereit, a TLS-konfigurációt egy lendülettel megnézheti. A PHP-rést nem zárja le, de minden rendes keményítéshez hozzátartozik.

Mihez igazodik a jó TLS-konfiguráció webszerverhez

Két forrás különösen hasznos az üzemeltetőknek. A BSI TR-02102 kriptográfiai eljárásokat értékel; a 2. rész a TLS-sel foglalkozik. Főleg fejlesztőknek és tervezőknek szól, és hatóságok és szabályozott területek számára gyakran ez a mérce. A Server-Side-TLS-ajánlásokat, amelyeket korábban a Mozilla-wikiben gondoztak, ma a TLSRef viszi tovább, és konkrét, másolható profilokat adnak.

A TLSRef a 6.0-s változatban két profilt különböztet meg:

Nyilvános weboldalaknál az Intermediate a szokásos kiindulópont. A profil kizárja a nagyon régi eszközöket, de lefedi a mai böngészőket és operációs rendszereket. Az X25519MLKEM768 hibrid csoport friss TLS-könyvtárat feltételez. Mielőtt beírja, ellenőrizze, ismeri-e az Ön OpenSSL-verziója.

Nginx és Apache: biztonságos kiindulópont

A következő példák az Intermediate profilt valósítják meg. Az útvonalak helyőrzők, a cipher suite-ok listája a TLS 1.2-re érvényes; a TLS 1.3 saját, biztonságos alapértelmezett eljárásokat hoz magával.

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

A második server blokk tartósan HTTPS-re irányítja a titkosítatlan hívásokat. Az átirányítás közvetlenül a végleges címre mutasson, és ne több köztes állomáson haladjon át. Ezután ellenőrizze a beágyazott erőforrásokat is: a még HTTP-n betöltött képek, szkriptek vagy betűtípusok a böngészőben figyelmeztetést váltanak ki, vagy blokkolják őket.

Az a beállítás, hogy a kliens választja a sorrendet, megfelel a TLSRef ajánlásának: az összes kínált eljárás biztonságosnak számít, és az AES-gyorsítás nélküli eszközök így előnyben részesíthetik a ChaCha20-at. Minden módosítás után tesztelje a konfigurációt (nginx -t, illetve apachectl configtest), és töltse újra a szolgáltatást. A megfelelő HSTS-fejlécet és további böngészői előírásokat a Biztonsági fejlécek weboldalakhoz útmutató írja le.

Tanúsítványok: kulcs, lánc, megújítás

A gyakorlatban a TLS-problémák nagy része nem a cipher suite-okkal, hanem a tanúsítványokkal függ össze. Tipikus hibák a hiányos lánc, amelyből a köztes tanúsítvány hiányzik, a lejárt tanúsítványok mellékdomaineken, és a túl tág fájljogokkal rendelkező privát kulcsok.

Három szabály segít:

1. Automatikusan megújítani, és a megújítást felügyelni. A rövid futamidők, ahogyan a TLSRef ajánlja, csak automatizálással kivitelezhetők.
2. Védeni a privát kulcsokat: csak a root és a webszerver-folyamat számára olvashatók, soha nem a webrootban, soha nem egy repositoryban.
3. Minden nevet felvenni: főtartomány, www, aldomainek a webshophoz, stagingre, a levelezés webes felületéhez és a panelekhez.

Aki tanúsítványokat több helyen használ, például CDN-en, terheléselosztón és origin szerveren, vezessen áttekintést: melyik tanúsítvány hol van telepítve, ki újítja meg, és mikor jár le. Ha ez az áttekintés hiányzik, egy lejárt tanúsítvány gyakran csak akkor tűnik fel, amikor az ügyfelek jelentkeznek.

Így ellenőrizze a konfigurációt kívülről

A következő parancsok tisztán ellenőrzések, és semmit sem módosítanak. A hosztnevet cserélje a sajátjára:

# A TLS 1.3-nak és a TLS 1.2-nek működnie kell
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
# A TLS 1.1-nek el kell buknia
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# A kiszolgált tanúsítvány futamideje és birtokosa
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

A TLS 1.1-teszt kudarca azon is múlhat, hogy a helyi OpenSSL-verziója a régi protokollt egyáltalán nem kínálja már. Az összes kínált eljárásról szóló teljes jelentéshez egy specializált TLS-szkenner alkalmas. Közben minden aldomaint külön ellenőrizzen, mert gyakran saját beállításokkal futnak.

Elfelejtve: TLS ott, ahol a PHP maga a kliens

A PHP-alkalmazások maguk is sok kapcsolatot építenek fel: fizetési szolgáltatókhoz, szállítmányozókhoz, interfészekhez, levelezőszerverekhez és adatbázisokhoz. Itt a leggyakoribb hiba nem egy gyenge beállítás, hanem a tanúsítvány-ellenőrzés kikapcsolása, gyakran gyors megoldásként egy fejlesztési problémára.

<?php
// Biztonságos: a tanúsítványt és a hosztnevet ellenőrzi (az alapértelmezett viselkedést megtartani)
$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);

Keresse a kódban a false értékű CURLOPT_SSL_VERIFYPEER-t és a verify_peer-t a stream-kontextusokban. Minden találat gyakorlatilag feloldja a TLS védelmét az adott kapcsolatnál. Ahol a szolgáltatások CDN mögött vannak, a CDN és az origin szerver közötti szakasz is érvényes, ellenőrzött tanúsítványt használjon. További webszerver-beállításokat PHP-környezetekhez a Az Nginx biztonságos konfigurálása PHP-hez cikkben talál, a teljes keményítés mércéit a CIS-benchmarkok és BSI-modulok cikkben.

Hogyan segít konkrétan a PHP SOS?

• Felmérjük az összes hosztnevet és TLS-t használó szolgáltatást, beleértve a paneleket, a stagingt és a levelezés webes felületeit.
• A beállításokat összevetjük a TR-02102-vel és a megfelelő TLSRef-profillal, és dokumentáljuk a tudatos eltéréseket.
• A tanúsítványokat automatikus megújításra, felügyelettel állítjuk át.
• Az alkalmazáskódban kikapcsolt tanúsítvány-ellenőrzéseket keresünk, és megmutatjuk a javítást.

A TLS a PHP-webszerverek keményítésének egyik eleme; a mai helyzethez fűződő kapcsolatot a Mi a PHP2Shell? magyarázza el.

Gyakori kérdések

Források

• BSI TR-02102: Kriptográfiai eljárások, 2. rész: TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx dokumentáció
• Apache HTTP Server: dokumentáció