Lo strato applicativo di Internet

Utilizzo dei Meccanismi di Sicurezza

• SSH
  
  • Autenticazione del server
  • Il proprio server ssh
  • Confidenzialità
  • Autenticazione del client
  • Passiamo nel tunnel
  • Grafica remota
• TLS
• Openssl
  • Creazione di una Certification Autority
    • Impostazione di Dovecot all'uso del nuovo certificato
  • Richiesta di un nuovo certificato firmato
  • Firma del certificato
  • Interfacce grafiche
    • Gestione ed utilizzo dei certificati con TinyCA
• La nostra piccola PEC
• Virtual Private Network - VPN
• Gnu Privacy Guard
  • Interfaccia testuale
  • Seahorse
  • Keyserver
  
  

SSH

Fin dagli albori di Internet, si è potuti entrare su di un altro computer, usando il comando Telnet per collegare standard input ed ouput locali, ad una sessione terminale remota. Questa modalità operativa soffre però di alcune ingenuità legate al fatto che ai tempi in cui Telnet fu definito, Internet era confinata al mondo accademico e della ricerca, per cui

• nella la fase di autenticazione iniziale la password viene trasmessa in chiaro
• non è previsto un modo per crittografare la comunicazione

A partire dal 1995, si è lavorato ad un diverso metodo di connessione remota, crittograficamente sicuro, ed il risultato, noto come Secure SHell, è stato formalizzato in una serie di documenti emessi dal gruppo di lavoro SECSH di IETF, brevissimamente riassunti qui. L'implementazione più diffusa sui sistemi Unix, è quella offerta dal progetto OpenSSH, e prevede l'esecuzione di un applicativo server (sshd) in ascolto in TCP sulla porta ben nota 22, e di un programma client (ssh), da invocare da parte di chi vuol connettersi. Per funzionare, non pretende l'esistenza di una PKI, ma si basa sulla autenticazione a chiave pubblica delle due parti in comunicazione, e sulla generazione estemporanea di chiavi simmetriche di sessione.

Autenticazione del server

Questo aspetto è per così dire simmetrico a quello della autenticazione del client: se infatti il client fornisse le sue credenziali, anziché al server a cui si rivolge, ad un man in the middle impostore, oltre a non riceverere il servizio richiesto, il client avrebbe anche svelato la sua identità, e la sua password. Per questo, occorre stabilire un modo per permettere al server di dimostrare la sua identità.

Quando ci si collega in ssh ad un computer remoto per la prima volta, ci viene chiesto se accettare o meno la chiave pubblica del server, identificata da una fingerprint. In linea di principio, si dovrebbe contattare in modo sicuro (ad es, per telefono) l'amministratore del server e chiedergli di leggere la fingerprint della sua chiave pubblica, in modo da verificarne l'uguaglianza.

Nel caso in cui si decida di fidarci della chiave pubblica, questa viene memorizzata, assieme al nome del computer, nel file ~/.ssh/known_hosts.

Le volte successive che ci collegheremo, se il server continua a fornire la stessa chiave pubblica, e che ora corrisponde alla versione memorizzata dal lato client, non ci verrà più chiesto se accettare o meno l'autenticità della parte remota. Viceversa, se la chiave pubblica del server fosse cambiata, ci verrà impedito di collegarci, nel dubbio che qualcun altro stia impersonando il server remoto. Se siamo sicuri che il server sia proprio lui, e che la nuova chiave è anch'essa autentica, allora la cosa più semplice e rapida da fare per poter entrare, sarà quella di cancellare il file ~/.ssh/known_hosts.

Il proprio server ssh

Non è installato di default con Ubuntu-desktop, ed occorre prelevarlo impartendo sudo apt-get install openssh-server; dopo la generazione delle chiavi RSA e DSA, si metterà subito in funzione. Un comando che consente di conoscere la fingerprint della propria chiave pubblica RSA (che dal lato server è memorizzata nel file ssh_host_rsa_key.pub presente nella directory /etc/ssh), in modo da poterla confrontare con quella dichiarata (al lato client) al momento del collegamento, è

che, dopo aver indicato la lunghezza in bit della chiave, ne calcola appunto la fingerprint. D'altra parte, un metodo sicuramente meno macchinoso, è quello di provare a connettersi direttamente al proprio server!

