Procollo SSL: breve introduzione

Indice

Introduzione SSL 

SSL vuol dire “Secure Sockets Layer” (Livello di socket sicuri), una tecnologia standard che garantisce la sicurezza di una connessione a Internet e protegge i dati sensibili scambiati fra due sistemi impedendo a terzi di leggere e modificare le informazioni trasferite, che potrebbero comprendere anche dati personali.

HTTPS (Hyper Text Transfer Protocol Secure, Protocollo di trasferimento ipertestuale sicuro) è una dicitura visualizzata negli URL di un sito Web protetto con un certificato SSL.

Alla base del funzionamento di HTTPS risiede interamente il protocollo HTTP; per questo motivo quest’ultimo può essere criptato del tutto. La cifratura del protocollo HTTP include:

  • la richiesta URL (la pagina web che è stata richiesta)
  • i parametri di query
  • le intestazioni della connessione (headers)
  • i cookies (i quali spesso contengono le informazioni sull’identità dell’utente)

Per capire come funziona SSL  è necessario introdurre alcuni concetti di crittografia quali chiavi pubbliche e private, firme digitali, certificati digitali e autorità di certificazione.

Immaginiamo che di avere il seguente problema: Bob e Alice si devono scambiare dei messaggi in modo che, anche se questi messaggi vengono intercettati, nessuno li possa decriptare, e quindi leggere; questa operazione la possono fare solo i destinatari.

Chiavi Pubbliche e Chiavi Private

La chiave è uno strumento che ci permette di codificare o decodificare un messaggio.

In un certo tipo di crittografia, vengono generate una coppia di chiavi, per ogni soggetto coinvolto nella trasmissione dei messaggi, composta da una chiave privata e una chiave pubblica. Ci sono diversi algoritmi che lo fanno, ad esempio RSA.

La chiave pubblica, ad esempio di Bob, è una chiave nota a tutti. La chiave privata invece la conosce solo il legittimo proprietario.

Un messaggio cifrato con la chiave PUBBLICA di Bob può essere aperto solo dalla chiave PRIVATA di Bob. Quindi lo può leggere solo lui. Il problema è che chiunque può usare la chiave pubblica di Bob per cifrare quindi non sono sicuro che l’abbia spedito Alice (Autenticita non rispettata)

Un messaggio cifrato con la chiave PRIVATA di Bob può essere aperto solo dalla chiave PUBBLICA di Bob. Sono sicuro che il messaggio è stato mandato da Bob. Il problema è che chiunque abbia la chiave pubblica di Bob può leggere il messaggio (confidenzialità non rispettata)

Questa coppia di chiavi può essere usata in vario modo, come vedremo.

Firma digitale di un documento


Ipotizziamo di voler inviare un documento ad una persona, e vogliamo essere sicuri che nessuno possa manomettere il contenuto del documento.

Una soluzione è criptare il documento con la nostra chiave privata, in questo caso si parla di documento firmato.

Nella realtà per motivi prestazionali non si firma l’intero documento ma si invoca una  funzione (detta funzione  hash, a cui si passa in input il nostro documento), nota a tutti, si ricava l’impronta digitale del documento, detta anche message digest, ossia un file di dimensioni relativamente piccole (160 bit) che  contiene una sorta di codice di controllo relativo al documento stesso.


La funzione hash è fatta in modo da rendere minima la probabilità che  da testi diversi si possa ottenere il medesimo valore dell’impronta, inoltre, è one-way, a senso unico, questo significa che dall’impronta è  impossibile ottenere nuovamente il testo originario ovvero essa è non invertibile.
Dopodiché si utilizza la propria chiave privata per cifrare  l’impronta digitale: il risultato di questa codifica è la firma.  

A questo punto la firma viene allegata al documento che si vuole inviare.

Chiunque può verificare l’autenticità di un documento: per farlo, decifra la firma del documento con la chiave pubblica del mittente, ottenendo l’impronta digitale del documento, e quindi confronta quest’ultima con quella che si ottiene applicando la funzione hash al documento ricevuto. Se le due impronte sono uguali, l’autenticità e l’integrità del documento sono garantite.

Quindi quando qualcuno firma un documento garantisce che tutto quello scritto la dentro è vero. Il ricevente a modo di verificare che il contenuto non sia stato modificato durante il tragitto.

Funzionamento del protocollo SSL

Prima di analizzare il funzionamento del protocollo SSL dobbiamo chiarire come funziona la  crittografia a chiave pubblica. 

Possibile soluzione, tramite crittografia a chiave pubblica, per far comunicare Bob e Alice: entrambi avranno una chiave Pubblica, che conoscono tutti, e una chiave privata, personale e segreta.

 Il mittente codifica due volte l’informazione:

 • con la propria chiave privata
 • con la chiave pubblica del destinatario

Il destinatario deve effettuare una doppia decodifica per leggere l’informazione:

 • con la propria chiave privata
 • con la chiave pubblica del mittente

Crittografia asimmetrica - Wikipedia


Nella realtà, per motivi prestazionali, il client e il server usano questa tecnica (Handshake) per scambiarsi  una chiave simmetrica in modo sicuro e poi passano a un algoritmo di crittografia tradizionale

Certificati SSL

Abbiamo il problema della conoscenza delle chiavi pubbliche dei soggetti coinvolti nello scambio di messaggi.  Per evitare la necessità di scambiarle in anticipo, si usano certificati.

Un certificato contiene una chiave pubblica autenticata mediante la firma digitale di una Certification Authority (CA).  

Chi riceve il certificato può verificare direttamente l’autenticità della chiave pubblica usando la chiave pubblica della CA (che deve essere nota). La maggior parte dei certificati comunemente utilizzati si basa sullo standard X.509 v3.

 Il certificato quindi è la chiave pubblica di tizio, garantisce per questo chi ha emesso il certificato ossia la CA, firmandolo con la sua chiave privata

In genere i certificati contengono le informazioni seguenti:

  • il valore della chiave pubblica del soggetto
  • informazioni di identificazione del soggetto, quali il nome e l’indirizzo di posta elettronica
  • il periodo di validità (il periodo nel quale il certificato è considerato valido)
  • informazioni di identificazione dell’autorità di certificazione

I certificati (quindi le chiavi pubbliche) ritenuti “fidati” sono memorizzati in un file detto truststore.

Nel keystore (un altro file)sono memorizzate la nostra chiave pubblica e private

Autenticazione Lato Server e Lato Client

SSL supporta sia l’autenticazione lato server che quella lato client;

Nell’autenticazione lato server, il più comune, il client controlla l’identità del server verificando che il certificato personale, inviato dal server, sia firmato da una CA che riconosce; Per fare ciò deve disporre di un certificato emesso dalla CA che ha firmato la chiave pubblica del server.

Nel caso di autenticazione lato client invece, è il server che controlla l’identità del client verificando che il certificato inviato da quest’ultimo sia firmato da una CA riconosciuta.

Pertanto nell’autenticazione lato server, il client deve possedere solo il certificato della CA del server, mentre nell’autenticazione lato client deve possedere, oltre al certificato della CA del server, anche il suo certificato personale da inviare al server.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *