HSTS: Apache2 in sicurezza

Vediamo come sia possibile aumentare la sicurezza di un sito web che già utilizza il protocollo di comunicazione HTTPS + SSL (qui un articolo su come installarlo su un sito per WordPress) nel caso specifico un server che utilizza Apache2 come webserver.

Le condizioni di partenza che assumo come predefinite per questo articolo quindi saranno la presenza di un web server Apache ramo della versione 2.4, il protocollo HTTPS con relativo certificato SSL già installato e il/i Virtual Host già configurati e pubblicati. Quindi dal punto di vista materiale il sito funziona e sarà visitabile in HTTPS con certificato privo di errori.

Ovviamente vi starete chiedendo, ma non è già abbastanza? Quasi.. in questo senso andremo ad applicare un meccanismo di sicurezza che prende il nome di HSTS, acronimo di HTTP Strict Transport Security. Per spiegarlo un piccolo passo indietro.

SSL Stripping

HTTPS + SSL da solo funziona, il problema deriva quando un potenziale attaccante riesce ad inserirsi nella comunicazione attraverso un Proxy che permette di girare una comunicazione HTTP in HTTPS facendo credere all’utente finale di essere in tutto e per tutto all’interno di un sito protetto da un certificato che ne comprova la veridicità. In effetti il browser mostrerà il classico lucchetto come favicon, ma il sito mostrato non sarà realmente quello. Chiaramente si tratta di un attacco che preveda l’intromissione delle comunicazioni tra HTTP e HTTPS di un server, non è una condizione semplice ma nemmeno improbabile.

HSTS

Qui interviene HSTS, di fatto è un meccanismo in cui si dichiara che il sito con header HTTP è utilizzabile solo con protocollo HTTPS abbinato ad una crittografia di tipo SSL/TLS. Questa direttiva lato server prevede obbligatoriamente una scadenza temporale, che poi vedremo a breve essere di fatto il minimo un anno di tempo. E’ inoltre possibile prevedere altri parametri che di fatto saranno anch’essi praticamente obbligatori e sono Include Subdomains (mi pare si spieghi da solo) e preload.

Quindi come avrete intuito questa direttiva ha effetto per l’utente la prima volta che visita il vostro sito e scadrà dopo un certo tempo. Ne consegue che la prima visita in realtà non sia protetta. Mozilla e Chrome hanno adottato un sistema nativo che permette il precaricamento, cioè un elenco di siti che adottano HSTS. Quindi se il vostro sito è in tale lista, il browser conoscerà la direttiva HSTS prima che lo visitiate. 

Aderire alla lista è gratuito e richiede qualche secondo per la candidatura, decisamente un tempo maggiore per essere approvati. Questa procedura è approvata, anzi direi sostenuta da Google, che nella sua Search Console la propone come “buona prassi” per essere meglio listati nelle ricerche.

Come si installa

Tutto il “pippone” di cui sopra per spiegare il motivo, in realtà poi il lato pratico della vicenda è molto più semplice.

La prima cosa da fare è verificare che il Virtual Host di Apache abbia una direttiva che dalla porta 80 ci traslochi nella porta 443. In pratica chi scrivesse il sito http://www.tosolini.info verrà automaticamente re-direzionato su https://www.tosolini.info, senza nessun intervento da parte dell’utente. Quindi non dovremo preoccuparci di cosa combinano “dall’altra parte”. La direttiva è piuttosto semplice, aperto il file di configurazione del Virtual Host che desideriamo modificare (solitamente sotto /etc/apache2/sites-available/XYZ.conf) dovremo ottenere qualcosa di questo genere:

<VirtualHost *:80>
    ServerAdmin support@tosolini.info
	ServerName tosolini.info
	ServerAlias www.tosolini.info
	
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [END,NE,R=permanent]
  </IfModule>
	  
</VirtualHost>

La parte che dovete copiare è quella racchiusa nell’IfModule. Come si può vedere viene presa la richiesta è rigirata così come è stata ricevuta, in HTTPS. Tutto ciò funziona grazie ad un modulo di apache, appunto mod_rewrite che sarà necessario avere già attivo. Qui sotto vi spiego come  attivarne due, uno relativo a quest’ultimo, l’altro ci servirà dopo :

sudo a2enmod rewrite headers
sudo service apache2 restart

Con la prima riga attiviamo due moduli, appunto rewrite e headers, con la seconda riavviamo Apache. Non devono esserci errori, se ci sono vedete a video cosa vi viene indicato, il sistema è molto verboso e indica in modo preciso cosa non gli è piaciuto.

A questo punto siamo pronti per attivare HSTS, queste direttive andranno anch’esse applicate all’interno del file di configurazione del Virtual Host che ha in carico la porta 443. Quindi se avete un file di configurazione separato andrà applicata li, oppure se il file è lo stesso nella apposita sezione. Cito solo per cronaca che è possibile applicare le direttive HSTS anche a livello globale nel file apache2.conf, ma siccome è probabile che il server abbia più domini e magari pure un certo numero di cambiamenti durante l’anno, a mio avviso è meglio operare per singolo Virtual Host.

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin support@tosolini.info
	ServerName tosolini.info
	ServerAlias www.tosolini.info
    SSLEngine on
    SSLCertificateFile /path/to/tosolini.info.cert
    SSLCertificateKeyFile /path/to/tosolini.info.key
	
	Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"
	Header always set X-Frame-Options DENY
	
    DocumentRoot /var/www/
</VirtualHost>
</IfModule>

La direttiva di HSTS è la prima delle due Header (modulo apache caricato poco prima). Come vediamo essa ha una scadenza, in questo caso un anno, sono inclusi tutti i sotto-domini ed è previsto il preload.

La seconda header non è parte di HSTS, ma in realtà ovvia ad un secondo potenziale problema, ovvero quello di mostrare il vostro sito all’interno di una pagina del sito di qualcun altro. Iframe se ben maneggiato può essere pericoloso perché nel server di qualcun’altro, con il suo certificato, andremo a mostrare un sito terzo. Con questa direttiva Apache si accorge di essere stato inglobato e si rifiuta di processare l’istruzione. Come dice il detto, meglio prevenire che curare.

Ci siamo quasi, riavviamo Apache e non dobbiamo avere errori lato server e tantomeno lato client visitando il sito. Ora non ci resta che sottoporre il nostro sito a partecipare alla lista di preload. Questa procedura prevede, oltre la direttiva di pre-caricamento anche un tempo minimo di un anno. La candidatura la faremo attraverso questa semplice procedura dove appunto il sito verrà verificato, e se tecnicamente idoneo potrete inviare la richiesta come si vede nell’immagine sottostante.

Conclusioni

Si tratta di un ulteriore livello di sicurezza che è bene avere a prescindere. Se già teniamo una condotta regolare sull’applicazione di patch e aggiornamenti del sistema operativo e dei software installati abbiamo una ragionevole certezza di essere coperti da eventuali bachi. Ma aggiungere degli ulteriori strati di sicurezza ci permetterà di chiudere anche le percentuali zero virgola qualcosa di statistica che magari un giorno potrebbero cagionare danni di immagine e tecnici non da poco.