[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


226. SSL/TLS

SSL (Secure Socket Layer) e TLS (Transport Layer Security) sono due protocolli per la certificazione e la comunicazione cifrata. SSL è stato sviluppato originalmente da Netscape; TLS è l'evoluzione del primo, come standard pubblicato da IETF.

+-------------------+
| Applicazione      |
+-------------------+
| Presentazione     |
+-------------------+
| Sessione          |  HTTP...
+-------------------+
                       SSL/TLS
+-------------------+
| Trasporto         |  TCP/IP
+-------------------+
| Rete              |
+-------------------+
| Collegamento dati |
+-------------------+
| Fisico            |
+-------------------+

Figura 226.1: Collocazione dei protocolli SSL/TLS nel modello ISO/OSI.

Nel modello ISO/OSI, il protocollo SSL/TLS si inserisce tra il livello di trasporto (quarto) e il livello di sessione (quinto). Le sue funzionalità sono essenzialmente:

226.1 Negoziazione

Attraverso la descrizione del meccanismo di negoziazione che c'è tra cliente e servente di una connessione SSL/TLS, si intendono meglio il significato e il funzionamento di questo sistema. In generale, la negoziazione consente al servente di farsi riconoscere nei confronti del cliente, attraverso la tecnica della chiave pubblica, e attraverso questa consente alle due parti di creare una chiave simmetrica da usare per cifrare la comunicazione; inoltre, è possibile anche richiedere al cliente di identificarsi nello stesso modo in cui fa il servente.

  1. Il cliente si presenta presso il servente fornendo alcune informazioni sulla versione del protocollo che è in grado di gestire.

  2. Il servente risponde comunicando le scelte fatte in base alla disponibilità del cliente, e invia il proprio certificato; inoltre, se la risorsa richiesta prevede l'identificazione del cliente, richiede anche il suo certificato.

  3. Il cliente analizza il certificato e determina se può riconoscere o meno il servente; se l'autorità di certificazione che lo ha firmato è sconosciuta, si chiede all'utente di intervenire per decidere il da farsi.

  4. Attraverso i dati ottenuti fino a questo punto, il cliente prepara un primo esemplare dell'informazione che servirà per definire la chiave di sessione, lo cifra attraverso la chiave pubblica del servente, e lo invia.

  5. Se il servente aveva richiesto l'autenticazione da parte del cliente, verifica l'identità di questo, e se non viene riconosciuto, la sessione termina.

  6. Il servente e il cliente determinano la chiave di sessione (simmetrica), in base ai dati che si sono scambiati fino a quel momento, e iniziano la comunicazione cifrata con quella chiave.

Leggendo la sequenza di queste operazioni, si intende che la connessione cifrata può avvenire solo perché il servente offre un certificato, contenente la chiave pubblica dello stesso, attraverso la quale il cliente può cifrare inizialmente le informazioni necessarie a entrambi per generare una chiave di sessione. Di conseguenza, con questo modello, non può instaurarsi una comunicazione cifrata se il servente non dispone di un certificato, e di conseguenza, della chiave privata relativa.

Dal momento che la disponibilità di un certificato è indispensabile, se si vuole attivare un servizio che utilizza il protocollo SSL/TLS per cifrare la comunicazione, se non è possibile procurarselo attraverso un'autorità di certificazione, è necessario produrne uno fittizio in proprio.

226.2 Autenticazione del servente

Vale la pena di elencare brevemente i passi che compie il cliente per verificare l'identità del servente:

  1. viene verificato che il certificato non sia scaduto, e se la data attuale è al di fuori del periodo di validità, l'autenticazione fallisce; *1*

  2. viene verificata la disponibilità del certificato dell'autorità che ha firmato quello del servente, e se è presente si può controllare la firma, e di conseguenza la validità del certificato offerto dal servente;

  3. se il cliente non dispone del certificato dell'autorità di certificazione, e non è in grado di procurarselo e di verificarlo attraverso una catena di certificazioni, l'autenticazione del servente fallisce;

  4. infine, viene verificato che il nome di dominio del servente corrisponda effettivamente con quanto riportato nel certificato. *2*

226.3 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


1.) Si comprende l'importanza di avere un orologio del sistema funzionante e configurato in modo corretto.

2.) Questo spiega il motivo per cui, in questi casi, nel campo CN del nome distintivo di un certificato X.509 viene indicato il nome di dominio del servente.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]