HSTS: come funziona l’implementazione HTTPS

Sempre più servizi in rete cercano di consentire agli utenti un accesso sicuro ai contenuti su Internet. Per questo nel World Wide Web si è affermato il protocollo di crittografia TLS (Transport Layer Security) che ha raggiunto una notevole fama con la precedente denominazione di SSL (Secure Sockets Layer). Mentre le connessioni tramite HTTP (Hypertext Transfer Protocol) avvengono senza crittografia, il protocollo di rete HTTPS (“Hypertext Transfer Protocol Secure” o “Hypertext Transfer Protocol over SSL/TLS”) offre la possibilità di strutturare il traffico dati sul web in modo più sicuro grazie alla crittografia SSL/TLS.

Anche il gigante di Internet Google dà il buon esempio e offre i suoi servizi web molto visitati esclusivamente tramite crittografia SSL/TLS. A partire dall’agosto del 2014, il protocollo HTTPS rientra inoltre tra i fattori di ranking tenuti in considerazione dall’algoritmo della ricerca web organica. Così è notevolmente aumentata l’importanza di una crittografia di trasporto basata su SSL/TLS per i web master. Ma il protocollo HTTPS nella sua configurazione standard non presenta una protezione affidabile.

Sempre più spesso gli esperti informatici scoprono nuove falle di sicurezza. I pericoli si insinuano soprattutto con gli attacchi man in the middle che consentono agli hacker di annullare la crittografia SSL/TLS. Solo dal 2012 è stato messo a disposizione con la procedura HSTS un meccanismo di sicurezza per le connessioni HTTPS che blocca gli attacchi di questo tipo.

Vulnerabilità della tecnica HTTPS

Se un sito viene aperto tramite il protocollo di rete HTTPS e un affidabile certificato SSL/TLS, questo tipo di crittografia sul livello di trasporto è essenzialmente sicura. In passato si sono sempre verificati attacchi agli enti di certificazione dai quali ne è conseguito che erano in circolazione moltissimi certificati poco sicuri. Inoltre le abitudini diffuse degli utenti e la generale disattenzione quando si tratta di connessioni crittografate offrono in generale numerosi punti deboli soggetti ad attacchi di phishing e man in the middle.

Deviazione da HTTP a HTTPS

È raro che gli utenti inseriscano gli URL interamente. Molto più spesso gli indirizzi Internet vengono semplicemente ridotti al loro dominio. Il protocollo di rete HTTPS che deve garantire la connessione crittografata 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 evidentemente aggiunto nell’URL automaticamente, al momento dell’interpretazione della richiesta eseguita, il protocollo di rete standard per le visualizzazioni delle pagine web, ovvero HTTP.

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

Se la pagina di destinazione risulta essere un sito crittografato, avviene infine un reindirizzamento lato server da HTTP a HTTPS.

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

Così viene stabilita una connessione crittografata, ma la deviazione dall’URL non sicuro dà la possibilità agli hacker di posizionarsi 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 complessivo può essere letto come testo in chiaro, senza che gli hacker si debbano impegnare a decifrare la crittografia SSL/TLS. Se la pagina di destinazione è una banca o uno shop online, questa falla di sicurezza può avere delle gravi conseguenze per quegli utenti che amministrano la propria gestione finanziaria online.

Chiariamo questo concetto con un esempio: in diversi luoghi sono messi a disposizione degli accessi Wi-Fi pubblici. Gli utenti poco attenti vi si connettono spesso senza controllare chi fornisce l’accesso a Internet. Gli hacker si servono di questa disattenzione per segnalare il proprio computer come hotspot e rilevare il traffico dati complessivo. Se uno degli utenti visualizza il sito della sua banca mentre è connesso a uno di questi pseudo hotspot che sono per comodità non crittografati, l’hacker ha la possibilità di eseguire indisturbato un redirect a un sito di phishing prima che il server della banca online abbia la possibilità di dirottare la connessione HTTP su HTTPS.

SSL Stripping

