Quando digiti un indirizzo nel tuo browser, le prime lettere dell’URL determinano se i tuoi dati viaggiano in chiaro o in un tunnel crittografato. HTTPS, ovvero Hypertext Transfer Protocol Secure, aggiunge uno strato di crittografia al protocollo HTTP classico. Questo strato si basa sul protocollo TLS (Transport Layer Security), successore del SSL, che protegge ogni scambio tra il browser e il server web.
Contenuto misto e errori di migrazione HTTPS
Installare un certificato SSL/TLS su un sito non è sufficiente per garantirne la sicurezza totale. Un problema comune, spesso ignorato, si verifica dopo la migrazione: il contenuto misto rompe la protezione HTTPS.
Hai mai notato un lucchetto barrato o un avviso del browser su un sito che è comunque in HTTPS? Questo accade quando alcune risorse (immagini, script, fogli di stile) vengono ancora caricate in HTTP. Il browser considera quindi la pagina come parzialmente non sicura.
Correggere questo problema richiede di riscrivere tutti gli URL interni affinché puntino a risorse HTTPS. Cloudflare offre riscritture automatiche per gestire questo caso specifico. Su un CMS come WordPress, estensioni come Really Simple SSL facilitano questa correzione. Per chi desidera saperne di più sull’acronimo HTTPS e sul suo funzionamento, la gestione del contenuto misto è un passaggio obbligato prima di considerare la migrazione come completata.
Certificato SSL/TLS e crittografia: come si sicurizza la connessione
Il meccanismo di sicurezza si basa su due fasi distinte. La prima utilizza la crittografia asimmetrica per scambiare le chiavi. La seconda passa a una crittografia simmetrica, più veloce, per proteggere i dati durante l’intera sessione.
Il ruolo del certificato e dell’autorità di certificazione
Un certificato digitale è rilasciato da un’autorità di certificazione (CA). Questo certificato dimostra al browser che il server è effettivamente quello che dice di essere. Senza questa verifica, un attaccante potrebbe spacciarsi per il sito legittimo.
Il certificato contiene la chiave pubblica del server. Il browser la utilizza per crittografare un segreto condiviso, che solo il server può decrittografare con la sua chiave privata. Questo segreto viene poi utilizzato per generare le chiavi di sessione per la crittografia simmetrica.
TLS 1.3 e i suoi miglioramenti concreti
TLS 1.3 riduce il numero di scambi necessari per stabilire la connessione sicura. Il risultato: una negoziazione più rapida e l’eliminazione di algoritmi obsoleti che erano ancora tollerati dalle versioni precedenti. I lavori attuali si concentrano sulla crittografia post-quantistica, destinata a resistere ai futuri computer quantistici in grado di rompere gli algoritmi di crittografia classici.
HSTS: forzare il browser a rimanere in HTTPS
Configurare HTTPS sul tuo dominio non garantisce che ogni visitatore lo utilizzi. Un utente che digita manualmente un indirizzo senza il prefisso “https://” può essere reindirizzato in HTTP per una frazione di secondo. Questa finestra è sufficiente per un attacco di downgrade.
HSTS (HTTP Strict Transport Security) ordina al browser di accettare solo connessioni crittografate per un dominio specifico, per un periodo definito dal server. In pratica, il server invia un’intestazione specifica nella sua risposta HTTP. Il browser la memorizza e rifiuta poi qualsiasi connessione non crittografata, anche se l’utente digita “http://”.
Questo meccanismo è distinto dal semplice reindirizzamento 301 da HTTP a HTTPS. Il reindirizzamento corregge il problema lato server. HSTS lo corregge lato browser, prima ancora che venga inviata una richiesta HTTP. Le recenti guide di hardening raccomandano HSTS come un controllo di sicurezza a tutti gli effetti.
HTTPS non protegge tutto: misure complementari
Un sito in HTTPS crittografa i dati in transito tra il visitatore e il server. Ma le minacce non si limitano all’intercettazione della rete. HTTPS non protegge né il server stesso né l’applicazione web.
Ecco le misure che completano realmente la crittografia della connessione:
- Gli attributi dei cookie Secure, HttpOnly e SameSite limitano l’esposizione dei token di sessione. Secure impedisce l’invio del cookie su una connessione HTTP. HttpOnly blocca l’accesso al cookie da JavaScript lato client. SameSite riduce i rischi di attacchi CSRF controllando quando il cookie viene trasmesso.
- Le aggiornamenti regolari del CMS e delle sue estensioni correggono le vulnerabilità di sicurezza note. Un WordPress o un PrestaShop non aggiornato rimane vulnerabile, certificato o meno.
- L’autenticazione a due fattori (2FA) sugli account di amministrazione aggiunge una barriera aggiuntiva contro accessi non autorizzati, anche se una password viene compromessa.
- Le backup testate consentono di ripristinare il sito dopo un incidente. Un backup non verificato è quasi rischioso quanto l’assenza di backup.
Verificare la sicurezza HTTPS del tuo sito web
Vari indicatori consentono di controllare rapidamente se il tuo dominio è configurato correttamente. L’icona del lucchetto nella barra degli indirizzi rimane il segnale più visibile per i visitatori. Cliccando su di essa, il browser mostra i dettagli del certificato: autorità emittente, data di scadenza, dominio coperto.
Gli strumenti di verifica SSL online analizzano la configurazione del server in modo più approfondito. Rilevano le versioni TLS obsolete ancora attive, le suite di crittografia deboli o l’assenza di intestazione HSTS. Un certificato valido non significa che la configurazione TLS sia ottimale.
Pensa anche a monitorare la data di scadenza del tuo certificato. Un certificato scaduto attiva un avviso a schermo intero nel browser, il che fa fuggire i visitatori e può influenzare il tuo posizionamento nei motori di ricerca.
La sicurezza di un sito web funziona per strati successivi. HTTPS costituisce il primo, quello che protegge il canale di comunicazione. I cookie sicuri, l’HSTS, gli aggiornamenti e il 2FA formano gli strati successivi. Trascurare uno di essi indebolisce l’intero sistema, indipendentemente dalla cura prestata agli altri.