HTTPS, SSL e TLS: cosa sono e come funzionano

HTTPS è lo standard utilizzato per proteggere le comunicazioni tra browser e server web. Dietro il lucchetto mostrato dal browser operano però tecnologie con compiti differenti: HTTP, TLS, certificati digitali, autorità di certificazione e crittografia.

Capire come interagiscono questi componenti aiuta a configurare correttamente un sito, evitare errori e distinguere un certificato valido da una configurazione HTTPS realmente efficace.

HTTPS, SSL e TLS: qual è la differenza?

I tre termini vengono spesso utilizzati come sinonimi, ma tecnicamente non indicano la stessa cosa. HTTPS è HTTP trasmesso attraverso un canale protetto da TLS; TLS è il protocollo crittografico che crea e protegge quel canale; SSL è il nome della tecnologia precedente, ormai superata e non più utilizzata nelle configurazioni moderne.

Quando si parla di “certificato SSL” si usa quindi un termine ormai entrato nell'uso comune per indicare un certificato digitale utilizzato con TLS. Il certificato non è l'elemento che cifra direttamente tutte le pagine: serve soprattutto a permettere al browser di verificare l'identità del server e a partecipare all'avvio della connessione sicura.

Che cosa protegge HTTPS?

TLS fornisce tre proprietà fondamentali alla comunicazione tra client e server: confidenzialità, integrità e autenticazione. In pratica, i dati scambiati dopo l'instaurazione della connessione vengono protetti dalla lettura e dalla modifica da parte di chi dovesse intercettare il traffico.

HTTPS non rende però sicuro tutto ciò che avviene sul sito. Non corregge vulnerabilità applicative, password deboli, codice PHP non aggiornato, configurazioni errate o compromissioni del server. È uno strato di sicurezza della comunicazione, non un sostituto della sicurezza dell'applicazione.

Come funziona una connessione HTTPS

Quando si apre un indirizzo come https://www.example.com, il browser deve prima raggiungere il server corretto e poi stabilire i parametri crittografici della connessione. Il processo coinvolge quindi più livelli, dal DNS fino al protocollo HTTP.

Il DNS permette di associare il nome del dominio all'indirizzo IP del servizio. Una volta raggiunto il server, client e server negoziano la connessione TLS; completato l'handshake, le richieste e le risposte HTTP vengono trasferite attraverso il canale protetto.

Il TLS handshake

L'handshake TLS è la fase in cui client e server negoziano la versione e i parametri crittografici, stabiliscono il materiale necessario per derivare le chiavi di sessione e verificano l'autenticità del server. In TLS 1.3 il processo è stato semplificato rispetto alle versioni precedenti e gran parte dell'handshake viene protetta molto prima che il normale traffico applicativo inizi.

In forma semplificata, il browser comunica le versioni e i parametri crittografici supportati, mentre il server seleziona quelli compatibili e invia i propri parametri, insieme al certificato quando viene utilizzata l'autenticazione tramite certificato. Le due parti eseguono quindi lo scambio delle chiavi e derivano il materiale crittografico necessario per proteggere il traffico.

Una volta completato l'handshake, TLS utilizza chiavi di sessione per proteggere i dati. I dati applicativi vengono protetti con algoritmi simmetrici, efficienti per trasferire grandi quantità di informazioni. Durante l'handshake vengono invece utilizzati meccanismi di scambio delle chiavi e firme digitali per stabilire il segreto condiviso e autenticare il server.

Che cos'è un certificato TLS

Un certificato digitale associa un'identità, normalmente uno o più nomi di dominio, a una chiave pubblica. Il certificato è firmato da un'autorità di certificazione (CA) che il browser considera attendibile attraverso una catena di certificati. La validazione del dominio serve a verificare il controllo del nome indicato nel certificato, non a certificare l'affidabilità generale del sito o del suo proprietario.

Quando il browser riceve il certificato, verifica aspetti come il nome del dominio, il periodo di validità, la firma della CA e la catena di fiducia. Se i controlli sono corretti e la configurazione TLS è compatibile, il certificato consente al browser di autenticare il server per il nome di dominio indicato.

Certificato, chiave pubblica e chiave privata

Il certificato contiene la chiave pubblica e le informazioni relative all'identità certificata, oltre agli attributi che ne definiscono l'utilizzo. La relativa chiave privata deve invece rimanere segreta sul server: il suo possesso permette di dimostrare che il server controlla effettivamente la chiave associata al certificato.

Per questo la protezione della chiave privata è importante quanto la corretta installazione del certificato. Un certificato valido non può compensare la compromissione del server o la perdita del controllo della chiave privata.

