Indice
Introduzione
L’ HTTP (HyperText Transfer Protocol) è un protocollo di livello applicazione che viene ampiamente utilizzato nel mondo del web per consentire la fruizione delle pagine che compongono un sito e che da un server vengo inviate ad un client, nel momento in cui questo le richiede. È possibile per un client, altresì, inviare dati ad un server, sulla base dei quali questo effettua un’elaborazione e fornisce una pagina di risposta. Il processo di richiesta/risposta è garantito proprio dall’uso dell’HTTP che presenta però una serie di limiti: non è in grado di garantire al client l’autenticazione del server al quale si vuole inviare la richiesta, di assicurare l’integrità dei dati, cioè, verificare che essi non siano stati compromessi (tamper) durante il percorso e di crittografarli, rendendoli illeggibili nel caso in cui venissero intercettati. Il protocollo in questione non è sicuro. Per ovviare a tali problematiche è stato introdotto il protocollo HTTPS che combina quello HTTP con le funzionalità del TLS, un protocollo di livello trasporto che aggiunge la risoluzione alle criticità citate.
Configurazione
Al fine di abilitare l’HTTPS sul proprio web server Tomcat è necessario predisporre un certificato digitale che contiene una serie di informazioni essenziali per garantire il corretto funzionamento del protocollo, quali dominio per cui è stato rilasciato, la data di emissione, quella di scadenza, una firma digitale utile per il riconoscimento del server da parte del client e una chiave pubblica che lo stesso userà per criptare i dati. Un certificato SSL può essere:
- autogenerato usando un apposito tool nel contesto Java, ma non verrà considerato valido da parte dei browser dei client che si connettono al server, poiché l’autorità certificatrice (CA) che lo emetterà saremo proprio noi stessi;
- rilasciato da un’autorità certificatrice (CA) nota, che dopo una procedura di verifica emetterà il certificato (alcuni sono gratuiti, ma possiedono una ridotta validità temporale) in relazione ad uno specifico dominio, assicurandosi che lo stesso sia gestito da colui che ha richiesto il certificato.
Supponendo di trovarci in un ambiente didattico o di test, adottiamo la prima soluzione (per la seconda seguirà un articolo dedicato). La prima operazione da compiere è recarsi nella cartella “conf” dell’installazione di Tomcat sul nostro server (di consuetudine è “/opt/tomcat/conf”), attraverso un terminale da remoto, sfruttando una connessione SSH, oppure recandoci sulla macchina server di nostro interesse, aprendo un classico terminale. Giunti nella directory citata si esegue questo comando per autogenerare il certificato:
keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: Antonio Tortona What is the name of your organizational unit? [Unknown]: Dev What is the name of your organization? [Unknown]: AntonioTortonaCompany What is the name of your City or Locality? [Unknown]: Benevento What is the name of your State or Province? [Unknown]: Campania What is the two-letter country code for this unit? [Unknown]: IT Is CN= Antonio Tortona, OU=Dev, O=AntonioTortonaCompany, L=Benevento, ST=Campania, C=IT correct? [no]: Yes
Il prossimo passo è modificare il file di configurazione di Tomcat “server.xml”, che risiede all’interno della medesima directory in cui abbiamo generato il certificato: attraverso un editor di testo, quali in ambiente Linux, Nano o Vim, decommentiamo la seguente riga di codice, se già presente, altrimenti la si aggiunge manualmente:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/keystore.jks"
certificateKeystorePassword="password_keystore"
type="RSA" />
</SSLHostConfig>
</Connector>
Attenzioniamo alcuni attributi fondamentali in questo snippet:
- port: è la porta su cui il nostro demone si porrà in ascolto per richieste HTTPS;
- certificateKeystoreFile: è il percorso del keystore che contiene il certificato SSL autogenerato;
- certificateKeystorePassword: è la password che ci è stata richiesta di inserire subito dopo aver lanciato il comando keytool per generale il certificato.
La configurazione è giunta al termine, ma solitamente una delle best practices è reindirizzare tutte le richieste che pervengono al server sulla porta 8080 o 80, mediante il protocollo HTTP, sulla sua porta 8443 in maniera tale da garantire l’uso in automatico dell’HTTPS. A tal fine devono essere apportate delle modifiche a due file di configurazione di Tomcat, il già citato “server.xml” e “web.xml”, entrambi presenti nella directory “conf”. Nel primo file, troviamo le seguenti righe di codice e modifichiamo l’attributo “redirectPort”, inserendo la porta su cui reindirizzare le richieste giunte con protocollo HTTP:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
A tal fine suggerisco di considerare un fattore importante in questo processo di reindirizzamento: nel caso in cui si utilizzi un port mapping, implementato sul router, che consenta dall’esterno della rete (cioè, da Internet) di raggiungere il web server, allora sarà necessario valorizzare l’attributo “redirectPort” con la porta aperta dell’interfaccia pubblica del router, a cui è mappata quella LAN del server. Propongo a titolo di esempio la seguente configurazione di port forwarding:
| Porta LAN – Porta Demone Server | Porta WAN – Porta Interfaccia Pubblica Router | Protocollo |
| 8080 | 80 | HTTP |
| 8443 | 443 | HTTPS |
Sulla base di quanto affermato precedentemente il valore dell’attributo “redirectPort” dovrà essere 443 e NON 8443, poiché accade quanto segue: il client invia una richiesta al router sulla porta 80, che la inoltra al server in rete locale sulla 8080. In seguito, il server invia una risposta al client con la quale suggerisce di contattare il router sulla porta 443 (valore attributo “redirectPort”). La nuova richiesta giunta al router viene correttamente inoltrata al server sulla porta 8443. Questo processo dimostra intuitivamente cosa accadrebbe se il server reindirizzasse il client sulla porta 8443, cioè se tale sarebbe il valore dell’attributo “redirectPort”: in questo caso il client invia una richiesta alla porta 8443 del router che risulterà chiusa, portando al fallimento il tentativo di redirecting. La fase conclusiva prevede l’aggiunta del seguente snippet al file web.xml:
<security-constraint> <web-resource-collection> <web-resource-name>Entire Application</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>
Se sul server è presente un personal firewall sarà necessario aprire le porte 8080 e 8443, o qualunque altre scelte su cui porre in ascolto il demone per richieste HTTP e HTTPS. Il firewall più comune in ambiente Linux è UFW e per abilitare le porte sarà sufficiente digitare i seguenti comandi:
ufw allow 8080 ufw allow 8443
Lascia un commento