Capitolo 236. Applicazioni che usano OpenSSL

Alcune versioni di applicazioni comuni che hanno a che fare con la comunicazione di dati, incorporano le funzionalità crittografiche di certificazione e crittografia SSL/TLS, in particolare quelle che utilizzano proprio le librerie OpenSSL. Si tratta normalmente di versioni parallele a quelle «standard», e restano tali a causa delle leggi USA che limitano la distribuzione di software crittografico. Se la propria distribuzione GNU/Linux non dispone dei pacchetti relativi a questi programmi, in versione SSL, si rischia di dovere provvedere da soli compilando i sorgenti, dopo che questi sono stati ottenuti da siti che si trovano al di fuori degli USA.

Per fortuna, per alcune di queste applicazioni c'è poco da aggiungere, e in questo capitolo si raccolgono le sole informazioni necessarie per poterle utilizzare.

236.1 Opzioni comuni

Di solito, le applicazioni che incorporano le funzionalità SSL attraverso le librerie di OpenSSL, consentono l'uso dell'opzione -z, alla quale va aggiunto un argomento. La tabella 236.1 mostra sinteticamente l'uso di questa opzione aggiuntiva.

Opzione	Descrizione
-z ssl	Utilizza esclusivamente il protocollo SSL.
-z secure	Se fallisce la negoziazione SSL non passa a una connessione normale.
-z verify=`n`	Definisce il livello di verifica della certificazione.
-z cert=`file`	Definisce il file contenente il certificato.
-z key=`file`	Definisce il file contenente la chiave privata RSA.
-z cipher=`elenco`	Definisce l'elenco di algoritmi crittografici preferiti.

Figura 234.1. Alcune opzioni comuni ai programmi che usano le librerie di OpenSSL.

236.2 Certificati dei servizi

In generale, per attivare un servizio che consente l'utilizzo del protocollo SSL, occorre che questo disponga di una chiave privata e di un certificato. In particolare, il certificato dovrebbe essere ottenuto da un'autorità di certificazione, ma in mancanza di questo lo si può creare in proprio. I programmi in questione, dal momento che offrono un servizio in modo autonomo, hanno la necessità di accedere alla chiave privata, senza poter interrogare l'amministratore. Di conseguenza, tale chiave non può essere protetta, e di solito viene creato un file unico sia per la chiave privata che per il certificato.

Il file contenente il certificato e la chiave, ha solitamente un nome corrispondente a quello dell'applicazione, con l'aggiunta dell'estensione .pem, e si colloca normalmente nella directory /etc/ssl/certs/, o in un'altra simile. Supponendo che la directory da utilizzare sia proprio questa, si può generare in proprio il certificato dell'applicazione «prova», incorporando anche la chiave privata, nel modo seguente:

# cd /etc/ssl/certs

# openssl req -new -x509 -nodes -out prova.pem -keyout prova.pem

# chmod 600 prova.pem

# ln -s prova.pem `openssl x509 -noout -hash -in prova.pem`.0

Dal momento che deve essere creata una chiave privata non protetta, altrimenti il servizio non potrebbe funzionare, il file che si genera non deve avere alcun permesso di accesso per gli utenti estranei, esattamente come si vede nell'esempio.

Di solito, la directory in cui vengono collocati i certificati di questi servizi, non dipende dalla configurazione di OpenSSL. In effetti, a parte il problema di crearli, questi vengono poi gestiti dai servizi stessi: saranno questi che eventualmente devono essere configurati per poter ritrovare i loro certificati.

236.3 Apache-SSL

Su Apache esistono già diversi capitoli; in particolare il capitolo 203. In questa sezione si vogliono mostrare solo alcuni particolari che riguardano Apache-SSL, ovvero quella versione che contiene le estensioni offerte da OpenSSL.

La crittografia SSL nell'ambito del protocollo HTML, viene applicata utilizzando una porta diversa da quella standard. Di solito si tratta del numero 443, a cui si abbina la definizione https. A questo proposito, il file /etc/services dovrebbe contenere le righe seguenti:

https           443/tcp
https           443/udp

236.3.1 Installazione e configurazione di Apache-SSL

Quando si installa Apache-SSL occorre provvedere prima a disinstallare, o almeno disattivare, il servente Apache normale, o altro servente HTTP. Convenzionalmente, i file di configurazione di Apache-SSL non dovrebbero andare a sovrapporsi a quelli della versione normale di Apache: in condizioni normali potrebbe trattarsi della directory /etc/apache-ssl/.

In questa directory si trovano i file di configurazione consueti: access.conf, httpd.conf e srm.conf. Oltre a questi, deve essere creato il file contenente la chiave privata e il certificato che serve al servizio per potersi identificare nei confronti dei clienti: httpsd.pem, oppure apache.pem, o un altro nome, in base alla configurazione.

Questo file, a meno di averlo ottenuto da un'autorità di certificazione, deve essere creato in proprio. Dovrebbe essere lo stesso sistema di installazione che si occupa di crearlo; in alternativa, disponendo dei sorgenti, si ottiene con il comando make certificate, oppure nel modo già visto in questo capitolo, tenendo conto che di solito Apache-SSL si aspetta di trovarlo nella stessa directory in cui si trovano gli altri file di configurazione (basta controllare il contenuto di httpd.conf per determinare il nome di questo file e la sua collocazione).

Le novità della configurazione di Apache-SSL riguardano il file httpd.conf, e nel seguito vengono descritte brevemente solo le direttive più importanti riferite alle connessioni SSL.