Chi rilascia i certificati e come viene verificato un dominio?

I certificati utilizzati dai browser vengono normalmente emessi da Certificate Authority, o CA, riconosciute all'interno dei programmi e dei sistemi operativi. La CA non “rende sicuro” il sito in senso generale: verifica invece determinati requisiti per certificare il controllo del dominio, secondo il tipo di certificato e le proprie procedure.

Un esempio molto diffuso è Let's Encrypt, che utilizza il protocollo ACME per automatizzare la verifica del controllo del dominio, l'emissione e il rinnovo dei certificati. La verifica può avvenire, ad esempio, attraverso una risorsa HTTP pubblicata sul dominio oppure tramite un record DNS.

Il vantaggio dell'automazione è particolarmente importante perché i certificati pubblici hanno periodi di validità limitati e devono quindi essere rinnovati con regolarità. Un sistema ACME configurato correttamente può rinnovarli senza interventi manuali, riducendo il rischio che un certificato scada e renda il sito irraggiungibile in HTTPS.

TLS 1.2 e TLS 1.3: cosa cambia?

Le versioni moderne da considerare sono TLS 1.2 e soprattutto TLS 1.3. TLS 1.3 ha ridotto la complessità del protocollo, eliminato algoritmi e modalità obsolete e migliorato il processo di negoziazione, mantenendo come obiettivi principali autenticazione, riservatezza e integrità.

La scelta non consiste quindi semplicemente nell'“avere SSL”: bisogna verificare quali versioni TLS sono abilitate, quali parametri crittografici possono essere negoziati e se il certificato viene presentato correttamente per tutti i nomi di dominio interessati.

HTTPS e HTTP: perché il sito dovrebbe usare sempre HTTPS

Con HTTP tradizionale, il contenuto della comunicazione può essere intercettato o modificato durante il percorso tra browser e server. Con HTTPS, il traffico applicativo viene invece protetto da TLS dopo l'instaurazione della connessione.

Per un sito pubblico è quindi opportuno utilizzare HTTPS per tutte le pagine e per tutte le risorse caricate dalla pagina. Questo è particolarmente importante quando il sito gestisce autenticazioni, moduli, aree riservate, dati personali, pagamenti o cookie di sessione.

HTTPS è inoltre necessario per molte funzionalità moderne del browser che richiedono un secure context. Non è quindi soltanto un requisito per i siti che gestiscono pagamenti, ma una componente normale dell'infrastruttura web.

Il passaggio da HTTP a HTTPS

Attivare un certificato non è sufficiente per completare una migrazione. Un sito esistente deve essere configurato affinché le richieste HTTP vengano indirizzate verso HTTPS e affinché applicazioni, risorse e collegamenti utilizzino correttamente il nuovo schema.

È importante verificare immagini, fogli di stile, JavaScript, font, iframe e altre risorse incorporate. Se una pagina HTTPS carica ancora una risorsa tramite HTTP, il browser può bloccarla o segnalare un problema di mixed content.

La configurazione dovrebbe inoltre prevedere un redirect permanente da HTTP a HTTPS, mantenendo coerenti canonical, sitemap e collegamenti interni. È utile verificare anche eventuali URL assoluti presenti nel codice o nel database, perché possono continuare a generare richieste HTTP dopo la migrazione. Per i siti che lo supportano può essere valutato anche HSTS, che istruisce il browser a utilizzare HTTPS per le richieste future al dominio.

Se la migrazione riguarda un sito già indicizzato, è utile controllare anche il comportamento dei motori di ricerca e verificare che le versioni HTTP non rimangano come copie alternative. La configurazione tecnica deve quindi accompagnare la migrazione fin dall'inizio.

HTTPS, prestazioni e protocolli HTTP moderni

L'idea che HTTPS renda necessariamente il sito lento nasce soprattutto da configurazioni e infrastrutture datate. Il costo dell'handshake TLS è oggi molto più contenuto e le moderne versioni dei protocolli web sono progettate per funzionare normalmente su connessioni sicure.

HTTP/2 viene utilizzato dai browser moderni attraverso TLS, mentre HTTP/3 utilizza QUIC, che integra TLS 1.3 nel proprio meccanismo di sicurezza. Per questo HTTPS non è un ostacolo alle prestazioni: una configurazione aggiornata del server può utilizzare sicurezza e protocolli di trasporto moderni contemporaneamente.

Le prestazioni complessive dipendono molto di più da hosting, applicazione, caching, database, PHP, risorse statiche e rete. Per capire quali caratteristiche valutare in un'infrastruttura web è utile anche la guida su come leggere le caratteristiche di un piano hosting.