Una tecnica con cui si possono neutralizzare le connessioni HTTPS classiche è stata dimostrata già nel 2009 nell’ambito di una conferenza sulla sicurezza Black Hat da Moxie Marlinspike, Cypherpunk e i fondatori di Open Whisper Systems, con l’autosviluppata tecnica di SSL Stripping. Per mostrare la vulnerabilità del protocollo HTTPS, Marlinspike ha sviluppato il software proxy SSLStrip, che sfrutta la falla di sicurezza che deriva dal reindirizzamento dall’URL HTTP a quello HTTPS e trasforma tutte le richieste HTTPS del browser in richieste HTTP dello stesso tenore. Mentre SSLStrip stabilisce una connessione 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 connessione sicura, mostrandogli un favicon con la forma di un lucchetto. La premessa per un attacco di questo tipo è che l’hacker riesca a leggere la comunicazione tra browser e server. Una soluzione al problema di sicurezza sollevato da Marlinspike è stata presentata dall’Internet Engineering Task Force (IETF) solo tre anni dopo: nel 2012 è stata specificata l’implementazione HTTPS HTTP Strict Transport Security (HSTS) nel RFC 6797.

Che cos’è HSTS?

HSTS (HTTP Strict Transport Security) è un meccanismo di sicurezza che è stato sviluppato per proteggere le connessioni HTTPS contro gli attacchi man in the middle e l’hijacking delle sessioni. Con l’implementazione HTTPS i web master possono segnalare ai browser, tramite informazioni opzionali nell’header HTTP, che un sito può essere richiamato per un arco di tempo definito esclusivamente per mezzo della crittografia SSL/TLS. Per questo viene utilizzato il campo di intestazione Strict-Transport-Security lato server, che comprende la direttiva obbligatoria max-age e può essere ampliato con le direttive opzionali includeSubDomains e preload:

Strict-Transport-Security: max-age=31536000

