3.1 Introduzione
Il web server per eccellenza sulle piattaforme di tipo Linux è senza
ombra di dubbio APACHE, che tra l'altro è il web server più
diffuso su internet data la sua flessibilità e anche per il fatto
che viene distribuito in maniera completamente gratuita. Per approfondire
si rimanda al sito ufficiale www.apache.org
Il server Apache non supporta, normalmente, il trasferimento di dati
in modalità protetta SSL, quindi è neccesario affiancargli
altri applicativi in modo da poter ottenere un server Apache con funzionalità
SSL. Due sono le strade che si possono scegliere a questo scopo: l'utilizzo
di un server Apache "modificato" oppure applicare un modulo alla distribuzione
standard di Apache. La prima soluzione è data dall'utilizzo di ApacheSSL
(www.apachessl.org), che è
appunto un server Apache con l'aggiunta di funzionalità per l'utilizzo
dell' SSL. La seconda soluzione, derivata peraltro da Apachessl, è
invece data dall'aggiunta del modulo mod_ssl (www.modssl.org)
nella distribuzione standard di Apache.
In questo documento verrà presentata l'implementazione utilizzando
il mod_ssl.
Entrambe le soluzioni si basano sul pacchetto OpenSSL (www.openssl.org),
basato a sua volta sulle librerie SSLLeay di Eric A. Jung.
3.2 Software necessario
Per realizzare un server Apache con funzionalità SSL si devono reperire
i seguenti applicativi.
-
Apache Web Server, ottenibile da www.apache.org
. E' consigliabile prendere la versione rilasciata più aggiornata,
evitando le Beta. Si devono scaricare i sorgenti, non le versioni già
precompilate (es. rpm), in quanto deve essere compilato insieme al mod_ssl.
-
mod_ssl, ottenibile da www.modssl.org
. In questo caso bisogna scaricare la versione adatta al nostro Apache
web server. Ad esempio mod_ssl-x.x.x.-y.y.y.tgz è la versione x.x.x
studiata per Apache versione y.y.y. Di norma le versioni di Apache e di
mod_ssl sono abbastanza sincronizzate, quindi ad un nuovo rilascio di Apache,
corrisponde un nuovo rilascio di mod_ssl.
-
OpenSSL, ottenibile da www.openssl.org
. Anche in questo caso è consigliabile la versione stabile più
recente.
I passi da seguire per l'installazione sono quelli standard per le installazioni
standard di linux. Si deve avere installata l'utility make . Si
guardino i file INSTALL dei tre pacchetti, visto che comunque i passi da
seguire possono variare da rilascio a rilascio. In particolare si consiglia
di cominciare a leggere il file INSTALL del mod_ssl, che spiega come installare
anche Apache e OpenSSL finalizzati all'uso con il mod_ssl stesso. Tra l'altro
le procedure di installazione variano, per questioni di tipo legislativo,
da stato a stato (principalmente USA e non USA).
3.3 Generazione delle chiavi e dei certificati per il
server SSL
Il concetto di SSL si basa anche, come già visto nella trattazione
teorica (http://telemat.die.unifi.it/book/Internet/Security/elab3.htm),
sul concetto di autentificazione del server e, opzionalmente, anche del
client. Questo significa che un server SSL deve avere obbligatoriamente
un proprio "certificato"(per un maggior approfondimento si veda il cap
relativo Certificazione) che
venga riconosciuto dai vari client. Questo certificato deve essere "firmato",
ovverosia deve contenere un firma elettronica di un ente che garantisca
che il certificato in questione sia valido e corrispondente ai dati in
esso riportati. Questi enti sono le "Certification Authority" (CAs), ovverosia
delle aziende che si occupano esclusivamente di autentificare i certificati
degli utenti di internet che ne fanno richiesta. Ovviamente le CAs devono
essere a loro volta autenticate da altre CAs, fino ad arrivare ad una root
CA, ovverosia un Certification Authority che sia riconosciuta a livello
mondiale, quale ad esempio Verisign (digitalid.verisign.com)
o Thawte (www.thawte.com)..
E' possibile farsi "firmare" un certificato da queste CAs seguendo
alcune semplice procedure e pagando dei prezzi che vanno da circa 100 $
in sù.
Alternativamente è possibile crearsi una propria CA ed usare
quella per firmare certificati. Ovviamente questa procedura è sconsigliata
nel caso si usi il server SSL per un pubblico generico (es. per e-commerce),
in quanto la vostra CA non offre garanzie alcune a terzi che voi siate
veramente le porsone che voi dite di essere. Viceversa questa soluzione
può essere valida in un contesto ridotto, ad esempio in una Intranet,
dove una CA locale ha invece una affidabilità garantita.
I certificati hanno una vlidità temporalmente limitata.
Le varie CAs gestiscono anche una CRL, Certificate Revocation List,
ovverosia una lista di certificati che, pur essendo in teoria ancora validi,
non lo sono più per tutta una serie di motivi (es. sono stati rubati).
In generale un certificato può essere visto come una sorta di
chiave pubblica a cui corrisponde relativamente un chiave privata. Quindi
ad ogni certificato corrisponde una chiave la quale in genere è
protetta da una passphrase. E' importante fare delle copie di Backup
di tale chiave, in quanto è l'unico modo che avete di dimostrare
la vostra identità sulla rete. Per lo stesso motivo è assolutamente
importante che essa non venga trafugata insieme alla passphrase, in quanto
in questo modo chiunque potrebbe impersonarvi su internet.
3.3.1 Generazione di una chiave
La prima cosa da fare è generare una propria chiave personale che
garantirà la nostra identità. Tale chiave verrà chiamata
server.key. Normalmente viene custodita in /usr/local/apache/conf/ssl.key/
La server.key deve essere accessibile solo dall'utente root, eventualment
con chmod 400 server.key.
Il comando è, dalla shell:
$ openssl genrsa -des3 -out server.key 1024
Verrà generata una chiave RSA triple
DES encrypted e con formattazione PEM. Vi verrà
inoltre richiesta una passphrase che servirà per utilizzare
questa chiave.
Si può anche decidere di togliere la phassphrase alla chiave,
ma è altamente sconsigliato per motivi di sicurezza:
$ openssl rsa -in server.key -out server.key.unsecure
3.3.2 Generazione di una Certificate Signing Request
(CSR)
Una volta generata la chiave bisogna ottenere un certificato. Per far questo
bisogna ottenere una Certificate Signing Request, ovverosia una richiesta
di firma per il nostro certificato, cioè il file server.csr,
che viene custodito in /usr/local/apache/conf/ssl.csr/
Per questo il comando è:
$ openssl req -new -key server.key -out server.csr
In questa fase vi verranno richiesti una serie di dati. In particolare
è importante il FQDN, cioè il Fully Qualified Domain Name.
Si tratta dell'indirizzo del server SSL su cui utilizzerete questo certificato.
Un certificato che riporti un FQDN diverso dal proprio indirizzo può
essere effetto di una mistificazione, quindi i client segnalano questa
anomalia, con il risultato che il vostro certificato potrebbe non essere
accettato dagli utenti.
Per vedere i dettagli del fil csr generato:
$ openssl req -noout -text -in server.csr
Il file server.csr è ciò che bisogna mandare ad una eventuale
CA perchè ci venga firmato e ci venga restituito.
Qualora si opti per questa soluzione si può passare direttamente
al punto 3.3.5
3.3.3 Generazione di una propria Certification Authority
(CA)
Come già detto è possibile anche generarsi una propria CA
che possa firmare certificati
In primis è necessario generare un chiave per la CA, che chiameremo
ca.key e localizzeremo in /usre/local/apache/conf/ssl.key/. Il procedimento
è ancora:
$ openssl genrsa -des3 -out ca.key 1024
Anche in questo caso verrà generata una chiave RSA triple DES
encrypted e con formattazione PEM. Vi verrà inoltre richiesta una
passphrase che servirà per utilizzare questa chiave.
Si tratta ora di generare il certificato di una CA secondo lo standard
chiamato X.509. Il comando è:
$ openssl req -new -x509 -days 365 -in ca.key -out ca.crt
Anche in questo caso vi verranno richiesti una serie di dati. Per visualizzare
il contenuto del file ca.crt:
$ openssl x509 -noout -text -in ca.crt
Il file ca.crt, costudito in /usr/local/apache/conf/ssl.crt/, è
il file che rappresenta la nostra Certification Authority
3.3.4 Utilizzare la propria CA per firmare i certificati
Si tratta ora di utilizzare la CA generata al paragrafo 3.3.3
per firmare un certificato, in particolare utilizzando Certificate Signing
Request generata al paragrafo 3.3.2
Per fare questo si può utilizzare uno script che viene fornito
insieme alla distribuzione mod_ssl, in particolare nella sottodirectory
pkg.contrib/
Lo script si chiama sign.sh
Per firmare un certificato bisogna avere a disposizione 3 files:
-
La Certificate Signing Request, nel nostro caso il file server.csr
-
La chiave della CA, nel nostro caso il file ca.key
-
Il certificato della CA, nel nostro caso il file ca.crt
Una volta che ci siamo assicurati che tutti i 3 files richiesti sono a
nostra disposizione (meglio se nella stessa directory) si può lanciare
lo script:
$ ./sign.sh server.csr
Il risultato sarà un file certificato server.crt, che
verrà costudito in /usr/local/apache/conf/ssl.crt/
A questo punto il file server.csr non è più necessario
3.3.5 Localizzazione di chiavi e certificati
Si tratta ora di comunicare al Web Server Apache la localizzazione del
file server.key e del file server.crt, sia esso stato ottenuto da una nostra
CA o da una CA ufficiale.
Nel file httpd.conf vanno inserite 2 direttive:
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key
Queste 2 direttive indicano la localizzazione del nostro certificato
del server e la relativa chiave privata.
3.4 Attivazione del server Apache con supporto SSL
Dopo aver corettamente configurato i certificati e le chiavi si può
far partire il server Apache con supporto SSL. E' bene evidenziare come
il server Apache funzioni sia in modalità protetta che non protetta.
In particolare:
-
http://www.mioweb.com è l'indirizzo non protetto, che funziona sulla
porta 80 classica
-
https://www.mioweb.com è, invece, l'indirizzo protetto da
SSL. Si noti la s in https. Funziona sulla porta 443, quindi, in caso di
firewalling, deve essere tenuto presente.
Lo script che viene utilizzato è:
$ /usr/local/apache/bin/apachectl argument
argument è la descrizione dell'operazione da intraprendere,
in particolare:
-
stop: ferma Apache, è utile per riavviarlo dopo aver variato
dei parametri in fase di test
-
start: fa partire Apache senza SSL
-
startssl: fa partire Apache con SSL. In questo caso, se server.key
è criptata (e dovrebbe esserlo) vi verrà richiesta la passphrase
di server.key. Se avete inserito l'avvio di Apache con SSL nelle procedure
di boot, la procedura, al momento di far partire httpd si interromperà
fino a che non inserirete la passphrase corretta. Se non si vuole
inserirla sempre a mano si può togliere la passphrase da
server.key (v 3.3.1), ma questo è notevolmente
rischioso in quanto la vostra server.key non verrebbe più protetta.
Alternativamente si può inserire in httpd.conf la direttiva
SSLPassPhraseDialog exec:/punta/a/un/file, ove file deve essere un eseguibile
che fornisca la passphrase allo standard output. Ovviamente anche
questo diminuisce il livello di sicurezza, ma in maniera meno compromettente
della soluzione precedente.
3.5 Generazione di un certificato per un Client
La generazione di una chiave per un Client è concettualmente identica
alla generazione di una chiave per un server. Solamente che i browsers
richiedono che essa sia in un formato particolare, cosiddetto PKCS (8 o
12, a seconda delle versioni). Le informazioni contenute in un file di
questo standard non sono diverse da quelle in un file .crt, sono solo in
formato diverso.
Come detto concettualmente si procede come per un server: in particolare
sono assolutamente identici i passi descritti ai punti 3.3.1,
3.3.2 e 3.3.4.
3.5.1 PKCS#8
Il PKC#8 è uno standard che gestisce le chiavi private. E' supportato
da OpenSSL, anche se oramai obsoleto, in quanto sostituito dal PKCS#12.
Si prenda il file .key, ad esempio client.key, e si usi la linea di
comando:
$ openssl pkcs8 -in client.key -topk8 -out client.p08 -v1 PBE-SHA1-3DES
3.5.2 PKCS#12
Sono detti anche PFX.
Una volta ottenuti i files .key e .crt (che possiamo chiamare client.key
e client.crt) essi vanno messi insieme in un file .pem, e.g. client.pem.
Questo può essere semplicemente fatto con:
$ less client.key > client.pem
$ less client.crt >> client.pem
Si tratta ora di generare il file PKCS. Viene qui fornito l'esempio
per il PKCS 12, nel caso del PKCS 8 si deve banalmente sostituire
il 12 con l'8.
$ openssl pkcs12 -export -in client.pem -out client.p12 -name "Il
mio Certificato"
Questo file può essere ora importato nel client.
Come nota si può riportare, dalla documentazione ufficiale:
BUGS
Some would argue that the PKCS#12 standard is one big bug :-)
3.6 Gestione dei livelli di sicurezza
Seguendo i passi fino a questo punto abbiamo ottenuto un Web Server Apache
con funzionalità SSL che però può non garantire un
alto grado di sicurezza.
Ad esempio le stesse pagine sono accessibili sia in modalità
SSL, sia in modalità standard, semplicemente digitando https o http
nell'indirizzo URL. Questo può, per un semplice errore del client,
far vedere delle pagine riservate in modalità non SSL, con il rischio
che vengano intercettate da qualcuno.
Ancora, non si è autentificato in alcun modo il client, quindi
non sono in grado di discriminare l'accesso al mio server su base utente,
eventualmente solo su base IP, sioè in maniera estremamente meno
flessibile.
Per questo mod_ssl definisce tutta una gamma di direttive per aumentare
il grado di protezione del server SSL stesso.
Per poter usare le direttive in una maniera più flessibile è
opportuno, in httpd.conf, abilitare l'uso del file .htaccess che
gestisce gli accessi su base "per directory" con la direttiva:
AuthOverride AuthConfig
3.6.1 Forzare il client ad usare SSL
Come detto, la prima necessità è quella di fare vedere il
sito, o almeno una sua parte, solo in modalità SSL. Questo può
essere fatto su base "per directory" usando, nel file .htaccess, la direttiva:
SSLRequireSSL
3.6.2 Autentificazione del client
In alcuni casi vi è la necessità di essere sicuri dell'identità
di un client che chiede una connessione al nostro server. Questa autentificazione
può essere basata sul concetto classico di username/password (autentificazione
di tipo Basic) oppure chiedendo al client un proprio certificato e valutandone
l'attendibilità. Vengono qui analizzati le due tecniche che, peraltro,
non sono mutualmente esclusive ma possono essere utilizzate insieme
3.6.2.1 Autentificazione Basic
E' basata sul concetto username/password. Funziona anche in assenza di
SSL, su server Apache tradizionale. In contesto SSL è bene sottolineare
come il passaggio di username e password avvenga in maniera protetta, cioè
dopo aver attivato la modalità SSL. Questo anche se, in alcuni client,
il "lucchetto" si chiude solo dopo avere inserito username e password:
è un bug del client.
La prima cosa da fare è generare un file che abbini coppie di
username e password (criptate) da utilizzare nelle procedure di autentificazione.
Si utilizza il programma htpasswd. Per creare il file inserendo
l'utente ilario:
$ htpasswd -c /punta/al/file/users ilario
a questo punto viene richiesta la password per ilario e viene creato
il file /punta/al/file/users che contiene la password per lo user ilario.
Successivamente per aggiungere altri utenti:
$ hppasswd /punta/al/file/users filippo
in questo caso viene richiesta la password per lo user filippo che viene
aggiunto al file.
Per cancellare uno user, è sufficiente cancellare dal file la
corrispettiva riga.
Si tratta ora di utilizzare questo file. L'autentificazione è
fatta su base "per directory", utilizzando il file .htaccess. All'interno
di questo file si deve aggiungere:
AuthName "area protetta 1"
AuthType Basic
AuthUserFile /punta/al/file/users
require valid-user
la direttiva AuthName specifica l'etichetta della protezione. una volta
che l'utente ha inserito validamente username/password, tutte le sezioni
protette con il medesimo AuthName sono accessibili.
AuthType indica il tipo di autorizzazione, Basic, appunto.
AuthUserFile punta al file che avevamo precedentemente creato.
require valid-user ci indica che possono accedere alla sezione tutti
gli utenti presenti nel file di cui sopra. Alternativamente si può
indicare:
require ilario
cioè solo lo user ilario può accedere a questa sezione.
Il vantaggio di questo tipo di protezione è, senza dubbio, la
facilità di implementazione, anche dal lato client. Di contro, però,
si intuisce come username/password possono essere rubate (indovinate) o
passate da un utente all'altro, rendendo basso il livello effettivo di
sicurezza.
3.6.2.2 Autentificazione con certificato di client
La filosofia di questa protezione è il far accedere al sito solo
i client che si autentificano con un proprio certificato (v
3.5) e, tipicamente, solo se il certificato presentato risponde ad
un determinato criterio.
Lo scenario più comune e quello di una Intranet, dove si mette
un Web Server SSL che debba far accedere alle pagine solo in SSL e solo
quei client che abbiano un certificato firmato dalla CA dell'amministrazione
dell'Intranet stessa.
Per far questo bisogna, oltre ad aver generato i vari certificati e
chiavi come indicato nei paragrafi precedenti, inserire in httpd.conf
le seguenti direttive:
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /usr/local/apache/conf/ssl.crt/ca.crt
La direttiva SSLVerifyClient require indica che è richiesta la
autentificazione del client.
SSLVerifyDepth indica che voglio che il mio certificato sia firmato
direttamente dalla mia CA
SSLCACertificateFile indica dove è il certificato della mia
CA.
Nel caso voglia revocare la validità di un certificato è
sufficiente inserirlo nella Revocation List della mia CA ed usare
la direttiva:
SSLCARevocationFile /usr/local/apache/conf/ssl.crl/revocation_list.crl
Il vantaggio di questa soluzione è che mi da la garanzia che
accedono solo le persone a cui si è firmato il certificato con la
CA del sistema. Un uso fraudolento è quindi possibile solo se viene
utilizzato il file contenente il certificato del client. Di contro l'utilizzo,
a livello di client, è meno immediato.
Nel caso si utilizzi questa modalità congiunta con quella Basic
lo username/password verranno richiesti dopo l'autentificazione via certificato
del client.
E' possibile anche sapere, nel caso si richieda un certificato al client,
quale è il client che accede al sito. Per fare questo è necessario
aggiungere, in http.conf, la direttiva:
SSLOptions +ExportCertData
Questo genera la variabile di ambiente SSL_CLIENT_CERT, che può
essere gestita attraverso un cgi-bin standard.Questa variabile contiene
il certificato del client in formato PEM encoded. Per avere il formato
"pulito" è necessario usare il comando
$ openssl x509 -noout -text -in SSL_CLIENT_CERT
Un modo semplice per gestire il monitoring degli accessi è creare
un file di log, che può poi essere gestito in maniera classica.
Si può fare inserendo in httpd.conf la direttiva:
CustumLog /usr/local/apache/log/Client_certificates_log \
"%{SSL_CLIENT_CERT}x%t\n%h\n
Questo genera un file Client_certificates_log che, per ogni connessione,
riporta in formato PEM-encoded del certificato di client, giorno, ora e
IP da dove è avvenuta la connessione.
Explore Telemat site!