24.1 SSL/TLS - Secure Sockets Layer / Transport Layer Security

Il protocollo SSL1 (Secure Sockets Layer), ideato da Netscape nel 1994 è stato standardizzato alla IETF come TLS (Transport Layer Security) e documentato dalla RFC 2246. Sebbene venga largamente utilizzato sul web (si parla in tal caso di HTTPS2, anche se sarebbe più corretto parlare di HTTP over TLS, v. RFC 2818), esso può essere utilizzato con qualunque altra applicazione per effettuare la cifratura delle informazioni scambiate.

Il protocollo TLS permette di ottenere una comunicazione sicura tra due entità per mezzo di una cifratura delle informazioni con chiave simmetrica, in modo da ridurre il carico di lavoro della CPU nella cifratura/decifratura delle informazioni stesse (gli algoritmi di cifratura/decifratura con chiave asimmetrica sono più pesanti di quelli con chiave simmetrica).

Il concetto che sta alla base del protocollo di comunicazione è piuttosto semplice. La comunicazione tra il client ed il server avviene seguendo le seguenti fasi:

  1. riconoscimento del corrispondente;
  2. scambio delle chiavi;
  3. comunicazione cifrata con le chiavi scambiate;

Al momento della connessione ha inizio la fase 1. Il client richiede al server il suo certificato digitale, che attesta (dipendentemente da quanto si ritiene affidabile la CA - Certification Authority - che ha rilasciato il certificato) che la chiave pubblica in esso presente appartiene al server stesso. Quindi il client richiede al server di dimostrare effettivamente che esso è proprio il server al quale è stato rilasciato il certificato trasmesso precedentemente. Il server prova chi dice di essere, inviando al client un semplice messaggio in chiaro, a cui allega l’impronta (message digest) del messaggio cifrata con la propria chiave privata. In questo modo il client può verificare, decifrandola con la chiave pubblica del server, che l’impronta coincide con quella del messaggio in chiaro, autenticando quindi il server.

Oltre a quanto indicato, nella fase 1 viene anche controllato che il nome con il quale viene raggiunto il server (se disponibile) corrisponda a quello indicato nel certificato digitale.

A questo punto ha inizio la fase 2. Il client genera in maniera poco prevedibile (in teoria casualmente) una chiave simmetrica, detta chiave di sessione e la invia al server cifrata con la chiave pubblica del server stesso. In questo modo soltanto il server può decifrare il messaggio ottenendo la chiave di sessione generata dal client. Quindi conferma il ricevimento della chiave rispondendo al client con un messaggio ed un MAC (un’altra impronta) il tutto cifrato con la chiave di sessione. Il client può quindi verificare se la comunicazione cifrata funziona.

Quindi, una volta che il client ed il server condividono la stessa chiave di sessione e sono gli unici a conoscerla, i due possono scambiarsi le informazioni cifrate con tale chiave.

Il progetto OpenSSL3 si prefigge lo scopo di creare e manutenere un toolkit open source per l’utilizzo di SSL/TLS in una qualunque applicazione client-server.