Confidenzialità

Come risulta da questo file di cattura, prima ancora che venga svolto il dialogo relativo alla chiave del server, il protocollo ha già provveduto ad instaurare una connessione sicura, mediante uno scambio di Diffie-Hellman. Osserviamo che il ritardo di 8 secondi che intercorre tra il pacchetto 17 ed il pacchetto 18, corrisponde al tempo impiegato per rispondere alla domanda se continuare la connessione o meno. Quindi, tutto quel che segue risulta protetto da una chiave di sessione simmetrica.

Autenticazione del client

Avendo conseguito la confidenzialità della comunicazione, la trasmissione della password dell'utente verso il sistema remoto viene effettuata in forma crittografata dallo strato di sicurezza di SSH. Alternativamente, la richiesta della password può essere evitata, qualora la chiave pubblica del client venga memorizzata presso il server, in modo che quest'ultimo possa verificare autonomamente l'identità del client.

Passiamo nel tunnel

In effetti, lo scopo di ssh non si limita al solo accesso ad una shell remota, ed una delle sue caratteristiche più interessanti consiste nella possibilità di realizzare dei tunnel sicuri tra computer, ridirezionando servizi basati su socket, da uno all'altro. Ad esempio, se un programma server sshd è in ascolto sulla porta 22 del computer hostB, e presso hostA si impartisce il comando

allora viene creato un tunnel ssh dal computer hostA verso hostB, che resta in ascolto (-L) su p^A di hostA, mettendola in comunicazione con p^B di hostB, in modo che connettendosi a p^A di hostA ci si ritrova a dialogare con un servizio in ascolto su p^B di hostB, avendo crittografato il traffico tra i due, e raggiungendo effettivamente hostB sulla porta 22 su cui ascolta sshd, che provvede a sua volta a connettersi (localmente) a p^B di hostB. In questo modo, è possibile ad esempio scavalcare eventuali limitazioni imposte da firewall intermedi.

Grafica remota

Una opzione molto simpatica di ssh, è quella (opzione -Y) che consente di visualizzare sul proprio computer la finestra di esecuzione di una applicazione grafica (ad es. nautilus) lanciata sul computer su cui ci si è collegati. Inoltre, si può specificare (opzione -l) di presentarsi sul computer remoto con una UserID differente da quella impersonata sul proprio computer. Queste due opzioni, combinate assieme, producono il comando generico

che ci permette appunto di eseguire programmi presso computerremoto, con l'identità di utenteremoto, e di visualizzare la relativa finestra sul nostro schermo. La cosa ancora più divertente, è che in questo caso funziona anche il copia e incolla tra le finestre del computer remoto, e quelle del computer locale, dato che entrambe sono visualizzate dallo stesso desktop.

TLS

Come illustrato a lezione, il TLS è uno strato frapposto tra l'applicazione ed il TCP, che permette di autenticare l'altra parte mediante certificati X.509 e relativa fingerprint, e di negoziare dinamicamente una chiave di sessione a crittografia simmetrica, in modo da garantire la confidenzialità della comunicazione. Riprendendo l'esempio svolto in merito alla attivazione del TLS nel contesto di una connessione IMAP, proviamo ad analizzare più in dettaglio il risultato del capture ottenuto.

Osserviamo che dopo che nei pacchetti 9-10 il client ed il server IMAP si sono accordati per utilizzare il TLS, il capture non è più in grado di decodificare correttamente quanto accade. E' però possibile istruire Wireshark affinché tenti di interpretare i pacchetti come la fase iniziale di una comunicazione TLS. Per ottenere questo, occorre posizionarsi con il mouse su di un pacchetto TLS, cliccare con il tasto destro, e scegliere l'opzione decode as; quindi, specificare che le due porte utilizzate agli estremi della comunicazione (in questo caso, la 143 che è la porta ben nota di IMAP, e 45238, che è una porta effimera) identificano pacchetti SSL (il predecessore del TLS).

A questo punto, l'aspetto del capture cambia completamente, e si possono apprezzare i passaggi previsti dall'handshake protocol. Inoltre, possiamo notare ad esempio come, nel pacchetto TCP 12, trovano posto 4 diverse PDU del TLS.

Ulteriori dettagli possono essere apprezzati, espandendo ulteriormente i contenuti delle PDU TLS.

