Teatralizzazione SMTP

Introduzione

Ho iniziato a studiare una teatralizzazione del protocollo di comunicazione SMTP (leggermente semplificato) con la finalità di rendere evidenti le problematiche di sicurezza legate all'utilizzo della posta elettronica come canale di comunicazione (Man-in-the-Middle, ripudiabilità del messaggio, ...) Mentre lo sviluppavo ho riflettuto sul fatto che potrebbe essere anche un buon modo per approcciare e consolidareil concetto di protocollo di comunicazione.

È sicuramente utile una (breve) introduzione al concetto di protocollo di comunicazione e comunicazione client-server. Prima di procedere con l'esercitazione vera e propria potrebbe essere utile far interpretare una comunicazione Client-Server a due studenti utilizzando l'esempio riportato di seguito.

Esempio di comunicazione SMTP

I personaggi di questa teatralizzazione di esempio sono: Client (C) e Server (S)

S: Aspetta l'arrivo di una comunicazione

C: Client si avvicina al server

S: 220 Sono il computer smtp.amicidellaposta.it

C: Ciao, io sono il computer utente.amicidellaposta.it

S: 250 Ciao utente.amicidellaposta.it, sono felice di incontrarti

C: Questa lettera è da parte di davide@amicidellaposta.it

S: 250 OK

C: Il destinatario è giorgia@corrispondenzaveloce.it

S: 251 Ok, non è uno dei miei utenti ma inoltrerò la lettera per te.

C: Ecco il contenuto della mail

S: 354 Ok, inviami in contenuto della mail. Quando finisci scrivi la sequenza: “E con questo ho finito”

C: Ciao Giorgia! È da un po' che non ci sentiamo. Come stai? E con questo ho finito

S: 250 OK: messaggio inviato

S: Interrompe la comunicazione e ricomincia ad aspettare

Scenario

Si predispone la seguente situazione. Vi sono tre server SMTP:

- "amicidellaposta.it" (A)

- "braviagestirelaposta.net" (B)

- "corrispondenzaveloce.com" (C)

Si ha che A è collegato con B e B è collegato con C. Quindi A e C possono comunicare solo tramite B.

Ogni SMTP server ha una scatola per ogni utente registrato (e la relativa password di accesso, nascosta).

Gli utenti del server A sono: carla, davide ed eugenio. Gli utenti del server B sono: davide, eugenio e francesca. Gli utenti del server C sono: carla, francesca e giorgia. NB: I nomi sono scelti in modo arbitrario. È importante che ci sia almeno uno username presente su più di un dominio.

Ogni server di posta è interpretato da uno studente. Ad altri studenti vengono date le credenziali di accesso per un account di posta.

Valori

Sono presenti nella descrizione del comportamento di server e client alcuni valori contenuti tra parentesi angolari (< e >). Tali valori vanno opportunamente sostituiti nell'applicazione del protocollo. Di seguito alcune indicazioni:

<nomeSMTPserver>: è il nome del computer sul quale risiede il server SMTP

<nomeClient>: è il nome del computer sul quale risiede il client SMTP

<mittente>@<dominio-mittente> è l'indirizzo email del mittente

<destinatario>@<dominio-destinatario> è l'indirizzo email del destinatario

Comportamento del server SMTP

Il comportamento del server è molto semplice... Resta in attesa di qualcuno che voglia parlare con lui e quando qualcuno (un client) si presenta inizia una conversazione. Il server si aspetta che la conversazione si svolga seguendo certe regole, con una sequenza di messaggi prestabilita inviati secondo un certo ordine e in linea di massima se il messaggio ricevuto non corrisponde a quello che si aspetta interrompe la comunicazione (potremmo dire che è molto suscettibile...).

La sequenza di messaggi segue questa scaletta:

1. presentazione

2. dichiarazione del mittente

3. dichiarazione del destinatario

4. invio del contenuto

Se il ciclo di operazioni viene completato il server svolgerà le operazioni di gestione della lettera ricevuta ma dato il comportamento del server non è detto che tutte le fasi possano essere svolte. Infatti se il client non rispetta le regole della comunicazione il server potrebbe decidere di interrompere la comunicazione prima del tempo.

Il server resta in attesa di una comunicazione e non esegue nessuna azione fintanto che non arriva qualcuno che vuole comunicare con lui. Di seguito viene illustrato il comportamento del server nelle diverse fasi della comunicazione.

Fase 1 – Presentazione

Questa fase comincia nel momento in cui un client si avvicina al server per comunicare.

