TLS-i ja HTTPS-i õige seadistamine

Lühidalt: Korralik TLS-konfiguratsioon veebiserverile pakub ainult TLS 1.2 ja TLS 1.3, kasutab šifrikomplekte, millel on Forward Secrecy ja autenditud krüpteerimine (AES-GCM, ChaCha20-Poly1305), ning sertifikaati ECDSA- või piisavalt pika RSA-võtmega, mis pikeneb automaatselt. Suunda annavad BSI (Saksamaa föderaalne infoturbeamet) suunis TR-02102-2 ja TLSRef-i Server-Side-TLS soovitused. Kontrollige tulemust väljastpoolt ja ärge unustage ühendusi, mida PHP ise loob.

Miks vanad TLS-sätted nii kaua püsivad

Lukk brauseris on olemas, seega loetakse krüpteerimine tehtuks. Nii arvavad paljud haldajad ja seetõttu jääb TLS-konfiguratsioon sageli aastateks muutmata. See pärineb siis serveri seadistamise ajast, kopeeritud mallist või paneeli vaikeväärtustest.

Probleem: soovitused muutuvad. Protokolliversioonid asendatakse, meetodeid peetakse nõrkadeks, lisandub uusi võtmevahetusmeetodeid. BSI avaldas TR-02102 viimati versioonina 2026-01 kuupäevaga 27.01.2026 ja viitab seal juba hübriidsetele kvantjärgsetele meetoditele TLS 1.3 jaoks. Kes pole oma sätteid aastaid vaadanud, ei ole suure tõenäosusega enam ajakohasel tasemel.

Kes kontrollib servereid niikuinii praegu PHP2Shelli tõttu, saab TLS-konfiguratsiooni vaadata samal ajal. See ei sulge PHP auku, kuid kuulub iga korraliku kõvendamise juurde.

Millele hea TLS-konfiguratsioon veebiserverile tugineb

Kaks allikat on Euroopa veebisaitide haldajatele eriti kasulikud. BSI TR-02102 hindab krüptograafilisi meetodeid; 2. osa käsitleb TLS-i. See on suunatud eelkõige arendajatele ja planeerijatele ning on ametiasutuste ja reguleeritud valdkondade jaoks sageli mõõdupuuks. Server-Side-TLS soovitusi, mida varem hoiti Mozilla wikis, jätkatakse nüüd TLSRef-is ja need pakuvad konkreetseid, kopeeritavaid profiile.

TLSRef eristab versioonis 6.0 kahte profiili:

Avalike veebisaitide jaoks on Intermediate tavaline lähtepunkt. Profiil jätab välja väga vanad seadmed, kuid katab praegused brauserid ja operatsioonisüsteemid. Hübriidgrupp X25519MLKEM768 eeldab ajakohast TLS-teeki. Kontrollige, kas teie OpenSSL-i versioon seda tunneb, enne kui selle sisse kirjutate.

Nginx ja Apache: turvaline lähtepunkt

Järgmised näited rakendavad Intermediate-profiili. Teed on kohatäitjad, šifrikomplektide nimekiri kehtib TLS 1.2 jaoks; TLS 1.3 toob kaasa omad turvalised vaikemeetodid.

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

Teine server-plokk suunab krüpteerimata päringud püsivalt HTTPS-ile. Suunamine peaks viitama otse lõppaadressile ja mitte jooksma läbi mitme vahepeatuse. Kontrollige seejärel ka sisseehitatud ressursse: pildid, skriptid või fondid, mida laaditakse veel HTTP kaudu, vallandavad brauseris hoiatusi või blokeeritakse.

Säte, et järjekorra valib klient, vastab TLSRef-i soovitusele: kõiki pakutavaid meetodeid peetakse turvaliseks ja AES-kiirenduseta seadmed saavad nii eelistada ChaCha20-t. Pärast iga muudatust testige konfiguratsiooni (nginx -t vastavalt apachectl configtest) ja laadige teenus uuesti. Sobiva HSTS-päise ja muud brauseri nõuded kirjeldab juhend Veebisaitide turvapäised.

