Sempre più servizi in rete cercano di con­sen­ti­re agli utenti un accesso sicuro ai contenuti su Internet. Per questo nel World Wide Web si è affermato il pro­to­col­lo di crit­to­gra­fia TLS (Transport Layer Security) che ha raggiunto una notevole fama con la pre­ce­den­te de­no­mi­na­zio­ne di SSL (Secure Sockets Layer). Mentre le con­nes­sio­ni tramite HTTP (Hypertext Transfer Protocol) avvengono senza crit­to­gra­fia, il pro­to­col­lo di rete HTTPS (“Hypertext Transfer Protocol Secure” o “Hypertext Transfer Protocol over SSL/TLS”) offre la pos­si­bi­li­tà di strut­tu­ra­re il traffico dati sul web in modo più sicuro grazie alla crit­to­gra­fia SSL/TLS.

Anche il gigante di Internet Google dà il buon esempio e offre i suoi servizi web molto visitati esclu­si­va­men­te tramite crit­to­gra­fia SSL/TLS. A partire dall’agosto del 2014, il pro­to­col­lo HTTPS rientra inoltre tra i fattori di ranking tenuti in con­si­de­ra­zio­ne dall’algoritmo della ricerca web organica. Così è no­te­vol­men­te aumentata l’im­por­tan­za di una crit­to­gra­fia di trasporto basata su SSL/TLS per i web master. Ma il pro­to­col­lo HTTPS nella sua con­fi­gu­ra­zio­ne standard non presenta una pro­te­zio­ne af­fi­da­bi­le.

Sempre più spesso gli esperti in­for­ma­ti­ci scoprono nuove falle di sicurezza. I pericoli si insinuano so­prat­tut­to con gli attacchi man in the middle che con­sen­to­no agli hacker di annullare la crit­to­gra­fia SSL/TLS. Solo dal 2012 è stato messo a di­spo­si­zio­ne con la procedura HSTS un mec­ca­ni­smo di sicurezza per le con­nes­sio­ni HTTPS che blocca gli attacchi di questo tipo.

Vul­ne­ra­bi­li­tà della tecnica HTTPS

Se un sito viene aperto tramite il pro­to­col­lo di rete HTTPS e un af­fi­da­bi­le cer­ti­fi­ca­to SSL/TLS, questo tipo di crit­to­gra­fia sul livello di trasporto è es­sen­zial­men­te sicura. In passato si sono sempre ve­ri­fi­ca­ti attacchi agli enti di cer­ti­fi­ca­zio­ne dai quali ne è con­se­gui­to che erano in cir­co­la­zio­ne mol­tis­si­mi cer­ti­fi­ca­ti poco sicuri. Inoltre le abitudini diffuse degli utenti e la generale di­sat­ten­zio­ne quando si tratta di con­nes­sio­ni crit­to­gra­fa­te offrono in generale numerosi punti deboli soggetti ad attacchi di phishing e man in the middle.

De­via­zio­ne da HTTP a HTTPS

È raro che gli utenti in­se­ri­sca­no gli URL in­te­ra­men­te. Molto più spesso gli indirizzi Internet vengono sem­pli­ce­men­te ridotti al loro dominio. Il pro­to­col­lo di rete HTTPS che deve garantire la con­nes­sio­ne crit­to­gra­fa­ta non viene perciò inserito e viene quindi omesso. Se un utente digita, ad esempio, al posto di https:// example.com solo example.com nella barra degli indirizzi del suo browser, viene evi­den­te­men­te aggiunto nell’URL au­to­ma­ti­ca­men­te, al momento dell’in­ter­pre­ta­zio­ne della richiesta eseguita, il pro­to­col­lo di rete standard per le vi­sua­liz­za­zio­ni delle pagine web, ovvero HTTP.

example.com -> http:// example.com

Se la pagina di de­sti­na­zio­ne risulta essere un sito crit­to­gra­fa­to, avviene infine un rein­di­riz­za­men­to lato server da HTTP a HTTPS.

http:// example.com -> https:// example.com