Openssl

Si tratta di un toolkit OpenSource, cresciuto sulle fondamenta gettate da un altro, che oltre ad implementare gli strati di sicurezza SSL e TLS, offre una potente libreria crittografica che implementa praticamente tutti gli algoritmi di cui si può aver bisogno, e che viene usata da un gran numero di applicazioni crittografiche. Inoltre, è disponibile il comando openssl, che permette l'esecuzione di quasi tutte le operazioni crittografiche a partire da una finestra terminale. Un progetto del tutto analogo, ma sviluppato in accordo ad una licenza più liberale, è GnuTLS.

Dato che il comando openssl, per la ricchezza delle sue possibilità, può richiedere un pò troppa pazienza prima di individuare cosa occorre fare per svolgere delle operazioni ben precise, alcune sue funzionalità posso essere accedute per mezzo di interfacce grafiche e web. In particolare, le operazioni relative alla gestione di una Certification Authority, posso essere svolte per mezzo dello script perl CA.pl, come descritto in questo HowTo, ripreso appresso.

Creazione di una Certification Autority

Lo script CA.pl non si trova nel path, e quindi per generare la nostra CA, eseguiamo

e possiamo verificare ora l'esistenza di una directory demoCA nella nostra home, con il frutto del nostro lavoro. Possiamo già ora, provare ad utilizzare questo certificato auto-firmato per Dovecot, al posto di quello di snakeoil.

Impostazione di Dovecot all'uso del nuovo certificato

Per questo, copiamo il certificato e la chiave privata nella directory che viene letta da Dovecot, con

e modifichiamo /etc/dovecot/dovecot.conf in modo che utilizzi i nuovi files

Se ora ci ri-colleghiamo con Evolution, vediamo comparire il nuovo certificato. Se controlliamo il file di log, troviamo

Richiesta di un nuovo certificato firmato

Ora, passiamo a compilare una Richiesta di Certificato di Utente, con il comando /usr/lib/ssl/misc/CA.pl -newreq. Essendo un certificato individuale, ognuno potrà inserire i propri dati, ottenendo come risultato, due files:

che risiedono entrambi nella nostra home directory.

Firma del certificato

Possiamo scegliere di far emettere il certificato per il quale abbiamo generato la richiesta, alla nostra stessa CA, oppure di farlo firmare da una stessa CA centralizzata, che firmerà anche quelli dei nostri colleghi, e che provvederà a distribuire la propria chiave pubblica in modo fidato. Ad ogni modo, il comando per firmare una richiesta di certificato da parte di una CA, è

Come affermato, il certificato si trova in ~/newcert.pem, dove troviamo anche la sua corrispettiva chiave privata newkey.pem (se abbiamo usato la nostra stessa CA). Inoltre, il nuovo certificato si trova anche nella directory ~/demoCA/newcerts, dove è conservato assieme agli altri che verranno emessi, ed a quello emesso per la CA stessa; i certificati sono contrassegnati da un numero seriale crescente, e che corrisponde a quello presente all'interno del certificato stesso. La chiave privata invece, si trova ancora in ~/newkey.pem, dove è stata generata dal comando precedente.

Interfacce grafiche

Anziché eseguire dei comandi da terminale, le operazioni associate ad una CA possono esere svolte utilizzando degli strumenti grafici, come ad esempio quelli di TinyCA, e gnoMint (in effetti, sebbene nel seguito si faccia rierimento al primo, il secondo è più aggiornato). Inoltre, le operazioni di richiesta e di ritiro di un nuovo certificato, possono anche essere svolte interagendo con una CA remota, come nel caso dell'utilizzo di una interfaccia web, ad esempio quella offerta da PyCA e OpenCA.

Gestione ed utilizzo dei certificati con TinyCA

Allo scopo di semplificare il procedimento rispetto a quello necessario utilizzando OpenSSL, installiamo TinyCA mediante il comando

e lanciamolo invocando tinyca2. A questo punto, mediante l'interfacia grafica, è semplice

• generare una nuova CA - che potremmo chiamare nostronomeCA
  • ricordiamoci la password della CA, necessaria a crittare/decrittare la chiave privata della nostra CA!
