[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 407.   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», che 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. In questo capitolo si raccolgono le sole informazioni necessarie per poterle utilizzare.

Oltre alle applicazioni predisposte per il protocollo SSL/TLS, si aggiungono dei programmi che fungono da proxy TCP,(1) per dare queste funzionalità ai servizi che non le hanno già. Tuttavia, proprio perché intervengono solo a livello del protocollo TCP, può essere impossibile l'utilizzo di questi quando il protocollo finale prevede l'apertura di connessioni aggiuntive attraverso porte non prestabilite. In pratica, diventa impossibile il loro uso per servizi FTP.

407.1   Aggiornare l'elenco dei servizi

Le varianti SSL/TLS dei servizi più comuni, prevedono porte di comunicazione diverse da quelle standard. In particolare, se il proprio file /etc/services non è già stato predisposto, è necessario aggiungere le righe seguenti, dove i commenti sono ovviamente opzionali:

https           443/tcp         # http TLS/SSL
https           443/udp
ssmtp           465/tcp         # smtp TLS/SSL
ssmtp           465/udp
nntps           563/tcp         # nttp TLS/SSL
nntps           563/udp
telnets         992/tcp         # telnet TLS/SSL
telnets         992/udp
imaps           993/tcp         # imap4 TLS/SSL
imaps           993/udp
ircs            994/tcp         # irc TLS/SSL
ircs            994/udp
pop3s           995/tcp         # POP3 TLS/SSL
pop3s           995/udp
ftps-data       989/tcp         # ftp TLS/SSL
ftps-data       989/udp
ftps            990/tcp         # ftp TLS/SSL
ftps            990/udp

È proprio l'utilizzo di queste porte che fa intendere ai servizi in ascolto che si intende instaurare una connessione protetta. Per fare un esempio comune, il fatto di utilizzare un URI che inizi per https:// implica la richiesta di utilizzare un tunnel SSL/TLS per la certificazione e la crittografia, al contrario di un URI http:// normale; inoltre, nello stesso modo, il protocollo HTTPS è precisamente il protocollo HTTP nel tunnel SSL/TLS.

407.2   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 407.2 mostra sinteticamente l'uso di questa opzione aggiuntiva.

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

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.

407.3   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, sia 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, collocato 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[Invio]

openssl req -new -x509 -nodes -out prova.pem -keyout prova.pem[Invio]

chmod 600 prova.pem[Invio]

ln -s prova.pem `openssl x509 -noout -hash -in prova.pem`.0[Invio]

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.

Dal momento che si tratta di un certificato che serve a identificare un servizio, il campo CN deve contenere il nome di dominio completo attraverso il quale vi si accede.

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: sono questi servizi che eventualmente devono essere configurati per poter ritrovare i loro certificati.

407.4   Apache-SSL

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

407.4.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 dal supervisore dei servizi di rete, per cui la direttiva ServerType standalone è obbligatoria.

Apache-SSL deve essere in grado di comunicare sia in chiaro, sia 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 viene mostrato in seguito). 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.

407.4.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; esistono anche versioni di Lynx e Links, realizzate per questo scopo.

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

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

netscape-ssl-newsite

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

407.5   Telnet-SSL

Esiste anche una versione di Telnet in grado di utilizzare il tunnel SSL. (3) 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[Invio]

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 può essere negoziata anche attraverso la porta 23 normale. In alternativa, si può distinguere l'avvio del servente TELNET, nell'ambito della configurazione del supervisore dei servizi di rete, in modo da usare o meno la comunicazione cifrata. L'esempio seguente si riferisce a Inetd, con il file /etc/inetd.conf:

...
telnet   stream tcp nowait root /usr/sbin/tcpd  /usr/sbin/in.telnetd
telnets  stream tcp nowait root /usr/sbin/tcpd  /usr/sbin/in.telnetd -z secure
...

407.6   SSLwrap

SSLwrap (4) è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. In altri termini si tratta di un proxy che, ricevendo connessioni attraverso le porte SSL/TLS, ripete le richieste ai servizi reali attraverso le porte normali.

Figura 407.13. Principio di funzionamento di SSLwrap.

SSLwrap

La figura 407.13 mostra schematicamente un esempio di ciò che avviene. In particolare si vede l'uso delle porte, dove i numeri 1 046 e 1 053 sono solo un esempio di porte non privilegiate, utilizzate dinamicamente.

Da quanto espresso si dovrebbe intendere anche che SSLwrap può funzionare in un elaboratore distinto rispetto a quello che ospita i servizi per i quali è stato attivato. Naturalmente, nel tragitto che collega SSLwrap al servizio reale, i dati viaggiano in chiaro.

Un effetto collaterale dell'utilizzo di SSLwrap sta nel fatto che i servizi reali si trovano a comunicare sempre con lo stesso nodo, senza sapere da dove vengono realmente le richieste di connessione e senza poter applicare alcuna politica di filtro. SSLwrap è in grado di funzionare sia attraverso il controllo del supervisore dei servizi di rete, sia in modo indipendente; tuttavia, attraverso il supervisore dei servizi di rete e poi anche il TCP wrapper è possibile attuare le consuete politiche di filtro e di controllo degli accessi, anche attraverso il protocollo IDENT.

407.6.1   Avvio

SSLwrap si compone dell'eseguibile sslwrap, che svolge il ruolo di demone, autonomo o sottoposto al controllo del supervisore dei servizi di rete.

sslwrap [opzioni] -port porta-servizio-originale [-accept porta-servizio-ssl]