Così viene stabilita una con­nes­sio­ne crit­to­gra­fa­ta, ma la de­via­zio­ne dall’URL non sicuro dà la pos­si­bi­li­tà agli hacker di po­si­zio­nar­si già prima senza che l’utente se ne accorga, come man in the middle tra il browser e il server. In questo caso il traffico dati com­ples­si­vo può essere letto come testo in chiaro, senza che gli hacker si debbano impegnare a decifrare la crit­to­gra­fia SSL/TLS. Se la pagina di de­sti­na­zio­ne è una banca o uno shop online, questa falla di sicurezza può avere delle gravi con­se­guen­ze per quegli utenti che am­mi­ni­stra­no la propria gestione fi­nan­zia­ria online.

Chiariamo questo concetto con un esempio: in diversi luoghi sono messi a di­spo­si­zio­ne degli accessi Wi-Fi pubblici. Gli utenti poco attenti vi si con­net­to­no spesso senza con­trol­la­re chi fornisce l’accesso a Internet. Gli hacker si servono di questa di­sat­ten­zio­ne per segnalare il proprio computer come hotspot e rilevare il traffico dati com­ples­si­vo. Se uno degli utenti vi­sua­liz­za il sito della sua banca mentre è connesso a uno di questi pseudo hotspot che sono per comodità non crit­to­gra­fa­ti, l’hacker ha la pos­si­bi­li­tà di eseguire in­di­stur­ba­to un redirect a un sito di phishing prima che il server della banca online abbia la pos­si­bi­li­tà di dirottare la con­nes­sio­ne HTTP su HTTPS.

SSL Stripping

Una tecnica con cui si possono neu­tra­liz­za­re le con­nes­sio­ni HTTPS classiche è stata di­mo­stra­ta già nel 2009 nell’ambito di una con­fe­ren­za sulla sicurezza Black Hat da Moxie Mar­lin­spi­ke, Cy­pher­punk e i fondatori di Open Whisper Systems, con l’au­to­svi­lup­pa­ta tecnica di SSL Stripping. Per mostrare la vul­ne­ra­bi­li­tà del pro­to­col­lo HTTPS, Mar­lin­spi­ke ha svi­lup­pa­to il software proxy SSLStrip, che sfrutta la falla di sicurezza che deriva dal rein­di­riz­za­men­to dall’URL HTTP a quello HTTPS e trasforma tutte le richieste HTTPS del browser in richieste HTTP dello stesso tenore. Mentre SSLStrip sta­bi­li­sce una con­nes­sio­ne HTTP non protetta al browser dell’utente, il programma comunica con il server sul livello HTTPS. All’utente viene fatto credere di avere a che fare con una con­nes­sio­ne sicura, mo­stran­do­gli un favicon con la forma di un lucchetto. La premessa per un attacco di questo tipo è che l’hacker riesca a leggere la co­mu­ni­ca­zio­ne tra browser e server. Una soluzione al problema di sicurezza sollevato da Mar­lin­spi­ke è stata pre­sen­ta­ta dall’Internet En­gi­nee­ring Task Force (IETF) solo tre anni dopo: nel 2012 è stata spe­ci­fi­ca­ta l’im­ple­men­ta­zio­ne HTTPS HTTP Strict Transport Security (HSTS) nel RFC 6797.

Che cos’è HSTS?

HSTS (HTTP Strict Transport Security) è un mec­ca­ni­smo di sicurezza che è stato svi­lup­pa­to per pro­teg­ge­re le con­nes­sio­ni HTTPS contro gli attacchi man in the middle e l’hijacking delle sessioni. Con l’im­ple­men­ta­zio­ne HTTPS i web master possono segnalare ai browser, tramite in­for­ma­zio­ni opzionali nell’header HTTP, che un sito può essere ri­chia­ma­to per un arco di tempo definito esclu­si­va­men­te per mezzo della crit­to­gra­fia SSL/TLS. Per questo viene uti­liz­za­to il campo di in­te­sta­zio­ne Strict-Transport-Security lato server, che comprende la direttiva ob­bli­ga­to­ria max-age e può essere ampliato con le direttive opzionali in­clu­de­Sub­Do­mains e preload:

Strict-Transport-Security: max-age=31536000

La direttiva max-age indica per quanto tempo un sito deve rimanere a di­spo­si­zio­ne crit­to­gra­fa­to. L’arco di tempo coinvolto viene definito in secondi. Un max-age di 31.536.000 secondi cor­ri­spon­de quindi a un periodo di un anno.

