HTTPS, come funziona e cosa c'è da sapere

Quando si parla di navigazione sicura sul Web si fa generalmente riferimento all’utilizzo del protocollo HTTPS (HyperText Transfer Protocol over Secure Socket Layer): la presenza del lucchetto chiuso nella parte iniziale della barra degli indirizzi del browser Web conferma che il sito sta usando HTTPS.

Un tempo il protocollo HTTPS era utilizzato soltanto dalle banche e sui siti delle aziende di più grandi dimensioni ma da agosto 2014, quando Google fece riferimento all’utilizzo di HTTPS anche come allora blando fattore di ranking, la sua adozione si fece sempre più diffusa.
Oggi la stragrande maggioranza delle pagine Web usa HTTPS anche quando il sito non gestisce informazioni personali o dati sensibili.

HTTPS, come nasce e a cosa serve

L’idea di HTTPS è databile addirittura 1994 e fu di Netscape Communications: HTTPS è considerabile come una sorta di versione avanzata di HTTP ovvero del protocollo storicamente utilizzato per lo scambio di informazioni sul Web tra client e server.

Il protocollo HTTP focalizza l’attenzione sui meccanismi per lo scambio delle informazioni che contraddistinguono gli ipertesti (tali sono le pagine Web) ma non integra alcun livello di sicurezza aggiuntivo: i dati vengono scambiati in chiaro senza ricorrere alla crittografia. Sono quindi potenzialmente incercettabili, monitorabili, modificabili e danneggiabili da parte di terzi.

Con HTTPS si è voluto gestire il problema consentendo al browser Web di scambiare dati con il server remoto in forma cifrata. Dal momento che i dati tra client e server Web vengono crittografati eventuali malintenzionati non possono avere accesso alle informazioni trasferite né danneggiarle: vengono così evitati i cosiddetti attacchi MITM, man-in-the-middle).

Abbiamo già spiegato come funziona la crittografia e perché è essenziale utilizzarla.
Il livello di cifratura aggiuntivo usato da HTTPS per proteggere le informazioni che fluiscono da client e server e viceversa viene fornito da appositi protocolli crittografici: SSL (Secure Sockets Layer) e TLS (Transport Layer Security).
Alcune versioni di questi protocolli crittografici sono ormai considerate superate e insicure perché in passato ripetutamente rivelatesi soggette ad aggressioni.

SSL nel suo complesso è ormai superato anche se colloquialmente ancora oggi si utilizza di frequente tale acronimo per riferirsi in generale all’uso della cifratura per lo scambio di dati tra host remoti. TLS 1.3 e TLS 1.2 sono ormai gli unici protocolli che sarebbe bene utilizzare insieme con HTTPS. Il supporto per TLS 1.x viene mantenuto soprattutto dai siti Web che non gestiscono informazioni sensibili per estendere la compatibilità delle pagine anche ai browser più vecchi (che non supportano TLS 1.2 e 1.3)

Il sito SSL Server Test permette di scoprire tutto sull’utilizzo di HTTPS da parte di qualunque sito web.

HTTPS e il certificato digitale

Insieme con HTTPS si utilizza un certificato digitale che serve principalmente per attestare l’identità del sito Web visitato.
Il certificato digitale viene rilasciato da un’autorità di certificazione che accerta l’identità del richiedente, il possesso o la proprietà del nome a dominio ed emette un documento da esporre ai client collegati.

Sulla base delle verifiche che l’autorità di certificazione effettua prima dell’emissione del certificato vengono rilasciati diversi certificati digitali: DV (Domain Validated), OV (Organization Validated) ed EV (Extended Validation).
I certificati hanno anche un costo di rilascio e rinnovo diverso, a seconda della specifica tipologia.

Per i normali utilizzi va benissimo un certificato DV che addirittura un servizio come Let’s Encrypt fornisce a costo zero: in questo caso l’autorità di certificazione si limita a controllare solamente che il richiedente abbia titolarità per gestire il nome a dominio.

Un tempo i browser web mostravano una soluzione grafica differente all’inizio della barra degli indirizzi del browser: questo schema veniva adoperato per meglio esplicitare la tipologia di certificato durante il caricamento della pagina HTTPS.
Adesso invece si utilizza semplicemente il lucchetto chiuso di colore grigio per indicare l’uso di un certificato digitale valido e non scaduto indipendentemente dalla tipologia dello stesso.
L’utente può eventualmente fare clic sul lucchetto quindi su Certificato (su Ulteriori informazioni nel caso di Firefox) per ottenere maggiori informazioni sul certificato digitale in uso.

Come ottenere un certificato TLS da usare con HTTPS

