Ai vecchi tempi di Internet, la comunicazione era completamente in chiaro. Ciò significava che gli intercettatori potevano potenzialmente vedere tutti i dati inviati su Internet. Quindi le persone dovevano prestare molta attenzione quando inviavano informazioni sensibili.
Questo problema è stato riconosciuto già nel 1994, quindi è stato sviluppato il protocollo SSL (Secure Socket Layer). SSL crittografa i dati su un endpoint e li decrittografa sull'altro, in modo che i dati passati tra i computer siano completamente incomprensibili.
TLS (Transport Layer Security) è un protocollo simile a SSL e condivide lo stesso scopo. La prima versione è stata sviluppata nel 1999 e basata su SSL 3.0. Quando SSL 3.0 è risultato non sicuro, è stato completamente sostituito da TLS. TLS viene utilizzato per la navigazione web, ma può essere utilizzato per una varietà di servizi. Oggi, TLS 1.3 è l'ultima versione ufficiale e le versioni precedenti dovrebbero essere aggiornate.
Potresti aver notato durante la navigazione sul Web che alcuni URL iniziano con "http" e altri con "https". HTTP è l'acronimo di Hypertext Transfer Protocol ed è il protocollo che recupera HTML e altri media da visualizzare dal browser web. HTTPS è una versione di HTTP con TLS/SSL integrato. In altre parole, l'accesso a un sito Web "https" significa che le comunicazioni con il server sono crittografate. È consigliabile che ogni sito Web passi a HTTPS acquistando un certificato SSL.
La prima domanda che si potrebbe porre sulla comunicazione crittografata è "come fanno entrambe le parti a sapere come decifrare i messaggi? Sicuramente non possono semplicemente inviare la chiave sul web!” In effetti, possono e spiegheremo come passo dopo passo.
Supponiamo che tu sia un browser web e desideri connetterti all'host di un sito web. Il browser condurrà una conversazione con il server per stabilire un canale sicuro. Questa conversazione è chiamata handshake TLS.
Passaggio 1: il client invierà un messaggio di "ciao" al server, contenente le versioni TLS/SSL in uso, un elenco di suite di crittografia supportate e una stringa di byte casuali (denominata client random).
Cosa si intende per "suite di cifratura?" Ci arriveremo. Prima di tutto, un cifrario è semplicemente un algoritmo per crittografare un messaggio. Ad esempio, sostituire ogni lettera in un messaggio con un numero è un tipo di cifratura. Ma quelli usati da TLS sono molto più complessi e impossibili da violare da esseri umani o computer allo stesso modo.
Un cifrario può essere simmetrico o asimmetrico. Una cifratura simmetrica è quella in cui viene utilizzata una singola chiave per crittografare e decrittografare il messaggio. Sono molto utili quando solo tu vuoi vedere il contenuto del messaggio, poiché condividere la chiave è un rischio per la sicurezza. La cifratura simmetrica più è utilizzata da TLS e AES (Advanced Encryption Standard).
Le cifre asimmetriche richiedono chiavi separate per crittografare e decrittografare il messaggio e sono il componente più importante quando si stabilisce una sessione sicura. Ciò che fa funzionare questi algoritmi è che un utente malintenzionato non può decifrare il messaggio con la chiave di crittografia; deve avere la chiave di decrittazione. Pertanto, la chiave di crittografia, chiamata anche chiave pubblica, può essere scambiata liberamente tra le parti senza rappresentare un rischio per la sicurezza, purché la chiave di decrittazione (a.k.a. la chiave privata) non venga rivelata. I principali cifrari asimmetrici impiegati da TLS sono RSA (Rivest–Shamir–Adleman) e DHE (Diffie–Hellman).
Ora possiamo definire "suite di cifratura". Quindi una suite di cifratura contiene:
- Un algoritmo di crittografia simmetrica (come AES)
- Un algoritmo di crittografia asimmetrico (come RSA)
- Un codice di autenticazione dei messaggi (MAC), utilizzato per autenticare i messaggi
Passaggio 2: il server genera una coppia di chiavi pubblica/privata e risponde al client con: la suite di crittografia che desidera utilizzare, la versione TLS che desidera utilizzare, un certificato digitale, la chiave pubblica e un'altra stringa di byte casuali (chiamato il server casuale).
Il certificato digitale è fornito dal provider del nome di dominio del server. Il client verificherà con loro e si assicurerà che il server sia l'effettivo proprietario del dominio.
Dopo l'invio di questo messaggio, il client e il server utilizzeranno la versione TLS più alta e la suite di crittografia più sicura disponibile per entrambi.
Passaggio 3: il client genera un'altra stringa di byte casuali (chiamato segreto pre-master), la crittografa con la chiave pubblica del server e invia il risultato al server.
Passaggio 4: il server decodifica il messaggio inviato dal client con la sua chiave privata. Ora sia il server che il client hanno il segreto pre-master non crittografato.
Passaggio 5: il server e il client utilizzano il segreto pre-master, il client random e il server random per generare un'altra chiave, chiamata chiave di sessione. Dovrebbero entrambi generare la stessa chiave.
Tieni presente che la chiave di sessione è diversa dalle chiavi pubbliche/private del server. La prima è una chiave per un algoritmo simmetrico come AES, mentre le chiavi pubbliche/private sono RSA o DHE.
Passaggio 6: il server e il client si scambiano messaggi crittografati con la chiave di sessione per garantire che l'handshake abbia funzionato.
Passaggio 7: se l'handshake ha avuto successo, il client e il server utilizzeranno la chiave di sessione per il resto della sessione. Il MAC viene utilizzato insieme alla chiave di sessione per autenticare i messaggi.
Una volta stabilita una connessione sicura, non è necessario mantenere la chiave privata, la chiave pubblica o il segreto pre-master.
Invece con DHE, insieme alla chiave pubblica, il server invia un messaggio crittografato con la chiave privata per dimostrare che le due chiavi sono effettivamente associate. Il messaggio contiene una stringa nota come parametro DH. Sia il server che il client utilizzano il parametro DH per generare il segreto pre-master.