Buono sconto 4% su Toner e Cartucce agli utenti AZpoint. SU Iomiricarico.it!!
Parliamo questa volta del protocollo free e non proprietario SSL. Venne proposto da Netscape Communications al W3 Consortium come approccio standard alla sicurezza per i browser WWW e per i server in genere; a posteriori possiamo dire che ha mantenuto le sue promesse. SSL è oggi punto di riferimento per tutte le società informatiche che investono nella sicurezza dei loro software. La quasi totalità delle comunicazioni e delle transazioni private, in particolare quelle bancarie, vengono effettuate su protocollo SSL. Il supporto è pressochè universale in qualunque ambiente informatico, sia esso web server che applicativo.
Come Funziona
Scopo primario dell' SSL Protocol è fornire sistemi di crittografia per comunicazioni affidabili e riservate sul Web sfruttabili in applicazioni quali, ad esempio, posta elettronica e sistemi di autenticazione. Il protocollo SSL provvede alla sicurezza del collegamento garantendo:
Privatezza del collegamento. La crittografia è usata dopo un handshake iniziale per definire una chiave segreta. Per crittografare i dati è usata la crittografia simmetrica (DES, RC4, ecc.).
Autenticazione. L'identità nelle connessioni può essere autenticata usando la crittografia asimmetrica, ovvero a chiave pubblica (RSA, DSS, ecc). Così ogni client comunica in sicurezza con il corretto server, prevenendo ogni interposizione. E' prevista la certificazione sia del server che del client.
Affidabilità . Il livello di trasporto include un controllo dell'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (SHA, MD5, ecc). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione.
Volendo dare una panoramica tecnica leggermente più specifica sul protocollo, possiamo dire che SSL si suddivide in due sotto-protocolli:
SSL Handshake Protocol: si compone a sua volta di sei fasi che si occupano di gestire identificazione e autenticazione del server ed eventualmente anche del client mediante certificati in formato X509V3. La certificazione avviene mediante firma digitale con chiavi private generate, scambiate e verificate principalmente con protocollo RSA.
SSL Record Protocol: lavora a livello Data-Link (secondo lo standard networking a pila ISO/OSI), specificandone le modalità di incapsulamento dati in ricezione e trasmissione. In particolare, specifica il formato del codice di autenticazione del messaggio (Message Authentication Code, MAC), dei dati trasmessi e di quelli di padding.
Istallazione e creazione di un certificato per il nostro Server Web
Bene, vogliamo il nostro server Apache istallato nel nostro ambiente Linux pronto a lavorare con supporto SSL. Innanzitutto procuriamoci i sorgenti per Apache-ssl. Alla data in cui scriviamo la versione più recente è la apache_1.3.33+ssl 1.55.tar.gz. Supponendo di voler istallare il nostro server nella cartella /opt/apache, procediamo da shell come segue:
# tar zvxf apache_1.3.33+ssl 1.55.tar.gz
# cd apache_1.3.33
# tar xvzf ../ apache_1.3.33+ssl 1.55.tar.gz
# ./FixPatch
# ./configure --prefix=/opt/apache/
# ./configure --prefix=/opt/apache/ --enable-module=rewrite --enable-shared=rewrite
# make
# make install
# ln -s /opt/apache/conf/httpsd.conf /opt/apache/conf/httpd.conf
L' istallazione andata a buon fine verrà salutata da un messaggio di ringraziamento da parte di http://www.apache.org.
Ci siamo. E' tempo di costruirci il nostro certificato di riconoscimento personale ovvero, una carta digitale che assicuri a qualunque client, che si connetta al nostro server, che noi siamo davvero noi. I certificati digitali sono stati introdotti come un meccanismo avanzato per la distribuzione delle chiavi pubbliche secondo lo standard X.509V3 che ne definisce il formato. Esistono due tipologie di certificati:
Certificati firmati dalle CA (Certificate Authority a sua volta certificata da un autorità di certificazione finale detta root CA). In pratica è necessario un iter burocratico lento e a pagamento.
Costruire una coppia di chiavi, una pubblica ed una privata (vedremo come).
Preparare la richiesta di firma del nostro certificato ovvero un CSR (Certificate Signing Request).
Inviare alla CA la CSR.
CA più utilizzate in Italia sono le poste italiane e l'AIPA, ma si può anche ricorrere ad autorità di certificazione internazionali facilmente rintracciabili sul web a costi variabili.
Certificati CA self-signed. In pratica il certificato ce lo scriviamo e ce lo firmiamo da noi. Al momento in cui il client contatterà il nostro server il browser avviserà l' utente che il certificato che gli si propone non è firmato da nessuna authority riconosciuta. L' accesso alla connessione sicura che il nostro server fornisce sarà subordinata ad un "atto di fede" (passatemi il termine) da parte del client. Il vantaggio? Non si paga!
Il passo comune da compiere, sia per i certificati firmati da CA che da quelli self-signed, è quello di creare una coppia di chiavi, una pubblica ed una privata. Ci sono diversi metodi, più o meno complessi. Il più adatto al nostro scopo è certamente OpenSSL, un tookit totalmente free (quanto ci piace questo termine, specie se associato ad un software) che permetterà di interfacciarci con il protocollo SSL e tutte le sue funzionalità . Innanzitutto preoccupiamoci di scaricarne il sorgente e di istallarlo con la solita procedura:
# tar xvzf openssl-0.9.7.tar.gz
# cd openssl-0.9.7/
# ./config
# make
# make test
# make install
Digitando da shell il comando "openssl" dovrebbe comparire il prompt della console di interfaccia con OpenSSL "openssl>". Per uscire digitiamo exit, quit o by. Procediamo.
# cd /opt/apache/
Nella directory /opt/apache/ (quella in cui avete istallato apache-ssl) creiamo le directory "gcache" e "certs":
# md gcache
# md certificati
# cd certificati
utilizziamo l' opzione genrsa di OpenSSL.
# openssl genrsa -des -out mio_server.key 1024
in questo modo otteniamo una chiave privata RSA di 1024 bit memorizzata nel file mio_server.key cifrata con l' algoritmo DES, il che ci porta alla richiesta di inserimento si una passfrase (o password se preferite) utile alla cifratura DES e richiesta da OpenSSL ogni volta che dovrà usare questa chiave privata. Pensiamo ora a costruire il nostro CSR
# openssl req -new -key mio_server.key -out mio_server.csr
In questo modo abbiamo generato la richiesta di firma del certificato. Passiamo ora alla generazione del certificato della nostra CA
# openssl genrsa -des -out mia_CA.key 2048
Anche la generazione del file mia_CA.key contenente una chiave privata richiederà una passfrase. Con questa chiave ci occuperemo di generare e firmare certificato CA:
# openssl req -new -x509 -days 365 -key mia_CA.key -out mia_CA.cert
Il file mia_CA.cert conterrà invece il certificato della nostra CA valido per un anno secondo lo standard x509. La generazione del certificato comporta il riempimento di alcuni campi standard tipici dei certificati. Se si sta generando un certificato per una CA pubblica, sarà necessario indicare come Common Name (CN) il nome esatto del server HTTPS. Per essere sicuri di ciò che abbiamo combinato visualizziamo in chiaro il certificato:
# openssl x509 -text -in mia_CA.cert
Fatto tutto questo, l'atto finale è quello di creare il certificato del nostro sito web e farlo firmare dalla nostra CA. Innanzi tutto procediamo con la creazione di alcune cartelle e file nella directory in cui abbiamo istallato Apache, nel nostro esempio /opt/apache/ per poi passare alla firma vera e propria:
# cd /opt/apache/
# mkdir -p mia_CA/certificati
# touch mia_CA/index.txt
# echo '01' > /mia_CA/seriale
# openssl ca -keyfile mia_CA.key -cert mia_CA.cert -in mio_server.csr -out mio_server.cert
finalmente in mio_server.cert abbiamo ottenuto il certificato firmato dalla CA mia_CA. Ci siamo quasi. Per fare in modo che il nostro server web usi il certificato, modifichiamo il file di configurazione di apache httpsd.conf sotto la cartella /opt/apache/conf/, inserendo le direttive:
sslCertificateFile /opt/apache/certificati/mio_server.cert
sslCertificateKeyFile /opt/apache/certificati/mio_server.key
per un approfondimento è bene consultare le guide alla configurazione di apache http://www.apache.org/docs/configuring.html e di ssl presso http://www.apache-ssl.org/docs.html.
Fidarsi è bene, non fidarsi ...
Purtroppo, l'esperienza ci ha insegnato che la parola sicurezza non è mai valida al 100%. In passato ci sono stati diversi episodi in cui si sono scoperte di falle nel protocollo. Nel 2002 SSL ha mostrato un primo cedimento. La falla consentiva la generazione di falsi certificati digitali che, come visto, normalmente garantiscono l'autenticità delle transazioni in modo tale da intercettare comunicazioni riservate. Il problema fu risolto in ambiente Linux dopo soli tre giorni, Microsoft preferì minimizzare il problema con conseguenze lasciate ai posteri. Nel 2004 vennero rilevati una serie di problemi di una certa gravità che interessavano il Private Communications Transport (PCT), protocollo integrato in SSL. Nei sistemi Microsoft, portava a gravissimi problemi di sicurezza quali il reset da remoto della macchina attaccata e, in qualche caso, permetteva di prendere il controllo completo con possibilità di istallazione di programmi e creazione di account con permessi universali. A suo tempo, la casa di "Bill" rilasciò tempestivamente i soliti "pezzotti" (le patch) per correre ai ripari. In ogni caso non fu mai messa in discussione la parte di sicurezza riguardante lo scambio di informazioni sensibili, quali pin di carte di credito e password sul web. In ogni caso, non temete, il vostro ambiente Linux è nativamente immune a questi livelli di attacchi, ma questa è un' altra storia.
Un articolo di TuxJournal - clicca qui
|