• creare un nuovo certificato che useremo per il nostro server IMAP Dovecot, usando come Distinguished Name il nome a dominio di secondo livello nel nostro computer, ossia nostronome.labint. Anche stavolta, ricordiamoci la password necessaria per accedere alla chiave privata di questo nuovo certificato!
• notiamo come usando TinyCA, la richiesta di un nuovo certificato sottintende i passi di
  • generazione chiavi
  • compilazione della richiesta
  • accettazione della stessa
  • firma ed emissione del certificato da parte della CA
• esportiamo il certificato creato per ultimo, in formato PEM, includendo nello stesso file anche la chiave privata
• impostiamo Dovecot per utilizzare il nuovo certificato, copiando il file .pem dalla nostra home directory in /etc/ssl/certs/, e modifichiamo il file di configurazione di Dovecot, come suggerito da queste istruzioni
  • dato che certificato e chiave sono nello stesso file, usare quello stesso nome in tutti e due i casi
  • ricordiamoci di decommentare anche la linea in cui va inserita la password necessaria ad usare la chiave privata
• mantenendo attivo Wireshark sulla porta 143, lanciare Evolution impostandolo in modo che l'accesso al server IMAP sul proprio computer (127.0.0.1) sia reso sicuro mediante TLS
• verificare nella richiesta di consenso proposta da Evolution, così come nel capture, che sia stato effettivamente usato il certificato da noi fornito per ultimo

La nostra piccola PEC

La Posta elettronica certificata si propone come forma di comunicazione autenticata nei confronti della pubblica amministrazione, ed al dilà delle particolarità politico-giuridiche, si basa (anche) sulla definizione di una PKI in grado di emettere certificati digitali X.509 da usare nel quadro delle normative S/MIME. Il risultato ufficiale di questa armonizzazione è stato quindi documentato nella pubblicazione della RFC 6109. Dal canto nostro, ci interessa mostrare come procedere per utilizzare le estensioni di sicurezza disponibili su client email come Evolution o Thunderbird in accordo ad S/MIME, mentre più avanti discutiamo della adozione di PGP.

Innanzitutto creiamo una richiesta di certificato (CSR - Certificate Signing Request), ed implicitamente una coppia di chiavi, usando direttamente le opzioni permesse da Openssl:

che ci porrà alcune domande, a cui possiamo rispondere come già indicato in precedenza, usando il proprio nome vero e l'indirizzo email labint@nome.labint valido nell'ambito del laboratorio. Come risultato, troviamo due files nella stessa directory da cui abbiamo eseguito il comando, nome.csr con la richiesta di firma, e nome.key con la propria chiave privata (crittografata con la passphrase).

La firma del certificato deve ora essere apposta da una unica CA comune a tutti, in esecuzione presso ns.labint. Trasferiamo quindi li le nostre richieste, per mezzo del supporto che Nautilus offre ad SSH, inserendo nella barra degli indirizzi la URI ssh://labint@ns.labint: dopo aver inserito la password dell'utente labint, possiamo navigare nel filesystem del computer remoto, recarci nella directory /home/labint/pec/reqs, e copiare (trascinandolo da una diversa finestra di Nautilus) il file con la propria richiesta, nella cartella remota. A questo punto attendiamo che qualcuno su ns.labint esegua (ad es.) Gnomint, e firmi tutte le richieste pervenute, usando la chiave pubblica di una CA (labintCA) definita per l'occasione.

Il certificato firmato può quindi essere ritirato presso la directory /home/labint/pec/cert di ns.labint, copiando (trascinando) il file nome.pem presso il proprio computer. Già che ci siamo, copiamo sul proprio computer anche il certificato auto-firmato della CA, che si trova nel file labintCA.pem presente sempre nella stessa directory, e che useremo in seguito. Prima di poter fornire il nostro certificato nome.pem al nostro Mail User Agent, occorre ri-associarvi la propria chiave privata, e rappresentare il tutto nel formato pkcs12: più semplice a farsi che a dirsi, impartendo il comando

Evolution

Volendo utilizzare questo MUA, possiamo ora discendere nella colonna sinistra delle preferenze di Evolution, fino a certificati, e nella linguetta di quelli personali, richiedere l'importazione del file nome.pkcs12 prodotto al passo precedente. Vengono chieste due password: la prima è quella del portafoglio dei certificati, e se è la prima volta che viene chiesta, sarà bene fare attenzione a ricordarsela; la seconda è la passphrase che abbiamo messo a protezione della propria chiave privata, e che (la passphrase) verrà consevata crittografata mediante la password generale del portafoglio.