ServerType standalone

Allo stato attuale, Apache-SSL può funzionare solo in modo indipendente da inetd, per cui la direttiva ServerType standalone è obbligatoria.

Apache-SSL deve essere in grado di comunicare sia in chiaro che in modo cifrato. La distinzione avviene in base all'uso delle porte. In condizioni normali, la porta 80 è quella usata di consueto per le connessioni normali, mentre la porta 443 è riservata per le comunicazioni cifrate.

Port 80

Come si vede nell'esempio, viene abilitata espressamente la porta 80; in seguito, con la direttiva Listen, viene esteso l'ascolto anche alla porta 443.

Listen 80
Listen 443

Con queste due direttive, viene confermato l'ascolto sulla porta 80 e si aggiunge anche la porta 443 necessaria per le comunicazioni SSL (cifrate).

# Set SSLVerifyClient to:
# 0 if no certicate is required
# 1 if the client may present a valid certificate
# 2 if the client must present a valid certificate
# 3 if the client may present a valid certificate but it is not required to
#   have a valid CA
SSLVerifyClient 0

Inizialmente, a meno che si pretenda di ottenere un certificato valido dai clienti, è bene disattivare la verifica dei clienti stessi, come si vede nell'esempio.

SSLDisable

In generale conviene organizzare l'abilitazione della crittografica SSL attraverso la distinzione in domini virtuali (come verrà mostrato). Per questo, conviene disabilitare a livello globale la crittografia SSL, riservandosi poi di abilitarla nei domini virtuali preferiti.

SSLCACertificatePath /etc/apache-ssl
SSLCertificateFile /etc/apache-ssl/apache.pem

Queste due direttive servono a definire la directory contenente i file dei certificati, e il percorso assoluto del file di certificazione del servizio, che in questo caso è /etc/apache-ssl/apache.pem.

<VirtualHost localhost:443>
    SSLEnable
    DocumentRoot /home/httpd/html-ssl/
</VirtualHost>

<VirtualHost dinkel.brot.dg:443>
    SSLEnable
    DocumentRoot /home/httpd/html-ssl/
</VirtualHost>

Queste due definizioni di domini virtuali servono a stabilire che: accedendo localmente, utilizzando quindi il nome localhost, oppure accedendo dall'esterno utilizzando il nome dinkel.brot.dg, ma attraverso la porta 433, si entra in un dominio virtuale, dove il nome non cambia, ma la directory iniziale corrisponde a /home/httpd/html-ssl/. È all'interno di queste definizioni che viene abilitata la comunicazione cifrata via SSL.

236.3.2 Accesso al servizio cifrato

Per accedere a un servizio HTTP-SSL in forma cifrata, è sufficiente indicare il protocollo HTTPS, ovvero, https://. La cosa riguarda tutti i clienti che siano compatibili con questo protocollo; esiste anche una versione di Lynx realizzata per questo scopo.

Se il cliente è in grado di tenere traccia delle informazioni sulla certificazione, si accorgerà che l'identità mostrata dal servente non è conosciuta. Si osservi la figura 236.1 che mostra quello che potrebbe succedere quando si tenta per la prima volta di accedere al servizio HTTPS offerto dall'elaboratore dinkel.brot.dg.

figure/netscape-ssl-newsite

Figura 236.1. Avvertimento da parte di Netscape nel momento in cui si tenta di accedere attraverso il protocollo HTTPS a un sito il cui certificato è firmato da un'autorità sconosciuta.

In effetti, Netscape (che si vede nella figura) offre un'ottima opportunità per controllare che il proprio certificato, per quanto non valido, sia realizzato correttamente.

236.4 SSLtelnet

Esiste anche una versione di Telnet in grado di utilizzare il tunnel SSL. In generale non c'è alcun problema di configurazione, a parte la necessità di disporre di un certificato, completo di chiave privata in chiaro, rappresentato di solito dal file telnetd.pem, che dovrebbe essere generato automaticamente dal programma di installazione, e inserito probabilmente nella directory /etc/ssl/certs/. Eventualmente, questo file (e il collegamento simbolico relativo) può essere ricostruito attraverso i comandi già visti all'inizio del capitolo.

Una volta installato il demone in.telnetd e il programma cliente telnet nella versione SSL, non serve altro. Al massimo, è il caso di verificare che il cliente sia in grado di connettersi con un servizio SSL. Il modo migliore è quello di farlo attraverso un altro servizio basato su SSL di cui si è già sicuri. L'esempio seguente mostra una connessione con un servente HTTPS, dal quale si preleva la pagina di ingresso al sito; si osservi in particolare l'uso dell'opzione -z ssl per utilizzare espressamente il protocollo SSL:

$ telnet -z ssl dinkel.brot.dg https

GET / HTTP/1.0[Invio]

[Invio]

HTTP/1.1 200 OK
Date: Fri, 03 Dec 1999 16:42:41 GMT
Server: Apache/1.3.3 Ben-SSL/1.29 (Unix) Debian/GNU
Connection: close
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Index of /</TITLE>
 </HEAD>
 <BODY>
<H1>Index of /</H1>
...
</BODY></HTML>
Connection closed by foreign host.

È interessante notare che la connessione Telnet cifrata via SSL, non utilizza una porta speciale: prima di instaurare una connessione avviene una negoziazione tra cliente e servente, e solo se è possibile si passa a una comunicazione cifrata.