In breve: una solida configurazione TLS del server web offre solo TLS 1.2 e TLS 1.3, usa cipher suite con forward secrecy e cifratura autenticata (AES-GCM, ChaCha20-Poly1305) e un certificato con chiave ECDSA oppure RSA sufficientemente lunga, che si rinnova automaticamente. Fanno da riferimento la direttiva tecnica TR-02102-2 del BSI (Ufficio federale tedesco per la sicurezza informatica) e le raccomandazioni Server-Side TLS di TLSRef. Verifichi il risultato dall'esterno e non dimentichi le connessioni che PHP stesso stabilisce.
Perché le vecchie impostazioni TLS sopravvivono così a lungo
Il lucchetto nel browser c'è, quindi la cifratura si considera sistemata. Così pensano molti gestori, ed è per questo che la configurazione TLS resta spesso invariata per anni. Risale allora al momento in cui il server è stato allestito, a un modello copiato o ai valori predefiniti di un pannello.
Il problema: le raccomandazioni cambiano. Le versioni dei protocolli vengono sostituite, alcune procedure sono considerate deboli, ne arrivano di nuove per lo scambio di chiavi. Il BSI ha pubblicato da ultimo la TR-02102 nella versione 2026-01 del 27/01/2026 e vi segnala già le procedure ibride post-quantistiche per TLS 1.3. Chi non guarda le proprie impostazioni da anni, con alta probabilità non è più aggiornato.
Chi comunque sta verificando i server dopo PHP2Shell può esaminare nello stesso passaggio anche la configurazione TLS. Non chiude la vulnerabilità di PHP, ma fa parte di ogni hardening fatto bene.
A che cosa si ispira una buona configurazione TLS del server web
Due fonti sono particolarmente utili per i gestori in Europa. La BSI TR-02102 valuta le procedure crittografiche; la parte 2 tratta TLS. Si rivolge soprattutto a sviluppatori e progettisti ed è spesso il metro di riferimento per le autorità e i settori regolamentati. Le raccomandazioni Server-Side TLS, in passato curate nel wiki di Mozilla, oggi proseguono presso TLSRef e forniscono profili concreti da copiare.
TLSRef distingue nella versione 6.0 due profili:
| Caratteristica | Intermediate (per la maggior parte dei siti) | Modern |
|---|---|---|
| Protocolli | TLS 1.2 e TLS 1.3 | solo TLS 1.3 |
| Cipher suite TLS 1.2 | ECDHE con AES-GCM o ChaCha20-Poly1305 | nessuna |
| Gruppi per lo scambio di chiavi | X25519MLKEM768, X25519, prime256v1, secp384r1 | come Intermediate |
| Certificato | ECDSA P-256 raccomandato oppure RSA a 2048 bit | ECDSA P-256 |
| Durata del certificato | 90 giorni raccomandati, al massimo 366 giorni | 90 giorni |
| HSTS max-age | due anni | due anni |
Per i siti pubblici Intermediate è il punto di partenza abituale. Il profilo esclude dispositivi molto vecchi, ma copre i browser e i sistemi operativi attuali. Il gruppo ibrido X25519MLKEM768 presuppone una libreria TLS aggiornata. Verifichi se la sua versione di OpenSSL lo conosce prima di inserirlo.
Nginx e Apache: un punto di partenza sicuro
Gli esempi seguenti attuano il profilo Intermediate. I percorsi sono segnaposto; l'elenco delle cipher suite vale per TLS 1.2; TLS 1.3 porta con sé procedure standard proprie e sicure.
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
Il secondo blocco server reindirizza in modo permanente a HTTPS le chiamate non cifrate. Il reindirizzamento dovrebbe puntare direttamente all'indirizzo definitivo e non passare per più tappe intermedie. Controlli poi anche le risorse incorporate: immagini, script o font ancora caricati via HTTP provocano avvisi nel browser o vengono bloccati.
L'impostazione per cui è il client a scegliere l'ordine corrisponde alla raccomandazione di TLSRef: tutte le procedure offerte sono considerate sicure e i dispositivi senza accelerazione AES possono così preferire ChaCha20. Dopo ogni modifica si provi la configurazione (nginx -t oppure apachectl configtest) e si ricarichi il servizio. L'header HSTS adatto e altre indicazioni per il browser sono descritti nella guida Header di sicurezza per i siti web.
Pannelli come Plesk o cPanel sovrascrivono spesso le modifiche manuali ai file generati. Imposti lì le direttive TLS tramite le impostazioni o i modelli previsti dal pannello.
Certificati: chiave, catena, rinnovo
Gran parte dei problemi TLS nella pratica non ha a che fare con le cipher suite, ma con i certificati. Errori tipici sono una catena incompleta in cui manca il certificato intermedio, certificati scaduti sui domini secondari e chiavi private con permessi sui file troppo ampi.
Tre regole aiutano:
- Rinnovare automaticamente e monitorare il rinnovo. Durate brevi, come le raccomanda TLSRef, sono praticabili solo con l'automazione.
- Proteggere le chiavi private: leggibili solo da root e dal processo del server web, mai nel webroot, mai in un repository.
- Rilevare tutti i nomi: dominio principale, www, sottodomini per shop, staging, interfaccia web della posta e pannelli.
Chi impiega certificati in più punti, ad esempio su CDN, load balancer e server di origine, dovrebbe tenere un elenco: quale certificato è installato dove, chi lo rinnova e quando scade. Senza questo elenco, un certificato scaduto si nota spesso solo quando si fanno vivi i clienti.
Come verificare la configurazione dall'esterno
I comandi seguenti sono semplici verifiche e non modificano nulla. Sostituisca l'hostname con il suo:
# TLS 1.3 e TLS 1.2 dovrebbero funzionare
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 dovrebbe fallire
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Durata e titolare del certificato fornito
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Un fallimento nel test di TLS 1.1 può dipendere anche dal fatto che la sua versione locale di OpenSSL non offre più affatto il vecchio protocollo. Per un rapporto completo su tutte le procedure offerte è adatto uno scanner TLS specializzato. Verifichi ogni sottodominio singolarmente, perché spesso girano con impostazioni proprie.
Dimenticato: TLS dove PHP stesso è client
Le applicazioni PHP stabiliscono da sole molte connessioni: verso fornitori di pagamento, corrieri, interfacce, server di posta e database. Qui l'errore più frequente non è un'impostazione debole, ma un controllo del certificato disattivato, spesso come soluzione rapida a un problema nello sviluppo.
<?php
// Sicuro: certificato e hostname vengono verificati (mantenere il comportamento predefinito)
$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);
Cerchi nel codice CURLOPT_SSL_VERIFYPEER con false e verify_peer nei contesti stream. Ogni occorrenza annulla di fatto la protezione di TLS per quella connessione. Dove i servizi si trovano dietro una CDN, anche la tratta tra CDN e server di origine dovrebbe usare un certificato valido e verificato. Altre impostazioni del server web per configurazioni PHP si trovano in Configurare Nginx per PHP in modo sicuro, i parametri di riferimento per l'intero hardening in Benchmark CIS e moduli BSI.
Come aiuta concretamente PHP SOS?
- Rileviamo tutti gli hostname e i servizi con TLS, compresi pannelli, staging e interfacce web della posta.
- Confrontiamo le impostazioni con la TR-02102 e il profilo TLSRef adatto e documentiamo le deviazioni consapevoli.
- Passiamo i certificati al rinnovo automatico con monitoraggio.
- Cerchiamo nel codice dell'applicazione i controlli dei certificati disattivati e mostriamo la correzione.
TLS è un tassello del nostro hardening del server per server web PHP; il legame con la situazione attuale lo spiega Che cos'è PHP2Shell?.
Domande frequenti
Devo ancora offrire TLS 1.0 e TLS 1.1?
In generale no. Le raccomandazioni attuali, come il profilo Intermediate di TLSRef, fissano TLS 1.2 come limite inferiore. Chi ha bisogno di protocolli più vecchi per dispositivi obsoleti dovrebbe deciderlo consapevolmente, documentarlo e limitarlo a un servizio separato.
Un certificato gratuito è meno sicuro di uno acquistato?
Per la cifratura non fa alcuna differenza. Contano il tipo di chiave, la lunghezza della chiave, una catena di certificati completa e un rinnovo automatico affidabile. Le differenze riguardano l'ampiezza delle verifiche, la durata e il servizio del fornitore.
HTTPS tra visitatore e CDN è sufficiente?
No. Anche la connessione tra CDN e server di origine dovrebbe essere cifrata e verificare il certificato dell'origine. Altrimenti, sulla seconda tratta i dati viaggiano in rete non cifrati o non verificati.
Che cosa c'entra TLS con PHP2Shell?
Direttamente nulla. TLS protegge i dati durante il trasporto, PHP2Shell riguarda l'interprete PHP sul server. Una connessione cifrata trasporta in modo affidabile anche le richieste di attacco, perciò l'aggiornamento di PHP resta obbligatorio a prescindere.