Sotto stretta sicurezza

In questo blog si è parlato in abbondanza di HTTPS e a piena ragione: la sicurezza dei nostri dati è una cosa importante che non va presa alla leggera.
Non ci stancheremo di ripetere che la privacy è un diritto di tutti e, di conseguenza, è un dovere della comunità IT fare tutto il possibile per renderla tecnicamente fattibile.

Il protocollo HTTPS è un passo in questa direzione: Google non è stata la prima a impegnarsi in questo senso, ma il suo peso specifico nel panorama tecnologico fa sì che ogni suo movimento sia il più rilevante, nonché quello che riceve la più ampia risonanza.
Questo post sul loro blog di sicurezza ha fatto notizia ed è una delle dichiarazioni giustamente più citate.
In particolare, mi piace focalizzare l’attenzione sulla immagine che mi sembra la più rappresentativa: un giorno tutte le pagine HTTP saranno trattate come Not secure. Ovvero, non sarà più HTTPS a essere una sicurezza in più, ma HTTP a esserne una in meno!

In questo ambito, ognuno di noi ha la possibilità di fare qualcosa: in primo luogo, in qualità di esperti di tecnologia, diffondere l’informazione sull’importanza della crittografia.
In seconda battuta, fare le cose bene a casa nostra, come suggerisce, di nuovo, Google anche in un altro post.
Non parlo naturalmente di questo blog, che è in HTTPS da tempo, ma piuttosto dei siti – personali o meno – di ognuno di noi.
L’azienda che ospita i siti che gestisco, offre da alcune settimane lo HTTPS anche per tutti i clienti con piani in hosting, e io di conseguenza mi sono dedicato a capire un po’ meglio come utilizzare HTTPS per un sito che non mantengo in casa mia.
In questo post condivido la mia esperienza.

La prima domanda: ora che ho HTTPS, come faccio a usarlo?
Mi aspetto veramente che tutti i miei vistatori si mettano a digitare h-t-t-p-s-duepunti… ?
Naturalmente no: è compito nostro rendere facile la vita all’utente.

Per fare in modo che una richiesta fatta in HTTP venga automaticamente tramutata in HTTPS si può agire facilmente sulla configurazione del proprio webserver.

Per quanto riguarda Apache, ammettendo di non poter accedere al file di configurazione, si può agire sul file .htaccess nella root del sito (e eventualmente di sue ulteriori copie nelle sottocartelle) aggiungendo questo codice

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Con queste direttive, Apache prenderà le richieste al nostro sito fatte in HTTP e le tramuterà in HTTPS in maniera trasparente all’utente.
Vale la pena ripetere che, dato che il file .htaccess ha sempre la priorità, una sua copia all’interno di una sottodirectory deve contenere lo stesso codice.
Esempio pratico: se nel vostro sito avete una installazione di WordPress nella classicissima cartella /blog, allora dovrete modificare anche il file file .htaccess di WordPress nello stesso modo.

Sì può fare una cosa simile con IIS, nel file web.config della vostra applicazione.
In questo caso bisognerà aggiungere questo frammento di XML:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      …
   </system.web>
   <system.webServer>
      …
      <rewrite>
         <rules>
            <rule name="HTTP to HTTPS redirect" stopProcessing="true" patternSyntax="ECMAScript">
               <match url="^(.(?!localhost))*$" />
               <conditions>
                  <add input="{HTTPS}" pattern="off" ignoreCase="true" />
               </conditions>
               <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
            </rule>
         </rules>
         <outboundRules>
            <rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
               <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
               <conditions>
                  <add input="{HTTPS}" pattern="on" ignoreCase="true" />
               </conditions>
               <action type="Rewrite" value="max-age=31536000" />
            </rule>
         </outboundRules>
      </rewrite>
   </system.webServer>
   …
</configuration>

All’interno di system.webserver abbiamo aggiunto delle regole di riscrittura degli URI per sostituire HTTP con HTTPS.
Il pattern "^(.(?!localhost))*$" che vedete nel match è una personalizzazione mia che mi serve per non effettuare la riscrittura quando faccio i test in locale.
Non è necessariamente qualcosa che debba servire ache a voi e la riga avrebbe potuto quindi essere <match url="(.*)" /> per coprire tutti gli URI.