Il server invia il messaggio: 220 Sono il computer <nomeSMTPserver>, pronto a eseguire comandi

Rimane quindi in attesa di un messaggio da parte del client con la seguente struttura: "Ciao, io sono il computer <nomeClient>". A questo punto ci sono due possibilità: il messaggio ha la struttura corretta (e viene quindi accettato) oppure ha una struttura diversa e viene rifiutato.

Se il server accetta il messaggio risponde: 250 Ciao <nomeClient>, sono felice di incontrarti e passa alla Fase 2

Altrimenti invia il messaggio: 500 Comando non riconosciuto e interrompe la comunicazione.

Fase 2 – Dichiarazione del mittente

Il server rimane in attesa di un nuovo messaggio da parte del client. Questa volta il messaggio che si aspetta ha la seguente struttura: "Questa lettera è da parte di <mittente>@<dominio-mittente>"

Se il messaggio ha la corretta struttura il server risponde: 250 OK e passa alla Fase 3

Altrimenti invia il messaggio: 500 Comando non riconosciuto e interrompe la comunicazione.

Fase 3 – Dichiarazione del destinatario

Il server rimane in attesa di un nuovo messaggio da parte del client. Il messaggio che si aspetta ha la seguente struttura: "Il destinatario è <destinatario>@<dominio-destinatario>"

Come anche nei casi precedenti se il messaggio ha una struttura differente il server risponde: 500 Comando non riconosciuto e interrompe la comunicazione.

NB: A questo punto se <dominio-destinatario> è effettivamente il dominio del server la lettera potrebbe essere arrivata a destinazione! Il server verifica quindi se <destinatario> è uno dei suoi utenti e se è così memorizzerà la lettera nella casella di posta corrispondente. Tuttavia potrebbe succedere che <destinatario> non esista! (magari a causa di un errore di digitazione...) In tal caso la mail viene rifiutata. Un altro caso è invece quello in cui il dominio del server SMTP non è <dominio-destinatario>. In tal caso il server si fa carico di inoltrare la mail verso la corretta destinazione.

Di seguito quindi le azioni eseguite dal server:

Se il dominio del server SMTP è <dominio-destinatario> allora il server controlla se esiste l'utente <destinatario> (e possono verificarsi due casi)

- Se <destinatario> esiste il server risponde: 250 OK e passa alla fase 4

- Se <destinatario> non esiste il server risponde: 450 Azione rifiutata. <destinatario> è inesistente. e interrompe la comunicazione.

Se invece il dominio del server è un altro il server risponde: 251 Ok, non è uno dei miei utenti ma inoltrerò la lettera per te. e passa alla fase 4

Fase 4 – Invio del contenuto

Il server rimane nuovamente in attesa di un messaggio da parte del client. Questa volta si aspetta che il messaggio sia esattamente: "Ecco il contenuto della mail"

Se il messaggio è diverso il server risponde: 500 Comando non riconosciuto e interrompe la comunicazione.

Altrimenti risponde: 354 Ok, inviami in contenuto della mail. Quando finisci scrivi la sequenza: "E con questo ho finito" e rimane in attesa di un messaggio da parte del client.

Tutto quello che viene trasmesso verrà interpretato come il contenuto del messaggio fino alla sequenza "E con questo ho finito"

Quando il server riceve la sequenza "E con questo ho finito" risponde: 250 OK: messaggio inviato termina la comunicazione e svolge le azioni descritte nella prossima sezione

Comunicazione terminata (E ora?)

Se la comunicazione è stata interrotta con un messaggio che inizia con il codice 500 non ci sono altre azioni da svolgere. Il server si rimette in attesa e il ciclo ricomincia.