Da questo momento in poi possiamo firmare (con la nostra chiave pubblica) i messaggi che inviamo, ed allegarvi il proprio certificato in modo che chi riceve vi possa leggere la nostra chiave pubblica, ed usarla per verificare la nostra firma digitale. Si, ma... perché l'autenticazione sia valida, occorre accertarsi che il certificato sia valido, ossia verificare la firma apposta dalla CA, e quindi... occorre tornare ancora nella finestra delle preferenze di Evolution, accedere allo schermo Certificati/Autorità, ed importare il certificato della CA labintCA.pem prelevato in precedenza. A questo punto compare una nuova finestra che chi chiede per quali compiti consideriamo idonea questa CA: possiamo tranquillamente reputarla idonea per tutto!

Prima di poter inviare messaggi firmati, occorre impostare le preferenze di Evolution per quanto riguarda la nostra identità labint@nome.labint, cliccando sulla linguetta "sicurezza", e selezionare così quale certificato usare sia per la firma, che per la crittazione. Ne abbiamo solo uno, la scelta non è difficile! Finalmente, possiamo inviare una email firmata: è sufficiente selezionare la casella firma S/MIME disponibile dal menù Opzioni della finestra di composizione della email. Notiamo che non ci viene chiesta la passphrase necessaria a decifrare la nostra chiave privata, perché questa stessa passphrase è stata salvata in forma crittografata con la password generale del portafoglio, che ci è stata già chiesta una volta; ad una nuova apertura di Evolution, l'atto di invio di una email firmata determina quindi la richiesta della password del portafoglio.

Infine, notiamo che non ci è possibile inviare una email crittografata verso un soggetto dal quale non abbiamo ancora ricevuto nessun messaggio firmato: solo in questo caso infatti veniamo in possesso del suo certificato (da cui possiamo leggere la chiave pubblica necessaria ad attuare la riservatezza), che ritroviamo poi elencato nella scheda di Evolution Preferenze/Certificati/Contatti.

Thunderbird

Con questo User Agent la gestione dei certificati è attuata mediante l'opzione Modifica/Preferenze, quindi scegliendo nella nuova finestra la categoria Avanzate, di lì la linguetta Certificati, e quindi Mostra Certificati, che determina l'apertura di una nuova finestra. A questo punto, aprendo la linguetta Certificati personali possiamo importare il nostro certificato firmato, mentre sotto la linguetta Persone possiamo importare quelli dei nostri corrispondenti; infine, la linguetta Autorità elenca i certificati della CA preinstallati in Thunderbird, a cui possiamo aggiungere quello che certifica la nostra piccola PEC.

Per inviare una email firmata, dopo aver aperto la finestra di composizione, scegliamo Opzioni/Apponi firma digitale, che ci chiede di indicare il certificato da usare, aprendo la finestra di Impostazione account relativa al mittente che intendiamo usare. Qui possiamo specificare il certificato recentemente importato, che verrà accettato solo se rilasciato allo stesso indirizzo email.

Virtual Private Network - VPN

Come abbiamo visto, i servizi di crittografia IPSEC che operano allo strato di rete possono essere utilizzati per realizzare una VPN. Una guida alla configurazione della VPN per un sistema Ubuntu è fornita presso il sito della documentazione prodotta dagli utenti.

Gnu Privacy Guard

La GNU Privacy Guard (o GPG) è una implementazione Open dello standard OpenPGP descritto nella RFC 4880, e che offre servizi di crittografia per la trasmissione sicura delle email, in grado di ottemperare ai requisiti 5), 6) e 7) elencati nella lista descritta precedentemente. Di base GPG offre uno strumento usabile da linea di comando, ma presso il sito di GPG sono documentate le estensioni disponibili, sia per la sua gestione grafica che per l'integrazione con altre applicazioni, come i client email.

Interfaccia testuale

Il comando da inserire da tastiera per eseguire tutte le operazioni possibili per OpenPGP è gpg, ed anche se la relativa pagina di manuale descrive una quantità di opzioni possibili, le operazioni più comuni (gestione del portachiavi, firma digitale, cifratura) sono molto ben descritte dalla documentazione.