Sertifikaadid: võti, ahel, pikendamine

Suur osa TLS-i probleemidest praktikas ei ole seotud šifrikomplektidega, vaid sertifikaatidega. Tüüpilised vead on poolik ahel, kus vahesertifikaat puudub, aegunud sertifikaadid kõrvaldomeenidel ja liiga laiade failiõigustega privaatvõtmed.

Kolm reeglit aitavad:

1. Pikendage automaatselt ja jälgige pikendamist. Lühikesed kehtivusajad, nagu TLSRef soovitab, on praktilised ainult automatiseerimisega.
2. Kaitske privaatvõtmeid: loetavad ainult root'ile ja veebiserveri protsessile, mitte kunagi veebijuurkataloogis, mitte kunagi repositooriumis.
3. Kaardistage kõik nimed: peadomeen, www, alamdomeenid poele, staging'ule, meili veebiliidesele ja paneelidele.

Kes kasutab sertifikaate mitmes kohas, näiteks CDN-is, koormusjaoturis ja lähteserveris, peaks pidama ülevaadet: milline sertifikaat on kus paigaldatud, kes seda pikendab ja millal see aegub. Kui ülevaadet pole, märgatakse aegunud sertifikaati sageli alles siis, kui kliendid teatavad.

Nii kontrollite oma konfiguratsiooni väljastpoolt

Järgmised käsud on puhtalt kontrollid ja ei muuda midagi. Asendage hostinimi enda omaga:

# TLS 1.3 ja TLS 1.2 peaksid töötama
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 peaks ebaõnnestuma
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Väljastatud sertifikaadi kehtivusaeg ja omanik
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

TLS 1.1 testi ebaõnnestumine võib tuleneda ka sellest, et teie kohalik OpenSSL-i versioon ei paku vana protokolli enam üldse. Täieliku aruande jaoks kõigi pakutavate meetodite kohta sobib spetsialiseeritud TLS-skanner. Kontrollige seejuures iga alamdomeeni eraldi, sest need töötavad sageli oma sätetega.

Unustatud: TLS seal, kus PHP ise on klient

PHP-rakendused loovad ise palju ühendusi: makseteenuse pakkujate, saatjate, liideste, meiliserverite ja andmebaaside poole. Siin ei ole sagedaseim viga nõrk säte, vaid välja lülitatud sertifikaadi kontroll, sageli kiire lahendusena arenduse probleemile.

<?php
// Turvaline: sertifikaati ja hostinime kontrollitakse (säilitage vaikekäitumine)
$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);

Otsige koodist CURLOPT_SSL_VERIFYPEER väärtusega false ja verify_peer voo kontekstides. Iga leid tühistab TLS-i kaitse selle ühenduse jaoks praktiliselt. Kus teenused asuvad CDN-i taga, peaks ka lõik CDN-i ja lähteserveri vahel kasutama kehtivat, kontrollitud sertifikaati. Veel veebiserveri sätteid PHP-seadistuste jaoks leiate artiklist Nginxi turvaline seadistamine PHP jaoks, mõõdupuud kogu kõvendamiseks artiklist CIS-võrdlusalused ja BSI moodulid.

Kuidas PHP SOS konkreetselt aitab?

• Me kaardistame kõik TLS-iga hostinimed ja teenused, sealhulgas paneelid, staging'u ja meili veebiliidesed.
• Me võrdleme sätteid TR-02102 ja sobiva TLSRef-i profiiliga ning dokumenteerime teadlikud kõrvalekalded.
• Me viime sertifikaadid üle automaatsele pikendamisele koos jälgimisega.
• Me otsime rakenduse koodist välja lülitatud sertifikaadikontrolle ja näitame parandust.

TLS on üks osa meie PHP veebiserverite kõvendamisest; seose praeguse olukorraga selgitab Mis on PHP2Shell?.

Korduma kippuvad küsimused

Allikad

• BSI TR-02102: krüptograafilised meetodid, 2. osa TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx-i dokumentatsioon
• Apache HTTP Server: dokumentatsioon