Se invece la comunicazione è arrivata a buon fine (come si intuisce dai messaggi inviati dal server al client) potremmo trovarci in due diverse situazioni: - il destinatario è un utente che ha un account presso quel dominio (e in tal caso la mail viene memorizzata nella sua casella di posta) - il destinatario è un utente che ha un account presso un altro dominio (e in tal caso la mail viene trasmessa all'SMTP server successivo)

In entrambi i casi, terminata l'azione il server si rimette in attesa e il ciclo ricomincia.

Comportamento del client SMTP

Il comportamento del client è semplicissimo. Invia i messaggi utili all'invio di un messaggio di posta elettronica.

La sequenza di messaggi che il server si aspetta è:

1. Ciao, io sono <nomeClient>

2. Questa lettera è da parte di <mittente>@<dominio-mittente>

3. Il destinatario è <destinatario>@<dominio-destinatario>

4. Ecco il contenuto della mail

5. <contenuto> E con questo ho finito

Se il client rispetta correttamente questa sequenza il messaggio verrà inoltrato, altrimenti il server interromperà la comunicazione.

Esercizi

I seguenti esercizi sono proposti come traccia per acquisire il funzionamento del protocollo, in modo da procedere successivamente con esercizi che ne mettano in luce i limiti

Es 1: Uno studente (con un account registrato presso A) si avvicina al server A e da indicazioni di spedire un messaggio ad un altro utente (che ha un account su A).

Es 2: Uno studente (con un account registrato presso C) si avvicina al server C e da indicazioni di spedire un messaggio ad un altro utente (che ha un account su B).

Es 3: Uno studente (con un account registrato presso A) si avvicina al server A e da indicazioni di spedire un messaggio ad un altro utente (che ha un account su C).

Invio di una mail con mittente fittizio

Uno studente appositamente istruito (o il prof) si avvicina ad un server e da indicazioni di spedire un messaggio ad un altro utente dichiarando come mittente un utente diverso da se stesso.

A questo punto ci si augura che gli studenti (se non se ne erano già accorti) si rendano conto che il protocollo così come descritto non verifica l'autenticità del mittente e questo permette a chiunque di mandare mail a nome di altri utenti (anche inesistenti!!).

Autenticazione nel protocollo SMTP

Si spiega quindi che a causa di questa vulnerabilità si è deciso di introdurre l'autenticazione nel protocollo SMTP modificando lo standard originale. Viene quindi introdotta nella teatralizzazione precedentemente descritta la "Fase 1/bis" per gestire l'autenticazione e viene modificata la "Fase 1". Di seguito viene presentata la versione modificata della "Fase 1" e la "Fase 1/bis".

Fase 1 (modificata) – Presentazione

Questa fase comincia nel momento in cui un client si avvicina al server per comunicare.

Il server invia il messaggio: 220 Sono il computer <nomeSMTPserver>, pronto a eseguire comandi

Rimane quindi in attesa di un messaggio da parte del client con la seguente struttura: "Ciao, io sono il computer <nomeClient>".

A questo punto ci sono due possibilità: il messaggio ha la struttura corretta (e viene quindi accettato) oppure ha una struttura diversa e viene rifiutato.

Se il server accetta il messaggio risponde: 250 Aloha <nomeClient>, sono felice di incontrarti e passa alla "Fase 1/Bis".

Altrimenti invia il messaggio: 500 Comando non riconosciuto e interrompe la comunicazione.

Fase 1/bis – Autenticazione

Il server invia il messaggio: 334 Username:

Rimane quindi in attesa di un messaggio da parte del client. Il messaggio viene interpretato come lo username dell'utente.

Ricevuto il messaggio il server invia il messaggio: 334 Password:

Rimane quindi in attesa di un messaggio da parte del client. Il messaggio viene interpretato come la password dell'utente.

Se le credenziali di accesso corrispondono effettivamente a quelle di un utente del sistema allora il server risponde: 235 Autenticazione confermata e passa alla "Fase 2"

Altrimenti invia il messaggio: 500 Errore di autenticazione e interrompe la comunicazione.

N.B. Ho volutamente utilizzato la rappresentazione dell'autenticazione PLAIN TEXT (o base64...) perché mi sembra più logico introdurre e risolvere un problema alla volta (vedi sezione successiva)

Man-in-the-Middle

Lo step successivo è introdurre (sempre con esercizi di teatralizzazione) le problematiche legate agli attacchi di tipo Man-in-the-Middle (lettura di contenuti riservati, alterazione di messaggi), per arrivare all'importanza di individuare gli strumenti che permettano di risolvere questi problemi.

L'idea di fondo è quella di spingere i ragazzi a cercare loro una soluzione al problema della riservatezza (magari come gioco a squadre... ogni squadra deve trovare un modo di scambiare messaggi riservati tra membri del gruppo sapendo che i membri dell'altra squadra possono leggere quello che trasmettono)

Cifratura e Crittografia

L'idea in questo caso è di partire dalle codifiche più semplici (steganografia, codifiche a sostituzione monocarattere, codifiche a traslazione) per mostrare quanto siano vulnerabili e arrivare così a parlare di crittografia.

Anche in questo caso si può organizzare una sfida a squadre: vince chi decodifica per prima il messaggio segreto (es: Omini danzanti di Sherlok Holmes, rune de "Lo Hobbit", ...)

Infine si può arrivare a parlare del problema della distribuzione delle chiavi e della crittografia asimmetrica (e quindi firma digitale, etc...).