Seahorse

Questa è probabilmente la migliore interfaccia grafica di GPG, che permette in modo molto semplice di

• generare una o più coppie di chiavi da usare con PGP
• esportare la propria chiave pubblica in modo da poterla inviare a terze parti
• attribuire un grado di fiducia alle chiavi pubbliche ricevute, e firmarle
• condividere le proprie chiavi sia via rete locale, che per il tramite di un keyserver
• firmare e cifrare sia le email che i file, direttamente da Evolution e da Nautilus
• gestire anche le chiavi utilizzate con SSH
• eseguire il backup di tutto il portachiavi

Possiamo quindi iniziare con il generare un nuova coppia di chiavi PGP, da associare al nostro nome e cognome, ed alla nostra email. L'email indicata dovrà essere esattamente quella che useremo poi nel seguito, idonea anche alla ricezione; scegliamo allora quella nella forma labint@nome.labint, che funziona all'interno del laboratorio: altre email, associate ad altre chiavi, potranno essere definite in un secondo momento. Ci viene quindi chiesto di inserire una passphrase, con la quale verrà crittografata la nostra chiave privata, e che ci sarà chiesta di nuovo, ogni volta che quest'ultima dovrà essere usata - a meno di non scegliere che venga memorizzata per la durata della sessione.

Le chiavi così generate si ritrovano ora tra le chiavi personali, e mediante il tasto destro del mouse possiamo investigarne le proprietà, ed esportare la parte pubblica in un file, che potremo inviare in allegato. Infatti, aprendo ora Evolution, ed scegliendo l'account che usa il nostro stesso computer come SMTP ed IMAP, scriviamo delle email ai nostri colleghi, e prima di spedirle, stabiliamo di firmarle, (dalla voce Sicurezza/firma PGP), ed alleghiamo il file in cui abbiamo salvato la chiave pubblica. Alla ricezione di queste email, notiamo in basso la dicitura La firma esiste, ma è necessaria la chiave pubblica. Clicchiamo allora (con il tasto destro) sull'allegato contenente la chiave pubblica, scegliamo Apri in importa chiave, e... la chiave appare, come per magia, in Seahorse, tra le chiavi collezionate. Alternativamente, salviamo su file l'allegato con chiave pubblica, ed importiamolo in Seahorse. A questo punto, se siamo certi della identità del mittente, non ci resta che attribuirgli fiducia (tasto desto, Proprietà, Fiducia), e quindi firmare la chiave, indicando il nostro grado di certezza sulla identità, ed inserendo la passphrase per poter apporre la firma. Potremo quindi verificare che ora il messaggio ricevuto appare come correttamente firmato.

Dopo aver ricevuto le chiavi pubbliche dei nostri colleghi, potremo iniziare a crittografare i messaggi indirizzati loro, utilizzando la chiave pubblica del destinatario. Proviamo quindi ad inoltrare come allegato verso una terza persona una email crittografata che era originariamente diretta a noi, e verifichiamo come il nuovo destinatario non sia assolutamente in grado di leggere il messaggio.

Per verificare il risultato delle nostre operazioni, possiamo usare la combinazione di tasti control-U per visionare il sorgente della email firmata e/o crittografata, osservando come, nel caso di una email firmata, sia presente l'intestazione

e poi, nella parte che contiene la firma, questa sia identificata come

mentre invece, un messaggio crittografato è identificato da una serie di direttive del tipo

Infine, osserviamo come dal file manager Nautils, cliccando con il tasto destro sopra di un file, ora viene anche offerta la possibilità di cifrare e/o firmare un file.

Keyserver

Ogni volta che sulla nostra chiave pubblica viene apposta una nuova firma, può essere utile distribure la nuova versione mediante un keyserver. Qui di seguito indichiamo alcune risorse relativa alla questione

• The WWW Based PGP 5.0 Key Server System
• PGP Global Directory
• PGP: Public Key Servers
• Come usare PGP: i Keyserver

x

Lo Strato Applicativo
di Internet

Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade dietro le quinte di Internet, completo di cattura del traffico.
Scopri come effettuare il download, ricevere gli aggiornamenti, e contribuire!

---

Realizzato con da Alessandro Falaschi -