Per ottenere un certificato digitale da usare sul proprio sito web al fine di proteggere i dati in transito con HTTPS ci si può rivolgere a un’autorità di certificazione o comunque al provider prescelto. Alcuni fornitori consentono di ottenere istantaneamente un certificato DV per il sito che si amministra semplicemente usando una comoda interfaccia web.

Chi usa un server dedicato o un servizio cloud può fare riferimento al modulo Certbot di EFF (Electronic Frontier Foundation) che permette di generare certificati digitali Let’s Encrypt per i siti configurati sul server Web. L’operazione di generazione del certificato digitale è generalmente gestibile anche da prompt dei comandi, dalla finestra del terminale e in generale dalla riga di comando.

Effettuando le opportune selezioni in corrispondenza di My HTTP website is running, si ottengono le indicazioni per generare il certificato digitale al fine dell’attivazione di HTTPS e le istruzioni per procedere con il rinnovo periodico del certificato stesso. I certificati Let’s Encrypt hanno infatti una scadenza trimestrale ma possono essere rinnovati automaticamente creando un’attività pianificata con il comando cron in Linux o su Windows Server, con un po’ di lavoro, usando Utilità di pianificazione. Lo abbiamo visto anche nell’articolo su come ottenere un certificato digitale gratuito per HTTPS.

Per controllare la data di scadenza dei certificati digitali usati sui propri siti Web si possono utilizzare diverse metodologie, compreso l’impiego di uno script che estragga le scadenze per tutti i nomi a dominio amministrati.

Chi gestisce un sito Web può fare riferimento all’articolo sull’importanza di passare da HTTP a HTTPS per ottenere alcuni suggerimenti pratici.

Errori HTTPS sui siti Web: da che cosa dipendono

Con l’indicazione Non sicuro che compare eventualmente all’inizio della barra degli indirizzi del browser, vengono segnalate le pagine Web che ancora usano HTTP in luogo di HTTPS, indipendentemente dal fatto che gestiscano dati personali oppure utilizzino o meno un form per il login. Abbiamo visto cosa fare in caso di sito non sicuro in Chrome.

Il sito di test BadSSL mostra invece gli errori che occasionalmente si potrebbero ricevere visitando pagine HTTPS.
Cliccando su expired, wrong.host, self-signed, untrusted-root e revoked, ad esempio, si può verificare come si comporta il browser web prescelto quando si dovesse visitare, rispettivamente, una pagina HTTPS con certificato scaduto, che si riferisce a un altro nome a dominio, autofirmato (quindi senza passare per un’autorità di certificazione) o rilasciato da un’entità radice non affidabile.

Cliccando su tls-v1-0 e tls-v1-1 si può verificare l’eventuale avviso mostrato dal browser nel caso in cui si tentasse di visitare una pagina HTTPS che usa solo i protocolli insicuri TLS 1.x.

Se si utilizza un’applicazione all’interno della rete locale che integra funzionalità proprie di un server Web molto spesso compare l’errore ERR_CERT_AUTHORITY_INVALID perché il certificato digitale è stato generato in proprio.
Questo non significa che i dati non viaggiano in forma cifrata: essi sono protetti e non possono essere letti o modificati lungo il loro percorso. Semplicemente non c’è un’attestazione dell’identità del soggetto che ha allestito il server Web e mette a disposizione un’applicazione via HTTPS. Per applicazioni che funzionano in locale, ad esempio in una Intranet o che si usano per scopi di test, l’avvio può essere tranquillamente ignorato e si può proseguire con la “navigazione”.

Mixed content e atteggiamento mutevole dei browser Web

I principali browser hanno da tempo dichiarato guerra alle pagine che ospitano mixed content.
Con questo termine si fa riferimento all’inserimento di oggetti che vengono richiamati via HTTP (quindi in chiaro) da pagine HTTPS.

La presenza di mixed content provoca la scomparsa del lucchetto sulle pagine HTTPS perché un eventuale contenuto malevolo richiamato via HTTP potrebbe modificare le informazioni contenute nella pagina HTTPS con la possibilità, ad esempio, di intercettare nomi utente e password. A questo proposito, anche i moduli di login che fanno riferimento a script via HTTP vengono immediatamente segnalati all’utente.

Sempre da BadSSL si può verificare (cercare mixed nella pagina) qual è il comportamento tenuto dal browser web nella gestione dei mixed content.

Nel rapportarsi con i mixed content il comportamento dei browser è mutevole e tende a essere sempre più intransigente.

Chrome, ad esempio, si astiene dallo scaricare qualunque file via HTTP ma non informa in alcun modo l’utente: il risultato è che talvolta si clicca su un link che non funziona perché il file da scaricare viene direttamente richiamato (oppure tramite reindirizzamento) usando un URL HTTP. Per risolvere basta applicare i suggerimenti utili nel caso in cui Chrome blocca i download dei file: i consigli valgono sia per il browser di Google che per tutti i prodotti derivati da Chromium.