I più attenti avranno notato che nella seconda parte del codice è implementata anche la HTTP Strict Transport Security: si tratta di una tecnologia che permette di indicare al browser di non smettere di usare HTTPS all’interno del sito. Evita che un link scritto male possa chiudere la sessione HTTPS, per esempio; inoltre aiuta a evitare il Protocol downgrade attack e il Session Hijacking .
Come vedete dall’immagine a fianco, viene inserito un nuovo header nella risposta al browser che indica di utilizzare HSTS.
La max-age- indica che richieste future a questo server (il numero indicato rappresenta un anno non bisestile in secondi) dovranno essere trattate sempre in HTTPS e non più in HTTP.
Attenzione: se smetteste di usare HTTPS sul vostro sito, un client che tornasse dopo aver già ricevuto questa direttiva, non riuscirebbe più ad accedere ai link, dato che cercherebbe sempre di accedervi tramite SSL.

La stessa tecnologia si può implementare il Apache, di nuovo nel file .htaccess con il codice

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>

Notate che lo header non è aggiunto sempre (non c’è la direttiva always) ma solo quando il trasporto è HTTPS: le specifiche di HSTS indicano chiaramente di aggiungere lo header solo in caso di HTTPS.

Alla fine di tutte le modifiche, potete rivedere il funzionamento del vostro sito con l’utile test che trovate qui https://www.ssllabs.com/ssltest/index.html .
Con questi piccoli accorgimenti è possibile aumentare la sicurezza dei nostri siti anche in hosting, senza necessariamente avere il controllo pieno dell’ambiente server su cui girano.

Autore: Luca Mauri

Prima di tutto un Geek e un Trekker, Luca Mauri lavora come IT Manager. Entusiasta della esplorazione spaziale e della scienza in generale. È un lettore vorace e un fotografo amatoriale. Fa parte della piccola schiera degli INTJ.

6 pensieri riguardo “Sotto stretta sicurezza”

    1. Rispettosamente non concordo. La privacy ma che bello, però qui si rischia di buttare via il bambino con l’acqua sporca e l’uso ubiquitario di TLS oltre che manicheo ha dei lati negativi.
      Uno su tutti, esistono organizzazioni che hanno IL DIRITTO/DOVERE di ficcare il naso nel traffico internet della propria utenza per sacrosante ragioni: sicurezza, congruo uso e ottimizzazione delle (scarse) risorse disponibili, esempio: le scuole.
      HTTPS impedisce o rende molto difficoltoso ispezionare il traffico e non è amico dei proxy (niente caching), a meno di non usare tecniche di interposizione MITM mutuate dall’hacking.

      Google ha un suo sporco interesse in tutto ciò? Da me interpellata in merito la risposta è stata: “lo sappiamo, provveda ad attivare i nostri strumenti di controllo, usi i nostri DNS, si abbandoni a noi e tutto sarà più bello.”

      Eggrazie al.

      1. Quando si introduce una maggior sicurezza o si cambia la tecnologia da qualche parte, qualcuno si lamenta sempre che in alcuni casi specifici potrebbe non essere più possibile effettuare controlli o intercettazioni; questa è una storia più vecchia del web.

        La limitazione e il tracciamento dell’attività su Internet si può fare a livello di siti con whitelist e blacklist senza ispezionare i contenuti, esistono servizi gratuiti che gestiscono questi elenchi e firewall gratuiti ((pfSense) che li implementano.

        Chiedere a Google di risolvere questo problema non serve perché non è il suo lavoro fare questo.

        1. il problema non è solo una whitelist-blacklist.
          Restando con pfsense, come ben sai, esso implementa sul proxy, anche un antivirus, in modo da controllare se quello che stà facendo transitare un utente, è effettivamente un file utile o malevolo.
          Purtroppo l’antivirus è efficace solo se ha accesso in chiaro a quello che stà scaricando.
          Certo, c’è la possibilità di fare appunto, come detto da qualcuno, una roba tipo man in the middle, pfsense stà già andando in quel senso, e soluzione proprietarie alla Cisco, già lo fanno da un pezzo, però tutta stà roba non fà altro che a complicare l’infrastruttura.
          Ora, non stò dicendo che la privacy non sia importante, e ci mancherebbe, ma mi pare che, decidere dalla sera alla mattina, che tutto si debba cifrare mi pare esagerato.

  1. una cosa importante che va ricordata è che tutto quello che viene chianato nella pagina poi deve essere chiamato via https.
    Quindi occhio a tutti i vari “” o “” che vanno cambiati in “” o “”, dopo esserci accertati che la fonte ovviamente funzioni anche in https.

Spazio per un commento