HTTPS protegge anche un sito WordPress o un e-commerce?

Sì, ma deve essere considerato come uno dei livelli di sicurezza dell'intera piattaforma. In un sito WordPress o in un e-commerce, HTTPS protegge il trasferimento di credenziali, sessioni e dati tra browser e server, mentre applicazione, CMS, plugin, database e server devono essere mantenuti sicuri separatamente.

Un certificato valido non corregge quindi una vulnerabilità di WordPress, di un plugin o del codice PHP. Per la parte applicativa è importante utilizzare versioni supportate e compatibili: la scelta della versione PHP incide infatti anche sulla sicurezza e sulla possibilità di mantenere aggiornato lo stack software. Per approfondire questo aspetto puoi consultare la guida su PHP, versioni, compatibilità, prestazioni e sicurezza.

HTTPS non sostituisce backup e sicurezza del server

HTTPS protegge la comunicazione in transito, ma non impedisce a un attaccante di compromettere il sito attraverso una vulnerabilità applicativa, credenziali rubate o un componente del server. Se un sito viene modificato o cancellato, TLS non permette di recuperare i dati.

Per questo HTTPS deve essere inserito in una strategia più ampia che comprenda aggiornamenti, controllo degli accessi, monitoraggio, isolamento delle risorse e backup affidabili. Una strategia di backup separata è descritta nella guida Backup di un sito web: come funziona e come creare una strategia affidabile.

Errori HTTPS più comuni

Quando HTTPS non funziona correttamente, il problema non è necessariamente il certificato. Gli errori possono dipendere da un certificato scaduto, da un nome di dominio non incluso nel certificato, da una catena incompleta, da una configurazione TLS incompatibile, da redirect errati o da risorse miste HTTP/HTTPS.

In alcuni casi il problema si manifesta anche come errore applicativo dopo l'installazione del certificato, perché il cambio di configurazione modifica il percorso della richiesta, i proxy o le regole del webserver. Per distinguere i problemi TLS da quelli applicativi è utile controllare i log del webserver e dell'applicazione; per gli errori HTTP generici puoi approfondire la diagnosi degli errori 500.

Che cosa controllare

Come verificare se HTTPS è configurato correttamente

Una verifica utile dovrebbe considerare sia il certificato sia la configurazione del server. Non basta controllare che il browser mostri il lucchetto: bisogna verificare che tutti i nomi utilizzati dal sito siano coperti, che la catena sia completa, che vengano utilizzate versioni TLS moderne e che non siano presenti risorse HTTP non necessarie.

È inoltre importante controllare il rinnovo automatico. Un certificato valido oggi può diventare un problema domani se il processo ACME non riesce a rinnovarlo per un errore DNS, una porta non raggiungibile, una modifica del virtual host o un problema con il client di gestione dei certificati.

Su un server gestito direttamente è buona pratica includere certificati e rinnovi nel monitoraggio dell'infrastruttura. Un problema può così essere individuato prima della scadenza e non quando gli utenti iniziano a ricevere un errore di sicurezza.

HTTPS come parte della sicurezza del sito

Una configurazione HTTPS corretta protegge la comunicazione, ma la sicurezza del sito dipende dall'intera catena tecnologica. Server, webserver, PHP, CMS, plugin, database, credenziali e backup devono essere gestiti separatamente con aggiornamenti, controlli degli accessi e procedure di ripristino adeguate.

TLS va quindi considerato una base infrastrutturale: deve essere sempre attivo, aggiornato e automatizzato, senza essere confuso con la sicurezza complessiva dell'applicazione.

Conclusioni

HTTPS è HTTP protetto da TLS. Il certificato digitale serve principalmente ad autenticare il server e a collegare il dominio a una chiave pubblica, mentre il TLS handshake negozia i parametri e stabilisce le chiavi utilizzate per proteggere il traffico.

Per un sito moderno è quindi opportuno utilizzare TLS aggiornato, certificati gestiti e rinnovati automaticamente, redirect coerenti da HTTP a HTTPS e una configurazione priva di mixed content. HTTPS è una componente fondamentale dell'infrastruttura, ma non sostituisce gli aggiornamenti, la sicurezza applicativa, il monitoraggio e i backup.

Approfondimenti

• Cos'è il DNS e a cosa serve
• PHP per un sito web: versioni, compatibilità e prestazioni
• Backup di un sito web: come funziona e come creare una strategia affidabile
• Come leggere le caratteristiche di un piano hosting e scegliere quello giusto