Molti dei miei clienti mi chiedono spesso di chiarire il ruolo dell’HTTPS. Ho provato a riassumere qui le informazioni necessarie alla corretta comprensione del suo funzionamento.
HTTPS (HyperText Transfer Protocol Secure) è la versione sicura del protocollo HTTP.
HTTPS (noto anche come HTTP over TLS) non è un protocollo vero e proprio, ma il risultato dell’applicazione del protocollo TLS (Transport Layer Security) in congiunzione ad HTTP.
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. È 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 quelli dell’HTTP che cominciano con http:// e utilizzano la porta 80.
L’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 sito
- Integrità: i dati scambiati tra il client e il sito web non vengono manomessi o modificati da terzi
Come funziona HTTPS in breve
È 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.
Ad esempio, se UtenteA vuole inviare un messaggio ad UtenteB, deve prima usare la chiave pubblica per crittografare i dati, quindi può inviare il messaggio crittografato ad UtenteB. L’unico modo di decifrare il messaggio per UtenteB è l’utilizzo della sua chiave privata.
In questo modo UtenteB non si deve preoccupare se qualcun altro sta ascoltando la comunicazione tra lei e UtenteA, perché solo lei può decodificarla, attraverso la chiave privata.
Certificati digitali e autorità di certificazione
Per comunicare in modo sicuro con Google abbiamo bisogno della sua chiave pubblica e lo stesso vale per altri siti che vogliamo visitare. Le autorità di certificazione o CA svolgono proprio questa funzione. Sono un soggetto terzo di fiducia (trusted third part), pubblico o privato, abilitato ad emettere un certificato digitale tramite una procedura di certificazione che segue standard internazionali e in conformità alla normativa europea e nazionale in materia.
Una CA è quindi un’organizzazione di terze parti che:
- Rilascia certificati digitali
- Conferma l’identità del proprietario del certificato
- Fornisce la prova che il certificato è valido
Ogni dispositivo ha installato un elenco di certificati radice di molte CA fidate, ad esempio, per visionarle su un dispositivo Android con Oreo (8.0) basterà seguire questo percorso di navigazione:
Impostazioni -> Security & location -> Encryption & credentials -> Trusted credentials
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.
Funzionamento HTTPS: riepilogo passo passo
Di seguito un esempio di una connessione HTTPS prendendo ad esempio Google e DigiCert (una tra le CA disponibili)
Procedura di certificazione in breve:
- Google richiede un certificato a DigiCert.
- DigiCert verifica che è davvero Google che sta effettuando la richiesta.
- Google invia a DigiCert la propria chiave pubblica.
- DigiCert utilizza la propria chiave privata per firmare digitalmente la chiave pubblica di Google.
- DigiCert dà a Google la chiave pubblica firmata, questa rappresenta ora il certificato SSL/TLS di Google.
Collegamento di un utente in breve:
- Ti colleghi col tuo browser al sito web di Google.
- Google invia al browser il certificato SSL/TLS.
- Utilizzando la chiave pubblica di DigiCert, che si trova nell’archivio dei certificati radice del tuo browser, viene verificata la firma di DigiCert 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.
HTTPS: stato della rete
Lee Butterman utilizzando un progetto opensource zmap ha scansionato oltre 350 milioni di connessioni SSL con i seguenti risultati.
Certificati emessi dalle maggiori CA (in milioni):
- 47.2M Let’s Encrypt
- 28.9M DigiCert
- 13.8M Comodo
- 10.1M Google
- 7.2M GoDaddy
- 7.1M Sectigo
- 7.0M cPanel
- 6.1M GlobalSign
- 3.4M CloudFlare
- 2.5M Amazon
- 2.1M (anonymous self-signed)
La CA Let’s Encrypt genera oltre 47 milioni di certificati, quasi il 30% del totale. I certificati Let’s Encrypt scadono dopo 3 mesi, il che spinge un regolare ciclo di aggiornamento, ma ci sono ancora un certo numero pratiche di sicurezza deprecate.
Sul web esistono ancora certificati che utilizzano algoritmi di criptazione obsoleti come: RC4, 3DES, TLS 1.0.
Oltre centocinquanta milioni di connessioni hanno utilizzato la curva ellittica Diffie Hellmann e AES. La successiva suite di cifratura più popolare è RSA con RC4 e quasi l’1,8% delle connessioni utilizza RC4 o 3DES.
Attualmente la best-practice consiglia di rinnovare un certificato SSL ogni 90 giorni ma la realtà è ben diversa.Cos’è l’ HTTPS e come funziona
Oltre 3.000 certificati non scadono in questo millennio. Oltre 8.000 certificati scadono dopo il 2200. Oltre 200.000 certificati scadono dopo il 2100. (Oltre 1,5 milioni scadono solo negli anni 2040)
Più di centomila certificati scadranno da soli nel 2117 e oltre mille scadranno nel 3017.
Quasi 1,6 milioni di domini avevano un certificato scaduto di recente (a luglio, il mese della scansione). Quasi 3,7 milioni di domini hanno un certificato scaduto nel 2019 (l’anno della scansione). Oltre 9,6 milioni di domini hanno un certificato scaduto nel 2010 infine, oltre centomila certificati scadono prima della data di validità.