Lo schema sintattico mostra in particolare l'uso obbligato dell'opzione -port, con la quale si specifica la porta del servizio originale, a cui ridirigere le richieste che invece provengono dalla porta SSL corrispondente. Si vede anche che l'opzione -accept permette di stabilire il numero di porta SSL da utilizzare per attendere le richieste; porta che non va indicata se si opera attraverso il controllo del supervisore dei servizi di rete (perché in tal caso i dati provengono dallo standard input).

In condizioni normali, si presume che il servizio standard sia collocato nello stesso nodo in cui è in funzione SSLwrap, per cui si intende implicitamente che si tratti di 127.0.0.1. Diversamente si deve utilizzare l'opzione -addr.

La tabella 407.14 elenca le opzioni più importanti della riga di comando di sslwrap.

Tabella 407.14. Alcune opzioni della riga di comando di sslwrap.

Opzione Descrizione
-addr indirizzo-ip
Indirizzo IP del servizio originale.
-port porta
Porta del servizio originale.
-accept porta
Porta SSL per ricevere le richieste.
-verify
Attiva la verifica del certificato della controparte.
-Verify
La controparte deve avere un certificato valido.
-cert file
Certificato in formato PEM.
-key file
Chiave privata in formato PEM (se non è già nel certificato).
-without_pid
Non crea il file contenente il numero del processo.

407.6.2   Utilizzo pratico

È probabile che la propria distribuzione sia organizzata in modo tale da configurare interattivamente il funzionamento di SSLwrap, aggiornando il file /etc/inetd.conf (nel caso si utilizzi Inetd come supervisore dei servizi di rete), oppure predisponendo gli script necessari nell'ambito della procedura di inizializzazione del sistema. Tuttavia, vale la pena di vedere ugualmente cosa si dovrebbe fare intervenendo manualmente.

Qui si presume che si utilizzi un certificato unico, completo di chiave privata, corrispondente al file /etc/ssl/certs/sslwrap.pem.

Nel caso del funzionamento sotto il controllo del supervisore dei servizi di rete, basta modificare il file /etc/inetd.conf aggiungendo le righe seguenti, che qui appaiono tutte spezzate a metà per motivi tipografici:

https           stream  tcp     nowait  root    /usr/sbin/tcpd    \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 80 -without_pid ssmtp stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 25 -without_pid nntps stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 119 -without_pid telnets stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 23 -without_pid imaps stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 143 -without_pid ircs stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 194 -without_pid pop3s stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 110 -without_pid ftps-data stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 20 -without_pid ftps stream tcp nowait root /usr/sbin/tcpd \
  \/usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 21 -without_pid

Naturalmente, non è necessario attivare tutti i presunti servizi SSL, eventualmente commentando le righe che non servono.(5) Inoltre, nel caso che i servizi reali si trovino in un altro elaboratore, si può aggiungere l'opzione -addr, come già descritto.

Per utilizzare sslwrap come demone autonomo, si può usare un comando simile a quello seguente, che si riferisce al caso del protocollo HTTPS:

sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 80 -accept 443 &[Invio]

Logicamente, questo e altri comandi simili per gli altri servizi SSL vanno messi convenientemente in uno script adatto alla procedura di inizializzazione del sistema.

407.7   Stunnel

Stunnel (6) è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. Ma in aggiunta a quanto fa già SSLwrap, può essere usato anche per la funzionalità opposta, utilizzando un cliente che non è in grado di gestire il protocollo SSL/TLS.

In particolare, Stunnel non può essere messo sotto il controllo del supervisore dei servizi di rete, mentre può controllare i programmi che lo stesso supervisore dei servizi di rete gestisce.

407.7.1   Avvio

Stunnel si compone dell'eseguibile stunnel, che svolge il ruolo di demone autonomo, in grado di contattare un servizio già in ascolto di una porta TCP o di avviare un programma come fa il supervisore dei servizi di rete.

stunnel [opzioni]

Tabella 407.16. Alcune opzioni della riga di comando di stunnel.

Opzione Descrizione
-c
Modalità «cliente»: il cliente si connette in chiaro e il servizio originale è SSL/TLS.
-T
Proxy trasparente, quando il sistema lo consente.
-p file
Certificato in formato PEM, che non si usa nella modalità «cliente».
-v [1|2|3]
Attiva la verifica del certificato.
-v 1
Verifica il certificato della controparte se presente.
-v 2
Verifica il certificato della controparte.
-v 3
Verifica la controparte con i certificati disponibili localmente.
-a directory
Directory contenente i certificati per la verifica -v 3.
-d porta
Porta di ascolto per le richieste di connessione.
-l programma [-- argomenti]
Avvio di un programma compatibile con il supervisore dei servizi di rete.
-r [indirizzo-ip:]porta
Servizio remoto da contattare.

407.7.2   Utilizzo pratico

Stunnel non ha una destinazione di utilizzo ben precisa, per cui occorre decidere prima cosa farne, quindi intervenire in modo appropriato nella configurazione del sistema. In generale, trattandosi di un demone che può funzionare solo in modo autonomo, non si deve intervenire nella configurazione del supervisore dei servizi di rete; al massimo si possono predisporre degli script per la procedura di inizializzazione del sistema. Vengono mostrati alcuni esempi, tenendo conto che il certificato riferito al servente si trova nel file /etc/ssl/certs/stunnel.pem.


1) Qui si intende un proxy che non conosca il protocollo utilizzato effettivamente dal servizio che viene ridiretto, a parte la gestione TCP pura e semplice.

2) Apache-SSL   software libero con licenza speciale

3) Telnet-SSL   UCB BSD

4) SSLwrap   GNU GPL

5) Soprattutto nel caso di servizi che per loro natura non si lasciano gestire semplicemente in questo modo, come avviene per il protocollo FTP.

6) Stunnel   GNU GPL


Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome applicazioni_che_usano_openssl.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory