WiKi ULI

Utilizzando algoritmi crittografici, i protocolli proteggono lo scambio che avviene tra client e server.
Nell'ambito delle comunicazioni web, la crittografia assume un'importanza sempre maggiore. Lungo le varie dorsali viaggiano sempre più spesso dati rilevanti e informazioni riservate: da quelli personali alle informazioni bancarie, passando per le credenziali di accesso ai vari servizi web e molto altro. Tra le modalità maggiormente utilizzate per criptare e quindi proteggere questi dati troviamo il protocollo SSL/TLS.

Il protocollo SSL/TLS

Nato dalle ceneri del Secure Sockets Layer (SSL), il Transport Layer Security (TLS) è un protocollo di crittografia utilizzato in ambito web per proteggere le comunicazioni e lo scambio informativo tra due nodi della Rete (solitamente tra client e server). La protezione è affidata all'utilizzo di certificati crittografici asimmetrici, come lo X.509, e allo scambio di chiavi di sessione simmetriche.
Affinché il sistema di certificazione basato sullo X.509 possa funzionare, è necessaria la presenza di una o più autorità di certificazione (Certificate Authority in inglese) e di un'infrastruttura a chiave pubblica per verificare la relazione tra il certificato e il suo possessore, così come per generare, firmare e amministrare la validità dei certificati. Da un punto di vista della sicurezza, però, questa architettura presenta non poche pecche: le cosiddette “divulgazioni sulla sorveglianza di massa del 2013” hanno mostrato come le autorità di certificazione siano l'anello debole della catena e non siano in grado di impedire attacchi del tipo man-in-the-middle (“Uomo nel mezzo” in italiano).

Come funziona il protocollo SSL/TLS

Il protocollo SSL/TLS permette ad applicazioni client/server di comunicare per mezzo di una rete in modo da prevenire l'eavesdropping (“origliare”) e il tampering (“manomettere”).
Dal momento che la comunicazione tra due nodi della rete può avvenire anche senza l'utilizzo di protocolli crittografici, è necessario che il client indichi al server di stabilire una connessione protetta per lo scambio informativo. La prima opzione prevede l'utilizzo di una porta differente rispetto alla solita (nel caso del protocollo HTTPS viene utilizzata la porta 443, mentre il protocollo HTTP utilizza la porta 80); una seconda opzione, invece, prevede l'utilizzo di un meccanismo ad hoc da parte del client affinché il server attivi la modalità crittografata. Una volta che i due nodi si sono accordati sull'utilizzo del protocollo SSL/TLS, comincia una procedura di negoziazione per stabilire una connessione affidabile. Durante la procedura, client e server concordano i diversi parametri necessari a stabilire l'effettiva sicurezza del processo.

  • Nella prima fase, client e server si scambiano diversi dati, inclusi la versione del protocollo utilizzata, le impostazioni di cifratura, dati specifici della sessione in fase di avvio e altri informazioni necessarie ai due nodi per comunicare tra loro
  • Il client utilizza queste informazioni per autenticare il server – nel caso della navigazione web, ad esempio, il client controlla se “l'intestatario” del certificato crittografico ricevuto corrisponde al server contattato e se l'autorità di certificazione sia o meno affidabile
  • Utilizzando tutti i dati scambiati sinora, il client crea il cosiddetto pre-master session (piccola porzione di dati condivisa esclusivamente tra i due nodi interessati alla comunicazione) relativo allo scambio in corso, lo crittografa con la chiave pubblica ricevuta dal server e lo invia al server stesso
  • Nel caso in cui il server lo richieda, il client invia una firma autenticativa per certificare la propria identità. Nel caso in cui l'identificazione vada a buon fine, il server decripta il pre-master session inviato e genera il master secret. Se il server non identifica il client, la sessione viene interrotta
  • Sia il server sia il client utilizzano il master secret per generare la chiave (simmetrica) di sessione. Questa chiave viene utilizzata nel corso della comunicazione per crittografare e decriptare i dati inviati dai due nodi e per verificarne l'integrità
  • I due nodi inviano un ultimo messaggio indicando che la procedura di negoziazione è terminata e tutti i futuri messaggi saranno crittografati utilizzando la chiave di sessione appena negoziata

Leggi tutte le altre WiKi di ULI qui.
© 2018 Utility Line Italia srl | Professional Internet Service Provider

Search

Questo sito raccoglie dati statistici anonimi sulla navigazione, mediante cookie installati da terze parti autorizzate, nel rispetto della tua privacy e dei tuoi dati. Cookie Policy