La direttiva max-age indica per quanto tempo un sito deve rimanere a disposizione crittografato. L’arco di tempo coinvolto viene definito in secondi. Un max-age di 31.536.000 secondi corrisponde 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 istruzioni dal campo dell’intestazione Strict-Transport-Security:

  • Tutti i link non crittografati al rispettivo sito devono essere convertiti in link crittografati (http:// diventa https://).
  • Se la sicurezza di una connessione non può essere garantita, ad esempio per via di un certificato non valido, deve essere interrotta. L’utente visualizzerà così un messaggio di errore.

In alternativa c’è la possibilità di estendere le informazioni HSTS ai sottodomini. In questo caso il campo dell’intestazione Strict-Transport-Security viene aggiunto alla direttiva includeSubDomains, 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 sottodomini del rispettivo dominio (ad esempio anche per blog.example.com o adserver.example.com).

Strict-Transport-Security: max-age=31536000; includeSubDomains

La direttiva preload consente di evidenziare le pagine web per il così chiamato “preloading”, per risolvere la questione che si verifica alla prima visita.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Senza il parametro preload, HSTS si ripercuote solo sulle visite future alle pagine: se un browser conosce le informazioni nell’header HSTS di un sito, le successive visualizzazioni vengono messe in atto conseguentemente. La prima volta che si visualizza un sito non si ricorre a questo meccanismo di sicurezza. I produttori di browser come Google e Mozilla offrono perciò la possibilità di inserire le pagine web in cosiddette liste di preload. Le pagine web che sono state registrate per un preloading sono visualizzabili solo tramite HTTPS. Le liste di preload vengono controllate centralmente dai produttori del browser e comunicate al browser degli utenti durante gli aggiornamenti.

Liste di preload per pagine HTTPS

Visto che l’HSTS funziona solo quando un sito è stato richiamato in passato almeno una volta attraverso una connessione non manipolabile HTTPS, ogni prima visita è essenzialmente soggetta agli attacchi SSL Stripping. Per evitarlo tutti i browser comuni ricorrono oggigiorno a liste che si basano su un servizio HSTS di preload, che è messo a disposizione da Google nell’ambito del progetto Chromium. Essenzialmente ogni web master ha la libertà di inserire il proprio dominio nella lista HSTS di preload. L’accettazione di un sito, però, è legata a dei requisiti di base che devono garantire la qualità del sistema di controllo:

  • Tutte le pagine web devono restituire un certificato SSL valido.
  • Gli URL HTTP devono essere inoltrati sugli URL HTTPS dello stesso host.
  • Tutti i sottodomini (comprensivi del sottodominio www) devono essere richiamati 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 comprendere la direttiva includeSubDomains.
    • L’header HSTS deve contenere la direttiva preload.
    • Tutti i reindirizzamenti aggiuntivi del sito HTTPS devono includere l’header HSTS.

Tra gli utenti famosi che utilizzano 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 vorrebbero proteggere il loro progetto contro l’SSL Stripping tramite HSTS, devono configurare il loro web server appropriatamente. La seguente breve guida indica la configurazione HSTS per Apache, NGINX, Lighttpd e Microsoft IIS.

Apache HTTP Server

Affinché HSTS possa venir utilizzato sul server Apache, deve essere prima di tutto attivato il modulo header Apache (mod_headers). I web master inseriscono quindi i seguenti comandi nel terminale:

sudo a2enmod headers

Se il modulo header Apache viene attivato, il web server deve essere riavviato nuovamente:

sudo service apache restart

Il server Apache offre la possibilità di gestire diversi domini sullo stesso server. Ognuno di questi domini viene indicato nella terminologia Apache come VirtualHost (vhost) e configurato sul server, indipendentemente dagli altri domini. Visto che nel caso di HSTS si tratta di un’implementazione per HTTPS, questo meccanismo di sicurezza è messo a disposizione solo per i VirtualHost con il numero di porta 443, ovvero la porta standard per le connessioni HTTPS. Per forzare la connessione crittografata di un sito HTTPS in previsione di future visite, i web master aggiungono il VirtualHost desiderato nel file di configurazione 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 VirtualHost:

<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ì configurato, Apache restituisce un header HSTS con i parametri desiderati. In questo esempio il browser viene incaricato di richiamare le pagine web del dominio example.com comprensivo di sottodomini solo con la crittografia SSL/TLS per le prossime otto settimane.

Per applicare la configurazione impostata, è necessario riavviare Apache.

NGINX

Anche su NGINX si possono forzare le connessioni crittografate tramite SSL/TLS attraverso una semplice riga di codice:

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

La modifica avviene nel file di configurazione /etc/nginx/nginx.conf. Al posto del VirtualHost vengono utilizzati su NGINX i cosiddetti 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";
}

È necessario riavviare anche NGINX dopo la configurazione.

Lighttpd

Pour activer HSTS sur Lighttpd, il suffit de modifier le fichier de configuration /etc/lighttpd/lighttpd.conf:

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

Le impostazioni diventano effettive dopo il riavvio del web server.

Microsoft IIS

Diversamente da Apache, NGINX e Lighttpd, il web server di Microsoft Internet Information Services (IIS) viene configurato tramite un’interfaccia grafica. Per attivare HSTS, i web master procedono nel modo seguente:

  • Attivano l’IIS manager e selezionano il sito desiderato.
  • Selezionano la voce del menu “HTTP Response Header” e cliccano su “Add”.
  • Nella finestra di dialogo “Add Custom HTTP Response Header” alla voce “Name” inseriscono Strict-Transport-Security e su “Value” definiscono il periodo di tempo richiesto in secondi.

Infine IIS deve essere riavviato.

Hai trovato questo articolo utile?
Per offrirti una migliore esperienza di navigazione online questo sito web usa dei cookie, propri e di terze parti. Continuando a navigare sul sito acconsenti all’utilizzo dei cookie. Scopri di più sull’uso dei cookie e sulla possibilità di modificarne le impostazioni o negare il consenso.