Cos'è e come funziona HTTPS differenza tra HTTP e HTTPS
Pubblicato da Aggiornato il
Dopo aver introdotto il protocollo HTTP ed analizzato come funziona un'interazione tra client e server, scopriamo come si è evoluto questo protocollo col passare degli anni.
Dopo l'uscita della prima versione di HTTP, che risale al 1991, l'azienda informatica Netscape Communications introdusse HTTPS per il suo browser Netscape Navigator.
Ma cos'è e come funziona HTTPS? E quali sono le differenze tra HTTP e HTTPS?
Indice dei contenuti
Cos'è HTTPS
HTTPS (HyperText Transfer Protocol Secure), come si evince dall'ultima parola, è la versione sicura del protocollo HTTP.
Tecnicamente HTTPS non è un protocollo vero e proprio, ma il risultato dell'applicazione del protocollo TLS (Transport Layer Security) in congiunzione ad HTTP. In precedenza veniva utilizzato SSL (Secure Sockets Layer), ma oggi è considerato poco sicuro.
HTTPS verifica l'identità di un sito web e crittografa le informazioni inviate tra il sito web e il client. Queste includono i cookie, lo user-agent, i percorsi degli URL e i dati inviati tramite i moduli. HTTPS è progettato per impedire che queste informazioni vengano lette o modificate mentre sono in transito.
Le URL di HTTPS iniziano con https://
e utilizzano la porta 443
di default, a differenza di HTTP le cui URL cominciano con http://
e utilizzano la porta 80
.
In questo momento il tuo browser web sta visualizzando un'icona verde a forma di lucchetto nella barra degli indirizzi per indicare che una connessione HTTPS è attiva. Se utilizzi Chrome 68
vedrai pure la scritta "Sicuro" sempre in verde.
Se configurato correttamente HTTPS garantisce:
- Privacy: la connessione del client con il sito web è crittografata, oscurando i dati sensibili.
- Autenticazione: il client sta comunicando esattamente col sito web autentico (e non con un falso).
- Integrità: i dati scambiati tra il client e il sito web non vengono manomessi o modificati da terzi.
Ma cosa succede dietro le quinte durante una connessione protetta?
Per scoprirlo introduciamo alcuni concetti di ciò che sta alla base del funzionamento di HTTPS, ovvero la crittografia.
Come funziona HTTPS: parte prima
Per capire come funziona HTTPS è necessario introdurre alcuni concetti di crittografia quali chiavi pubbliche e private, firme digitali, certificati digitali e autorità di certificazione.
Chiavi pubbliche e private
Le chiavi pubbliche e private sono strumenti utilizzati nella cosiddetta crittografia asimmetrica o a doppia chiave. Sono progettati per mantenere i dati privati, e proteggere le comunicazioni su Internet.
È possibile generare una coppia di chiavi composta da una chiave privata e una chiave pubblica. Ci sono diversi algoritmi che lo fanno, ad esempio RSA è uno di questi.
La chiave privata, come suggerisce il nome, deve rimanere segreta e custodita in un luogo sicuro (nel caso di un sito web verrà custodita sul server), mentre la chiave pubblica è destinata a essere distribuita pubblicamente.
Se ad esempio Bob vuole inviare un messaggio ad Alice, deve prima usare la chiave pubblica per crittografare i dati, quindi può inviare il messaggio (crittografato) ad Alice. L'unico modo di decifrare il messaggio per Alice è l'utilizzo della sua chiave privata.
In questo modo Alice non si deve preoccupare se qualcun altro sta ascoltando la comunicazione tra lei e Bob, perché solo lei può decodificarla, attraverso la chiave privata.
Il seguente video mostra come funzionano le comunicazioni criptate attraverso l'uso di chiavi pubbliche e private.
Firme digitali
Usando la chiave privata è possibile firmare digitalmente i dati. Funziona come nel mondo reale in cui una firma viene apposta tramite una penna su un foglio di carta, con la differenza che una firma digitale non può essere falsificata.
Dopo aver firmato i dati con la chiave privata, chiunque può verificare la firma usando la chiave pubblica associata. Se il destinatario dei dati firmati verifica correttamente la firma utilizzando la chiave pubblica ottiene due garanzie:
Autenticazione: il destinatario è sicuro che i dati provengono dal proprietario della chiave privata associata.
Integrità: il destinatario è sicuro che i dati non siano stati modificati da terzi durante il percorso.
Certificati digitali e autorità di certificazione
Lo scambio di chiavi pubbliche e la firma digitale introducono un nuovo problema da risolvere.
Se ad esempio vogliamo comunicare in modo sicuro con Google, abbiamo bisogno della sua chiave pubblica e lo stesso vale per altri siti che vogliamo visitare (Facebook, Twitter, etc...).
Dato che esistono miliardi di siti web su Internet, come possiamo ottenere una chiave pubblica per ogni sito web che vogliamo visitare?
Ed è qui che entrano in scena le autorità di certificazione o CA.
Una CA è un'organizzazione di terze parti con 3 obiettivi principali:
- Rilasciare certificati digitali.
- Confermare l'identità del proprietario del certificato.
- Fornire la prova che il certificato è valido.
Nello scenario di HTTPS la chiave pubblica è rappresentata da un certificato digitale, più noto come certificato SSL/TLS.
Ora vediamo in che modo è possibile ottenere un certificato SSL/TLS firmato da una CA:
- Il proprietario del sito web genera una chiave pubblica e una chiave privata ed invia un file di richiesta di firma del certificato (CSR) e la sua chiave pubblica alla CA.
- La CA crea quindi un certificato personale basato sulla CSR, dove sono indicati nome di dominio, nome del proprietario, data di scadenza e altre informazioni, appone la firma digitale, infine crittografa l'intero certificato con la chiave pubblica del server e lo rimanda al proprietario del sito web.
- Il certificato viene quindi decifrato con la chiave privata del proprietario del sito web e, infine, viene installato sul server.
N.B. La firma digitale della CA è crittografata dalla chiave privata della CA e può essere decifrata solamente con la chiave pubblica della CA, chiamiamo questa chiave Certificato Radice (Root Certificate).
Ogni dispositivo (pc, smartphone) ha, installato nel browser, un elenco di certificati radice di molte CA fidate. La figura seguente mostra questo elenco.
Come funziona HTTPS: parte seconda
Ora vediamo come avviene la connessione HTTPS tra client e sito web, prendendo come esempio il sito di Google (google.com) e Comodo come CA. Durante una connessione HTTPS avvengono due passaggi:
- L'handshake (letteralmente stretta di mano) per convalidare il certificato del sito web.
- La creazione di una connessione sicura tra client e sito web.
Handshake
Ecco cosa succede durante la "stretta di mano" tra browser e sito web:
- Quando visiti il sito di Google, il server fornisce al tuo browser la sua chiave pubblica + il certificato (firmato da Comodo).
- Per verificare l'autenticità del certificato, il browser preleva dall'elenco dei certificati radice la chiave pubblica di Comodo e tenta di decodificare la firma digitale del certificato che è stata crittografata tramite la chiave privata di Comodo.
- Se è in grado di decifrare la firma passa allo step successivo, altrimenti mostra all'utente un avviso come puoi vedere dalla figura seguente.
Creazione connessione sicura
Come già detto, Google invia la sua chiave pubblica mentre visiti google.com. Tutti i dati crittografati con questa chiave pubblica possono essere decifrati solo dalla chiave privata di Google.
- Dopo aver convalidato il certificato, il browser crea una nuova chiave di sessione facendone una copia. Queste chiavi possono crittografare e decrittografare i dati.
- Il browser quindi crittografa la chiave di sessione + altri dati con la chiave pubblica di Google ed invia tutto al server di Google.
- Il server di Google decodifica i dati crittografati utilizzando la sua chiave privata.
Ora server e browser hanno entrambi una copia della chiave di sessione creata dal browser. Nessun altro ha questa chiave, quindi solo server e browser possono crittografare e decrittografare i dati.
Quando Google invia dati al browser, prima li crittografa con la chiave di sessione e il browser decodifica i dati con la sua copia di questa chiave. Lo stesso avviene se è il browser ad inviare i dati.
Funzionamento HTTPS: riepilogo passo passo
Ora che conosci tutte le fasi del funzionamento di HTTPS facciamo un riepilogo passo passo prendendo come esempio sempre Google e Comodo:
- Google richiede un certificato a Comodo.
- Comodo verifica che è davvero Google che sta effettuando la richiesta.
- Google invia a Comodo la propria chiave pubblica.
- Comodo utilizza la propria chiave privata per firmare digitalmente la chiave pubblica di Google.
- Comodo dà a Google la chiave pubblica firmata, questa rappresenta ora il certificato SSL/TLS di Google.
- Ti colleghi col tuo browser al sito web di Google.
- Google invia al browser il certificato SSL/TLS.
- Utilizzando la chiave pubblica di Comodo, che si trova nell'archivio dei certificati radice del tuo browser, viene verificata la firma di Comodo sul certificato SSL/TLS di Google.
- Viene generata una chiave segreta e si utilizza la chiave pubblica di Google, ovvero il certificato, per crittografarla.
- Viene inviata la chiave segreta crittografata a Google.
- Google decrittografa la chiave segreta con la propria chiave privata e la trattiene.
- Il tuo browser e Google utilizzano la chiave segreta condivisa per crittografare le comunicazioni.
Così viene raggiunta l'autenticazione e finché Comodo è ritenuta una CA attendibile, puoi essere certo che i loro certificati saranno sicuri e affidabili.
Differenza tra HTTP e HTTPS
In questa tabella possiamo vedere cosa cambia tra HTTP e HTTPS
Caratteristica | HTTP | HTTPS |
---|---|---|
Sicuro | No | Si |
Porta utilizzata | 80 |
443 |
Pila protocollare | Livello di applicazione | Utilizza il protocollo SSL/TLS tra il livello di trasporto e di sessione |
Dati criptati prima della spedizione | No | Si |
Necessita di certificato SSL/TLS | No | Si |
Validazione dominio | No | Si |
Conclusioni
HTTPS rappresenta la migliore soluzione per trasmettere dati sensibili attraverso la rete e proteggere la privacy degli utenti.
Tuttavia, anche se garantisce che le informazioni trasmesse tra il browser e un sito web siano protette, HTTPS non impedirà a un utente malintenzionato di sfruttare le vulnerabilità del sito o del software installato sul server.
Con l'uscita di Chrome 68
i siti serviti su http://
verranno contrassegnati come "Non sicuri". Ciò potrà dissuadere i visitatori a proseguire la navigazione e questo avrà effetti negativi sulle visite. L'unico modo per evitare ciò è installare un certificato SSL/TLS e servire il sito su https://
.
E tu, hai già installato un certificato e fatto la migrazione del tuo sito web ad HTTPS? Non sai da dove cominciare? Contattami ora per un'analisi gratuita!
Risorse utili
- https://badssl.com/ Errori causati da configurazioni SSL/TLS errate