SSL in Java

Lo sviluppo di applicazioni web based presenta, alla base, l'architettura client/server che consente, a molti utenti collegati in una rete, di richiedere dei servizi a un server. Lo scambio di informazioni è generalmente rappresentato da pagine HTML che dal server vengono scaricate e rappresentate sul browser del client. Il principio vale sia nel caso di applicazioni Intranet che Internet, dove la topologia di rete è (per sua natura) sconosciuta, quindi potenzialmente vulnerabile a qualsiasi intrusione non autorizzata.

I dati viaggiano "in chiaro", cioè così come noi le leggiamo. Nel primo caso, è evidente che il pericolo è circoscritto alla rete Intranet su cui ci troviamo, quindi la confidenzialità delle informazioni è difficile che oltrepassi il confine della rete privata (a meno di non lasciare buchi aperti in quest'ultima). Nel secondo, praticamente, ci si trova in mare aperto, dove chiunque può intromettersi e leggere i nostri dati. Si capisce, quindi, come sia importante, in alcuni contesti, evitare che ciò si verifichi proteggendo tali dati rendendoli leggibili solo al legittimo intestatario.

La tecnologia standard che si utilizza è quella delle comunicazioni SSL (Secure Socket Layer). Nell'articolo non entreremo nel dettaglio della tecnologia stessa, ci limiteremo, dove necessario a spiegare alcuni concetti base. Per approfondimenti rimando alla definizione di Wikipedia o all'articolo Apache ed SSL.

Secure Socket Layer

SSL è un protocollo che nell'architettura TCP/IP si pone tra il livello applicativo (http, nel nostro caso) e il protocollo di trasporto (TCP). Il suo compito è di cifrare (lato server) e decifrare (lato client) le informazioni, in maniera trasparente rispetto agli strati cui si interpone.

Prima di effettuare qualsiasi scambio di informazioni (cifrato), il client e il server si interconnettono, e in particolare il client verifica che il server sia sicuro verificando il certificato del server.

Il certificato è un oggetto che assicura che il sito, che si sta visitando, è stato autenticato da un'autorità superiore e fidata (dal client). Tale autorità e la CA (Certificate Authority) che è un autorità riconosciuta dal browser in maniera automatica (all'interno del browser trovate la lista delle autorità riconosciute come tali). Se il processo di autenticazione va a buon fine inizia lo scambio dati cifrato (le operazioni di cifratura e decifratura avvengono attraverso le chiavi contenute nel certificato).

Installazione del certificato

La prima operazione che dovrete fare sarà quella di acquistare un certificato da una di queste CA (Verisign è quella più nota). Acquistare il certificato è un'operazione piuttosto complessa, nel senso che l'autorità, per poter garantire un certificato deve verificare la compagnia per cui lo sta emettendo facendo alcuni controlli (per esempio verificando l'indirizzo mail master del dominio di riferimento).

In ogni caso, ecco i passi da seguire per poter abilitare il servizio SSL:

1. creazione del certificato sul server;
2. firma del certificato da una CA;
3. installazione del certificato controfirmato sul server;
4. abilitazione di una porta SSL;
5. abilitare il web service su https.

Nel nostro esempio faremo riferimento a un application server Java Sun AS 9 (Glassfish). La procedura è più o meno la stessa su tutti gli application server, quello che cambia potrebbe essere il tool utilizzato. Glassfish utilizza lo strumento di criptografia standard di Java, attraverso il comando keytool. Vi consiglio di inserire il comando sotto il vostro path di esecuzione, in quanto tutto dovrà essere svolto a riga di comando. Il registro (keystore.jks) si trova sotto la directory di installazione / domains / domain1 / config (se state lavorando sul dominio di default).

Per generare il certificato (passo 1) utilizzeremo il comando come segue:

Fate molta attenzione a ricordare l'alias utilizzato (certificateName) e il dominio che avete intenzione di utilizzare (domain.com). In particolare quest'ultimo deve essere l'esatto dominio che verrà visto dagli utenti (non vale per subdomain.domain.com). Attenzione perché al momento della creazione (e tutte le successive operazioni) viene richiesta la password del keystore (registro dei certificati) che di default è changeit, ma in alcune versioni è adminadmin.

Il secondo passo implica la creazione di un CSR (Certificate Sign Request) richiesto dall'autorità. Esportiamo quindi il certificato appena creato per poi sottoporlo al CA:

Una volta ottenuto il certificato firmato dall'autorità, copiamo quest'ultimo in un file (certificate.crt) che provvediamo a importare nel nostro registro:

Fate attenzione a mantenere sempre lo stesso alias di riferimento.

A questo punto potete controllare il vostro certificato installato utilizzando il comando di lista del registro:

L'ultima operazione (passo 4), prima di poter utilizzare SSL, è quella di abilitare una porta attraverso un listener. L'operazione seguente vale per Glassfish e potrebbe variare su altri AS.

Entrate nel pannello di amministrazione del servizio e raggiungete, attraverso l'albero di navigazione, l'area dei listeners (configuration > http service > http listener). Create un nuovo listener su una porta (quella di default è la 443) e abilitatelo spuntando tutte le caselle. Digitate il nome dell'alias con cui avete importato il certificato e salvate la configurazione.

Per poter funzionare, riavviate il server e testate l'indirizzo https://localhost/. Vi dovrebbe apparire la seguente interfaccia, a indicare che tutto è andato a buon fine.

Per poter essere certificato dai browser, l'autorità deve essere ben conosciuta, in alcuni casi potrebbe essere sufficiente il solo passo 1, cioè creare un certificato self-signed. Per esempio, per testare l'applicazione, o anche per applicazioni Intranet dove si assume che chi ha generato la chiave è trusted (fidato).

In generale però, per applicazioni di un certo rilievo, è necessario affidarsi a un'autorità terza. In alcune circostanze, potrebbe essere necessario installare sul server i certificati della stessa CA. Di default, infatti, sono presenti tutti quelli più importanti ma, nel caso non lo fossero, questa è la procedura da seguire:

root.crt e class3.crt sono forniti dalla CA e fanno autenticare proprio quest'ultima. Potrebbe essere utile che come test usiate i certificati trial di Verisign, in quel caso, dovete seguire la procedura appena citata.

Web service su SSL

A parte la configurazione del servizio, la logica applicativa non risente di alcun mutamento, quindi, richiamando le pagine attraverso il protocollo sicuro, o meno, potete garantire un certo grado di sicurezza delle vostre applicazioni. Quello che si sconsiglia assolutamente è di far girare tutte le pagine dell'applicazione sopra https. Ricordiamo che le operazioni di cifratura e decifratura sono piuttosto cpu-intensive. Limitate l'uso del protocollo solo a sezioni sensibili (operazioni di login, visualizzazioni di dati sensibili, invio di carte di credito, ecc).

Anche ai web service la logica SSL è trasparente in maniera quasi totale (al contrario delle pagine web, i web service devono dichiarare in maniera esplicita il loro funzionamento criptato, per via del funzionamento a basso livello).

Come esempio base prendiamo il web service della guida J2EE e cerchiamo di farlo funzionare su SSL. Nel descrittore di deploy del server (nel nostro caso sun-ejb-jar.xml) identifichiamo il codice XML che riferisce al web service e aggiungiamo un tag, come segue:

Indicando che il livello di trasporto deve essere CONFIDENTIAL stiamo dicendo esplicitamente al server che il web service dovrà avere tutta la logica di trasporto su SSL. Ciò vuol dire che il web service funzionerà allo stesso modo, solo che la comunicazione verrà criptata. Ovviamente anche la porta a cui risponderà il servizio non sarà più http ma https.