Figura 398.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.
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
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.
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:
|
È 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.
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 398.2 mostra sinteticamente l'uso di questa opzione aggiuntiva.
|
Figura 398.2. Alcune opzioni comuni ai programmi che usano le librerie di OpenSSL.
|
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. |
Su Apache esistono già diversi capitoli; in particolare il capitolo 327. In questa sezione si vogliono mostrare solo alcuni particolari che riguardano Apache-SSL, (2) ovvero quella versione che contiene le estensioni offerte da OpenSSL.
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.
|
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.
|
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.
|
Con queste due direttive, viene confermato l'ascolto sulla porta 80 e si aggiunge anche la porta 443 necessaria per le comunicazioni SSL (cifrate).
|
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.
|
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.
|
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.
|
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.
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 398.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 398.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. |
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.
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:
|
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 398.13. Principio di funzionamento di SSLwrap.
|
La figura 398.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.
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).
La tabella 398.14 elenca le opzioni più importanti della riga di comando di sslwrap.
|
Tabella 398.14. Alcune opzioni della riga di comando di sslwrap.
|
È 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:
|
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.
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.
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 398.16. Alcune opzioni della riga di comando di stunnel. |
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.
# stunnel -p /etc/ssl/certs/stunnel.pem -d 443 -r 80[Invio]
In questo caso, molto semplice, si avvia il demone in modo da dare al servizio HTTP locale la possibilità di essere raggiunto attraverso il protocollo HTTPS. In pratica, il demone resta in ascolto della porta locale 443, per connessioni SSL/TLS, funzionando come proxy nei confronti della porta locale 80, con la quale la comunicazione avviene in chiaro.
# stunnel -p /etc/ssl/certs/stunnel.pem -d 443 -r 192.168.1.2:80[Invio]
Come nell'esempio precedente, ma il servizio HTTP si trova in un nodo preciso, 192.168.1.2, che si presume essere diverso da quello locale.
# stunnel -c -d 80 -r 192.168.1.5:443[Invio]
Il demone funziona in modalità cliente in attesa di connessioni in chiaro attraverso la porta locale 80, mentre contatta per converso la porta 443, nel nodo 192.168.1.5, utilizzando in questo caso la crittografia SSL/TLS.
# stunnel -p /etc/ssl/certs/stunnel.pem -d 993 \
\ -l /usr/sbin/imapd -- imapd[Invio]
Il demone resta in ascolto della porta 993 (IMAPS) e utilizza lo standard output per comunicare con una copia di imapd, in chiaro. Si osservi la necessità di ripetere il nome del demone imapd come primo argomento dello stesso.
# stunnel -p /etc/ssl/certs/stunnel.pem -d 993 \
\ -l /usr/sbin/tcpd -- /usr/sbin/imapd[Invio]
Come nell'esempio precedente, ma aggiungendo il controllo da parte del TCP wrapper.
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
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
5) Soprattutto nel caso di servizi che per loro natura non si lasciano gestire semplicemente in questo modo, come avviene per il protocollo FTP.
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]
