Il lucchetto verde demistificato: come funziona l'handshake SSL?

Ogni giorno, quando navighi sul Web con la sicurezza in mente, pensi al famoso lucchetto verde vicino all'indirizzo URL del sito web nel tuo browser e alla versione HTTPS del protocollo di trasferimento dati. In questo articolo, scopriremo perché HTTPS è davvero sicuro e come la comunicazione viene salvaguardata dalle intercettazioni di terzi.

Innanzitutto, introdurremo brevemente i due concetti crittografici di base: firma digitale e crittografia, ci immergeremo in un processo chiamato SSL handshake , che viene eseguito prima che client e server inizino a scambiare comunicazioni e viene utilizzato per stabilire un contesto crittografico sicuro. Concluderemo con le informazioni su come aumentare ulteriormente la sicurezza con un passaggio facoltativo chiamato autenticazione del certificato client.

Crittografia a chiave pubblica 101: Coppia di chiavi

Incontra Alice e Bob, due persone che hanno deciso di utilizzare metodi crittografici per scambiare i propri messaggi privati ​​in sicurezza. La prima scelta che devono affrontare è tra due diversi tipi di crittografia: crittografia a chiave simmetrica e asimmetrica (chiamata anche crittografia a chiave pubblica).

Ma aspetta, cosa sono queste chiavi ? Fondamentalmente, possiamo semplificare che una chiave è una sequenza casuale di caratteri. Possiamo usare questa sequenza per trasformare (eseguire una certa operazione crittografica) su un messaggio: lo analizzeremo presto.

Crittografia a chiave simmetrica

Quando si utilizza la crittografia a chiave simmetrica, un mittente genera una chiave e quindi la duplica per il destinatario. Il mittente salva la chiave originale e un duplicato viene consegnato al destinatario. La stessa chiave viene utilizzata per le operazioni di crittografia su entrambe le estremità della comunicazione.

E quali sono i principali vantaggi e svantaggi della crittografia a chiave simmetrica?

Crittografia a chiave asimmetrica

Quando si utilizza la crittografia a chiave asimmetrica, sia il mittente che il destinatario generano una coppia di chiavi : una chiave pubblica e una chiave privata. Le chiavi sono accoppiate matematicamente tra loro per lavorare insieme in varie operazioni crittografiche. Sia il mittente che il destinatario salvano le proprie chiavi private in modo sicuro, ma possono scambiarsi chiavi pubbliche senza particolari precauzioni. Possono persino utilizzare una sorta di "pagine gialle delle chiavi pubbliche": un server di chiavi pubbliche per inviare le proprie chiavi pubbliche affinché siano accessibili a chiunque.

Quali sono i pro ei contro della crittografia a chiave asimmetrica?

Poiché una configurazione crittografica asimmetrica è più sicura, Alice e Bob hanno deciso di seguirla! Ora possono sfruttarlo e iniziare a pensare a garantire la sicurezza e l'integrità della comunicazione.

Crittografia a chiave pubblica 101: Crittografia

Quando Alice invia un messaggio a Bob, vuole essere sicura che nessun altro possa vedere qual è il contenuto. Decide di crittografare il messaggio. Per ottenere ciò, Alice deve prima ottenere la chiave pubblica di Bob da un server di chiavi o direttamente da Bob tramite un canale di comunicazione. Una volta ottenuta la chiave, Alice può applicare un'operazione di crittografia utilizzando la chiave pubblica di Bob sul messaggio che desidera inviare.

In generale, in questo processo, il messaggio viene preso da un algoritmo crittografico (noto anche come cifra) in blocchi (più comunemente) e vengono eseguite alcune operazioni di bit tra il messaggio e la chiave, producendo un output che è il messaggio crittografato (noto anche come testo cifrato) . Quando Bob riceve il messaggio crittografato, è l'unica persona che può decrittografarlo con la sua chiave privata.

Nota:

• Crittografia del messaggio : il mittente crittografa un messaggio con la chiave pubblica del destinatario
• Decrittografia del messaggio : il destinatario decodifica un messaggio con la propria chiave privata

Crittografia a chiave pubblica 101: Firma

Oltre a impedire che il contenuto del messaggio venga rivelato, è altrettanto importante poter confermare l'identità del mittente e verificare se il messaggio non è stato modificato. Una firma digitale (un oggetto separato allegato al messaggio) viene utilizzata esattamente per questi due motivi.

Alice utilizza prima un algoritmo di hashing per sviluppare un hash del messaggio per generare la sua firma. L'hashing sta calcolando una funzione matematica unidirezionale su un messaggio che produce un output di valore fisso più breve, diverso per un input diverso. Quindi usa la sua chiave privata per crittografare (firmare) l'hash generato.

Successivamente, quando Bob riceve il messaggio e la firma, può prima decrittografare la firma utilizzando la chiave pubblica di Alice. Quando riesce, sa che la firma è stata davvero generata da Alice (altrimenti, la decrittazione con la sua chiave pubblica fallirebbe).

In secondo luogo, Bob può prendere il messaggio ed eseguirne l'hashing usando lo stesso algoritmo che Alice aveva prima e confermare che il suo hash del messaggio è lo stesso di quello generato da Alice. Quando gli hash corrispondono, sa che il messaggio non è stato manomesso.

Nota:

• Generazione della firma : il mittente crittografa (firma) l'hash del messaggio con la sua chiave privata e crea una firma
• Verifica della firma : il destinatario prima decifra l'hash del messaggio dalla firma e controlla se un hash da lui calcolato corrisponde a quello della firma
• La crittografia e la firma possono essere utilizzate separatamente , ma per la massima sicurezza, di solito sono combinate. Pertanto, la maggior parte delle funzioni crittografiche che puoi incontrare sono chiamate encryptSignMessage() , decryptVerifyMessage() , ecc.

Spero che tu non abbia problemi a tenere il passo con la storia di Alice e Bob. Permettetemi di illustrare ancora una volta l'intero flusso per garantire che tutto sia chiaro e per riassumere le cose.

1. Alice vuole inviare un messaggio a Bob
2. Alice prende la sua chiave privata e genera una firma
3. Alice prende la chiave pubblica di Bob e crittografa il messaggio
4. Alice invia il messaggio a Bob
5. Bob prende la chiave pubblica di Alice e verifica la firma
6. Bob usa la sua chiave privata per decifrare il messaggio

Va bene, è abbastanza teoria. Ora vediamo come tutto questo viene utilizzato in HTTPS!

Stretta di mano SSL

Saluta per favore

Quando un client avvia una connessione a un server, è innanzitutto fondamentale fare un'introduzione adeguata per stabilire il contesto crittografico per il resto della comunicazione. Questo può essere fatto nel passaggio HTTPS CONNECT, molto prima di analizzare le intestazioni e i corpi delle richieste. Tutto inizia con il client che invia un messaggio di saluto al client .

Ancora più importante, il messaggio contiene gli algoritmi crittografici che il client comprende e del materiale aggiuntivo, come algoritmi di compressione supportati, versioni di protocollo, ID sessione, ecc. Poiché al server piace essere educato, risponde anche con un messaggio di saluto del server che in particolare contiene il certificato del server con la chiave pubblica del server (sì, il processo si basa sulla crittografia a chiave pubblica, lo stesso metodo scelto da Alice e Bob).

Autorità di certificazione

Ora è il momento di dare il benvenuto al nostro prossimo ospite sul palco: un'autorità di certificazione (CA). Il nome sembra serio, ma è solo un'entità di terze parti con molto credito di strada che è sostanzialmente considerata affidabile in tutto il mondo. Tale entità può convalidare l'identità di un server e apporre la sua firma digitale insieme al certificato del server (in modo simile ad Alice quando invia messaggi a Bob).

Verifica del certificato

Ora consideriamo finalmente il titolo lucchetto verde accanto all'indirizzo URL del tuo browser.

Ciascun client Web dispone di un elenco raggruppato di chiavi pubbliche delle autorità di certificazione note e attendibili. Potresti ricordare che all'inizio dell'articolo ho menzionato che la firma viene generata utilizzando la chiave privata di un mittente e può essere verificata utilizzando la chiave pubblica di un mittente. Bene, questo è esattamente ciò che fa il cliente . Esamina l'elenco delle CA attendibili in bundle e controlla se la firma del certificato del server appartiene a una delle CA attendibili. Se lo fa, accetta il certificato – ed è il momento in cui il lucchetto diventa verde .

Ma questo è solo un primo passo, che non ha ancora nulla a che fare con la sicurezza. Chiunque può copiare qualsiasi certificato di chiave pubblica, inserirlo su un server e presentarlo a un client di connessione, giusto?

Dopo che il client ha verificato il certificato del server, crea una chiave simmetrica per crittografare la comunicazione. Ma, come ho detto all'inizio, il problema con le chiavi simmetriche è che sono vulnerabili all'intercettazione durante il trasporto. In questa fase, client e server non hanno un contesto crittografico comune. Quindi il client invia la chiave simmetrica al server, ma prima la crittografa con la chiave pubblica del server. Quindi il server lo riceve e ha bisogno della capacità di decrittografarlo per stabilire una connessione sicura.

Pertanto, anche se qualcuno presentasse un certificato di chiave pubblica rubato , questo è il passaggio che fallirebbe. Una chiave privata valida associata alla chiave pubblica del certificato del server è essenziale per decrittografare la chiave simmetrica. Ovviamente, questo non è un problema per un server legittimo in quanto la chiave privata è salvata in modo sicuro. Può essere utilizzato per decrittografare la chiave simmetrica e crittografare ulteriori comunicazioni.

Quindi, per riassumere, un handshake SSL è un processo in cui vengono utilizzati sia i tipi di crittografia simmetrica che asimmetrica . Inizialmente, la coppia di chiavi asimmetriche avvia la connessione e fornisce un modo sicuro per far viaggiare la chiave simmetrica. Come abbiamo sottolineato all'inizio, le operazioni di crittografia simmetrica sono più veloci, quindi utilizzarla per l'intera comunicazione dopo l'installazione è vantaggioso. Inoltre, una volta stabilita una connessione sicura, viene riutilizzata fino alla scadenza, quindi l'impostazione della chiave asimmetrica non viene eseguita prima di ogni richiesta del client.

Vale anche la pena ricordare che nella vita reale i certificati non vengono firmati direttamente dalle più famose CA fidate (chiamate root ). Tuttavia, le CA radice firmano i certificati intermedi, che poi alla fine firmano il certificato del server, creando così una catena di certificati, che il client di connessione controlla fino a quando non viene soddisfatta una firma valida. Fornisce sicuramente una maggiore sicurezza: quando una delle CA intermedie viene compromessa, colpisce meno persone.

Convalida del certificato del cliente

Ora, c'è un passaggio facoltativo che possiamo menzionare brevemente, poiché abbiamo tutte le conoscenze necessarie per capirlo. Un server può essere configurato per richiedere e convalidare un certificato client dopo aver stabilito una connessione sicura per ottenere una sicurezza aggiuntiva.

Funziona allo stesso modo, ma questa volta il client invia il proprio certificato e il server esamina l'elenco delle autorità di certificazione attendibili e lo verifica. Vale anche la pena notare che il server è sotto il controllo degli sviluppatori (opposto a un client, ad esempio un browser web o un sistema operativo mobile), quindi gli sviluppatori backend possono modificare facilmente l'elenco dei certificati attendibili.

Le reti aziendali usano comunemente questo meccanismo. Nella maggior parte dei casi, i certificati client sono generati da un sistema di gestione dei dispositivi installato sul dispositivo del dipendente e sono firmati con un certificato radice generato dall'azienda. Lo stesso certificato viene aggiunto anche all'ambiente di back-end. In questo modo, il back-end aziendale può verificare facilmente il certificato quando il client si connette.

Esaminiamo le nostre soluzioni di back-end

Leggi di più

Ora, per riassumere, vediamo un diagramma per l'intero flusso:

Riepilogo

Sei arrivato alla fine dell'articolo! Si spera che tu abbia già compreso il meccanismo di implementazione della configurazione della crittografia in HTTPS e i metodi applicativi dei processi di firma e crittografia.

Dal momento che sai come funzionano le cose, dovresti sicuramente sentirti più sicuro della crittografia dei dati. Tuttavia, è essenziale ricordare che un lucchetto verde nel tuo browser non garantisce ancora la sicurezza . Nel contesto sensibile alla sicurezza, dovresti anche esaminare attentamente il certificato. Come si suol dire, avvisato è avambrato!