Se un utente visita un sito protetto da HSTS per la prima volta, il browser riceve le seguenti istru­zio­ni dal campo dell’in­te­sta­zio­ne Strict-Transport-Security:

  • Tutti i link non crit­to­gra­fa­ti al ri­spet­ti­vo sito devono essere con­ver­ti­ti in link crit­to­gra­fa­ti (http:// diventa https://).
  • Se la sicurezza di una con­nes­sio­ne non può essere garantita, ad esempio per via di un cer­ti­fi­ca­to non valido, deve essere in­ter­rot­ta. L’utente vi­sua­liz­ze­rà così un messaggio di errore.

In al­ter­na­ti­va c’è la pos­si­bi­li­tà di estendere le in­for­ma­zio­ni HSTS ai sot­to­do­mi­ni. In questo caso il campo dell’in­te­sta­zio­ne Strict-Transport-Security viene aggiunto alla direttiva in­clu­de­Sub­Do­mains, che segnala al browser come l’header HSTS non valga solo per l’host attuale (ad esempio www.example.com), ma anche per tutti i sot­to­do­mi­ni del ri­spet­ti­vo dominio (ad esempio anche per blog.example.com o adserver.example.com).

Strict-Transport-Security: max-age=31536000; in­clu­de­Sub­Do­mains

La direttiva preload consente di evi­den­zia­re le pagine web per il così chiamato “pre­loa­ding”, per risolvere la questione che si verifica alla prima visita.

Strict-Transport-Security: max-age=31536000; in­clu­de­Sub­Do­mains; preload

Senza il parametro preload, HSTS si ri­per­cuo­te solo sulle visite future alle pagine: se un browser conosce le in­for­ma­zio­ni nell’header HSTS di un sito, le suc­ces­si­ve vi­sua­liz­za­zio­ni vengono messe in atto con­se­guen­te­men­te. La prima volta che si vi­sua­liz­za un sito non si ricorre a questo mec­ca­ni­smo di sicurezza. I pro­dut­to­ri di browser come Google e Mozilla offrono perciò la pos­si­bi­li­tà di inserire le pagine web in co­sid­det­te liste di preload. Le pagine web che sono state re­gi­stra­te per un pre­loa­ding sono vi­sua­liz­za­bi­li solo tramite HTTPS. Le liste di preload vengono con­trol­la­te cen­tral­men­te dai pro­dut­to­ri del browser e co­mu­ni­ca­te al browser degli utenti durante gli ag­gior­na­men­ti.

Liste di preload per pagine HTTPS

Visto che l’HSTS funziona solo quando un sito è stato ri­chia­ma­to in passato almeno una volta at­tra­ver­so una con­nes­sio­ne non ma­ni­po­la­bi­le HTTPS, ogni prima visita è es­sen­zial­men­te soggetta agli attacchi SSL Stripping. Per evitarlo tutti i browser comuni ricorrono og­gi­gior­no a liste che si basano su un servizio HSTS di preload, che è messo a di­spo­si­zio­ne da Google nell’ambito del progetto Chromium. Es­sen­zial­men­te ogni web master ha la libertà di inserire il proprio dominio nella lista HSTS di preload. L’ac­cet­ta­zio­ne di un sito, però, è legata a dei requisiti di base che devono garantire la qualità del sistema di controllo:

  • Tutte le pagine web devono re­sti­tui­re un cer­ti­fi­ca­to SSL valido.
  • Gli URL HTTP devono essere inoltrati sugli URL HTTPS dello stesso host.
  • Tutti i sot­to­do­mi­ni (com­pren­si­vi del sot­to­do­mi­nio www) devono essere ri­chia­ma­ti tramite HTTPS.
  • L’header HSTS deve essere fornito tramite il dominio di base con i seguenti parametri:
    • Il valore di max-age deve essere almeno pari a 8 settimane (4.838.400 secondi).
    • L’header HSTS deve com­pren­de­re la direttiva in­clu­de­Sub­Do­mains.
    • L’header HSTS deve contenere la direttiva preload.
    • Tutti i rein­di­riz­za­men­ti ag­giun­ti­vi del sito HTTPS devono includere l’header HSTS.

Tra gli utenti famosi che uti­liz­za­no le funzioni HSTS di preload rientrano Google, Paypal, Twitter e LastPass. La lista completa dei domini inseriti si trova sul sito del progetto Chromium.

Impostare HSTS: breve guida per Apache2, Lighttpd e NGINX

I servizi online, che vor­reb­be­ro pro­teg­ge­re il loro progetto contro l’SSL Stripping tramite HSTS, devono con­fi­gu­ra­re il loro web server ap­pro­pria­ta­men­te. La seguente breve guida indica la con­fi­gu­ra­zio­ne HSTS per Apache, NGINX, Lighttpd e Microsoft IIS.

Apache HTTP Server

Affinché HSTS possa venir uti­liz­za­to sul server Apache, deve essere prima di tutto attivato il modulo header Apache (mod_headers). I web master in­se­ri­sco­no quindi i seguenti comandi nel terminale:

sudo a2enmod headers

Se il modulo header Apache viene attivato, il web server deve essere riavviato nuo­va­men­te:

sudo service apache restart

Il server Apache offre la pos­si­bi­li­tà di gestire diversi domini sullo stesso server. Ognuno di questi domini viene indicato nella ter­mi­no­lo­gia Apache come Vir­tua­lHo­st (vhost) e con­fi­gu­ra­to sul server, in­di­pen­den­te­men­te dagli altri domini. Visto che nel caso di HSTS si tratta di un’im­ple­men­ta­zio­ne per HTTPS, questo mec­ca­ni­smo di sicurezza è messo a di­spo­si­zio­ne solo per i Vir­tua­lHo­st con il numero di porta 443, ovvero la porta standard per le con­nes­sio­ni HTTPS. Per forzare la con­nes­sio­ne crit­to­gra­fa­ta di un sito HTTPS in pre­vi­sio­ne di future visite, i web master ag­giun­go­no il Vir­tua­lHo­st de­si­de­ra­to nel file di con­fi­gu­ra­zio­ne Apache https.conf nella riga seguente:

Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"

In aggiunta il campo header Strict-Transport-Security viene scritto insieme alle altre direttive nel container Vir­tua­lHo­st:

<VirtualHost *:443>
    ServerAdmin support@example.com
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key
    […]
    Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"
    DocumentRoot /var/www/
</VirtualHost>

Ogni volta che un browser richiama il sito così con­fi­gu­ra­to, Apache re­sti­tui­sce un header HSTS con i parametri de­si­de­ra­ti. In questo esempio il browser viene in­ca­ri­ca­to di ri­chia­ma­re le pagine web del dominio example.com com­pren­si­vo di sot­to­do­mi­ni solo con la crit­to­gra­fia SSL/TLS per le prossime otto settimane.

Per applicare la con­fi­gu­ra­zio­ne impostata, è ne­ces­sa­rio riavviare Apache.

NGINX

Anche su NGINX si possono forzare le con­nes­sio­ni crit­to­gra­fa­te tramite SSL/TLS at­tra­ver­so una semplice riga di codice:

add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";

La modifica avviene nel file di con­fi­gu­ra­zio­ne /etc/nginx/nginx.conf. Al posto del Vir­tua­lHo­st vengono uti­liz­za­ti su NGINX i co­sid­det­ti server blocks, per definire le direttive:

server {
    listen      443 ssl;
    server_name    example.com;
    ssl_certificate  www.example.com.crt;
    ssl_certificate_key  www.example.com.key;
    […]
    add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
}

È ne­ces­sa­rio riavviare anche NGINX dopo la con­fi­gu­ra­zio­ne.

Lighttpd

Pour activer HSTS sur Lighttpd, il suffit de modifier le fichier de con­fi­gu­ra­tion /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}

Le im­po­sta­zio­ni diventano effettive dopo il riavvio del web server.

Microsoft IIS

Di­ver­sa­men­te da Apache, NGINX e Lighttpd, il web server di Microsoft Internet In­for­ma­tion Services (IIS) viene con­fi­gu­ra­to tramite un’in­ter­fac­cia grafica. Per attivare HSTS, i web master procedono nel modo seguente:

  • Attivano l’IIS manager e se­le­zio­na­no il sito de­si­de­ra­to.
  • Se­le­zio­na­no la voce del menu “HTTP Response Header” e cliccano su “Add”.
  • Nella finestra di dialogo “Add Custom HTTP Response Header” alla voce “Name” in­se­ri­sco­no Strict-Transport-Security e su “Value” de­fi­ni­sco­no il periodo di tempo richiesto in secondi.

Infine IIS deve essere riavviato.

Vai al menu prin­ci­pa­le