Il pro­to­col­lo di tra­sfe­ri­men­to Secure Sockets Layer (SSL) e il suo suc­ces­so­re Transport Layer Security (TLS) rientrano tra i com­po­nen­ti più im­por­tan­ti che servono per as­si­cu­ra­re la na­vi­ga­zio­ne su un sito sicuro. Questi pro­to­col­li cifrano i dati che il browser e il server si scambiano tramite HTTP, ancora prima che questi vengano inviati, anche nel caso in cui lo scambio avvenga tra una pagina HTTPS crit­to­gra­fa­ta e una non protetta. In questo modo non solo il tra­sfe­ri­men­to di dati classico è osta­co­la­to nel testo in chiaro, ma viene anche impedito che un cookie impostato in una con­nes­sio­ne SSL venga inviato in una con­nes­sio­ne non crit­to­gra­fa­ta.

Inoltre questi utili cer­ti­fi­ca­ti ga­ran­ti­sco­no al client ri­chie­den­te l’au­ten­ti­ci­tà del nome host del server. Il pro­to­col­lo TLS offre quindi sicurezza sotto molti punti di vista, cosa che ne rende in­di­spen­sa­bi­le il suo utilizzo in tutti quei casi in cui devono essere trasmessi dei dati sensibili.

Ge­ne­ral­men­te TLS è uno dei pro­to­col­li più sicuri e si è di­mo­stra­to efficace contro i tentativi di attacchi hacker. In presenza di con­di­zio­ni definite, dei tool specifici (come ad esempio SSL Strip, pro­gram­ma­to per scopi il­lu­stra­ti­vi) sono però in grado di ottenere l’accesso alla tra­smis­sio­ne dati prima che inizi il processo di crit­to­gra­fia. Gli accessi non au­to­riz­za­ti di questo tipo sono chiamati SSL Strip.

Cer­ti­fi­ca­to SSL
Proteggi il tuo sito con un cer­ti­fi­ca­to SSL

Evita che venga vi­sua­liz­za­ta un'al­ler­ta nella barra degli indirizzi e ottieni la fiducia dei clienti con un sito crit­to­gra­fa­to tramite SSL.

Che cos’è l’SSL Strip?

Già nel 2002 lo svi­lup­pa­to­re Moxie Mar­lin­spi­ke ha pro­gram­ma­to un tool con sslsniff che avrebbe potuto impedire la crit­to­gra­fia SSL. Il software proxy ha con­sen­ti­to di in­fil­trar­si nei flussi di dati SSL e di scambiare il cer­ti­fi­ca­to del server con uno a scelta. Con la sua ap­pli­ca­zio­ne Mar­lin­spi­ke voleva ri­chia­ma­re so­prat­tut­to l’at­ten­zio­ne su una vul­ne­ra­bi­li­tà di Internet Explorer, che al momento del rilascio di sslsniff risultava soggetto ad attacchi di tipo Man in the Middle.  Microsoft è riuscita a chiudere la falla di sicurezza e anche gli altri client am­pia­men­te uti­liz­za­ti sono oggi nella versione attuale e con la giusta con­fi­gu­ra­zio­ne ben equi­pag­gia­ti contro attacchi di questo tipo.

Mar­lin­spi­ke ha pre­sen­ta­to il già men­zio­na­to programma sslstrip nel 2009 nell’ambito della con­fe­ren­za di sicurezza Black Hat DC. Così come il suo tool pre­ce­den­te, anche sslstrip è un proxy che si posiziona tra client e server e tenta di aggirare la cer­ti­fi­ca­zio­ne lato client. A questo scopo il tool analizza le pagine web con­se­gna­te dai web server alla ricerca mirata di link e inoltri che rimandano a una pagina di login protetta con SSL, come ad esempio è il caso del seguente link:

<a href="https://example.com/login.php">

Se il proxy trova un simile link, questo viene tra­sfor­ma­to in un link HTTP equi­va­len­te, così che l’utente al momento del login invii un testo in chiaro al posto dei supposti dati crit­to­gra­fa­ti. Il po­ten­zia­le hacker può leggere senza problemi la co­mu­ni­ca­zio­ne grazie a sslstrip, che ricopre il ruolo di stazione in­ter­me­dia, e giungere così a in­for­ma­zio­ni riservate. So­li­ta­men­te l’utente non si accorge neanche che sta tra­smet­ten­do i propri dati in maniera non protetta, poiché, visto che SSL Strip non genera alcuna con­nes­sio­ne non valida, all’utente non compare alcun messaggio di avviso.

Come viene im­ple­men­ta­to SSL Strip?

Non importa se viene uti­liz­za­to sslstrip o un’ap­pli­ca­zio­ne pro­gram­ma­ta in modo simile: prima di tutto è ne­ces­sa­rio che l’hacker attivi il suo proxy tra browser e web server. Il software potrà infatti inserire degli URL mo­di­fi­ca­ti tramite SSL Strip solamente nel caso in cui sia riuscito a in­ter­cet­ta­re e/o inoltrare flussi di dati. Per l’im­ple­men­ta­zio­ne sono so­prat­tut­to diffusi i seguenti tre metodi:

  1. In­se­ri­men­to del proxy di nascosto nelle opzioni del browser: se il vostro sistema finisce nel mirino dei cy­ber­cri­mi­na­li, spesso non è tutto il computer ad essere l’obiettivo dell’attacco, ma solo il browser. Un malware si occupa poi di inserire au­to­ma­ti­ca­men­te nelle im­po­sta­zio­ni un server proxy, senza che l’utente se ne accorga.

  2. ARP spoofing o NDP spoofing: all’interno di una sottorete un hacker può ricorrere al co­sid­det­to ARP spoofing (per IPv4) o all’NDP spoofing (per IPv6) per far entrare in gioco il suo proxy. Entrambi i pro­to­col­li sod­di­sfa­no lo scopo di risolvere gli indirizzi IP nei cor­ri­spon­den­ti indirizzi hardware (anche co­no­sciu­ti come indirizzi MAC). Grazie ai messaggi ma­ni­po­la­ti di questi pro­to­col­li l’hacker può so­sti­tui­re gli indirizzi hardware richiesti tramite il proprio sistema e in­ter­cet­ta­re infine i pacchetti trasmessi.

  3. Mettere a di­spo­si­zio­ne un proprio hotspot: la terza pos­si­bi­li­tà prevede che il di­spo­si­ti­vo sul quale si basa il server proxy possa fungere anche da router. Come standard gateway com­pren­si­vo di server DHCP può ad esempio assegnare degli indirizzi IP agli utenti, ma anche leggere e inoltrare i pacchetti che vengono inviati oltre i limiti della sottorete creata. Così esiste anche con­tem­po­ra­nea­men­te la base perfetta per l’SSL Strip.

Dopo che l’hacker ha portato in posizione il suo proxy, in teoria non deve fare più molto per l’SSL Strip: basta che faccia fun­zio­na­re il tool, che nelle giuste si­tua­zio­ni farà vi­sua­liz­za­re link mo­di­fi­ca­ti e in caso di successo consegna in­for­ma­zio­ni non crit­to­gra­fa­te, come ad esempio i dati di login o quelli bancari dell’utente.

L’utente può ri­co­no­sce­re l’SSL Strip?

Il server e il browser non hanno nessuna pos­si­bi­li­tà di ri­co­no­sce­re l’SSL Strip. Entrambe le ap­pli­ca­zio­ni partono dal pre­sup­po­sto di co­mu­ni­ca­re con il partner con­tat­ta­to vero e proprio, perciò non mettono in di­scus­sio­ne l’integrità dei dati trasmessi. Per gli utenti la si­tua­zio­ne è molto simile, perché di primo acchito la visita al sito sembra procedere come sempre. Le pagine ma­ni­po­la­te da SSL Strip sono infatti ri­co­no­sci­bi­li solo in alcuni casi ec­ce­zio­na­li sulla base di dettagli tecnici o del loro design. Quindi se non viene pre­sen­ta­to un layout errato o non compaiono so­stan­zia­li ritardi nel ca­ri­ca­men­to della pagina, le in­di­ca­zio­ni per sapere se sta avvenendo una crit­to­gra­fia SSL o meno sono estre­ma­men­te minime.

Le barre degli indirizzi del browser for­ni­sco­no però da un po’ di tempo alcune in­di­ca­zio­ni, in parte in modi molto diversi: per segnalare le pagine web con una con­nes­sio­ne sicura, la barra degli indirizzi nelle pre­ce­den­ti versioni di Internet Explorer di Microsoft era ad esempio colorata di verde. Altri browser evi­den­zia­va­no sem­pli­ce­men­te il nome dell’azienda con un altro colore, fino a quando a questo tipo di segno di­stin­ti­vo, con la dif­fu­sio­ne dei di­spo­si­ti­vi mobili capaci di navigare su Internet, sono succeduti og­gi­gior­no i simboli comuni come il tipico lucchetto di sicurezza.

Ma anche queste in­di­ca­zio­ni ottiche non ga­ran­ti­sco­no sempre che la pagina visitata non sia stata ma­ni­po­la­ta da tool come sslstrip. Visto che un hacker controlla il traffico dati completo, è in grado nel frattempo di ri­pro­dur­re un simile simbolo come favicon, per rendere perfetto il suo inganno.

Quali pos­si­bi­li­tà di pro­te­zio­ne ci sono?

La dif­fi­col­tà di ri­co­no­sce­re le pagine ma­ni­po­la­te rende gli attacchi di SSL Strip molto pe­ri­co­lo­si per gli utenti: i cer­ti­fi­ca­ti di crit­to­gra­fia che do­vreb­be­ro essere uti­liz­za­ti da ogni gestore di siti con­sa­pe­vo­le dei suoi obblighi sono un simbolo di sicurezza e af­fi­da­bi­li­tà e tolgono perciò i dubbi ai vi­si­ta­to­ri di stare rivelando i loro dati riservati. Prin­ci­pal­men­te l’SSL offre anche la pro­te­zio­ne ne­ces­sa­ria, perché infatti la pos­si­bi­li­tà di leggere e in­ter­cet­ta­re i pacchetti non risulta da una falla di sicurezza del pro­to­col­lo, ma dal fatto che la crit­to­gra­fia in sé viene impedita. Per pro­teg­ger­si dall’SSL Strip, ogni utente dovrebbe perciò forzare la struttura delle con­nes­sio­ni crit­to­gra­fa­te HTTPS, ad esempio ri­cor­ren­do ai seguenti mezzi:

  1. In­se­ri­men­to manuale dell’URL: una misura estre­ma­men­te faticosa ma di successo è quella di inserire un URL HTTPS completo ma­nual­men­te.

  2. Esten­sio­ne per il browser: ci sono diverse esten­sio­ni per il browser che vi aiutano a ri­chia­ma­re versioni crit­to­gra­fa­te, a patto che siano di­spo­ni­bi­li. L’esten­sio­ne HTTPS Eve­ry­whe­re ricorre ad esempio alle liste di dominio e alle regole per ri­chia­ma­re le pagine tramite con­nes­sio­ni HTTPS. Trovate delle versioni per Firefox, Firefox for Android, Chrome e Opera sul sito dell’Elec­tro­nic Frontier Foun­da­tion, che sviluppa e cura l’esten­sio­ne insieme al progetto Tor.

  3. Salvare URL sicuri come se­gna­li­bro: se uti­liz­za­te fre­quen­te­men­te un servizio web protetto da SSL (online banking, ar­chi­via­zio­ne cloud, ecc.), potete salvare la versione HTTPS come se­gna­li­bro e ri­chia­ma­re il servizio sempre in questo modo. Il pre­re­qui­si­to è che vi troviate in una rete sicura nel momento in cui im­po­stia­te un se­gna­li­bro. Al­tri­men­ti è possibile che inseriate tra la lista dei preferiti un URL già ma­ni­po­la­to.

Anche come gestore di un progetto web si può lottare at­ti­va­men­te contro l’SSL Strip. Un passaggio basilare può ad esempio essere quello di attivare la crit­to­gra­fia per tutte le pagine del sito e di forzare il rein­di­riz­za­men­to delle con­nes­sio­ni HTTP in entrata sulle pagine sicure. Lo stesso vale per i cookie impostati: se non volete ri­nun­cia­re a pratici set di dati ai fini dell’analisi web, dovreste as­si­cu­rar­vi che questi non vengano rinviati tramite con­nes­sio­ni non sicure. Perciò con­tras­se­gna­te i cookie con l’attributo “Secure” e as­si­cu­ra­te­vi così che il vostro server riceva solamente risposte tramite HTTPS. Un’altra misura di sicurezza è lo standard dell’IETF HSTS sul quale si fa luce nel paragrafo suc­ces­si­vo.

In che modo l’HSTS aiuta contro l’SSL Strip?

Tre anni dopo che Mar­lin­spi­ke ha ri­chia­ma­to l’at­ten­zio­ne con il suo software sslstrip sulla vul­ne­ra­bi­li­tà dei siti cer­ti­fi­ca­ti tramite SSL, l’IETF (Internet En­gi­nee­ring Task Force) ha spe­ci­fi­ca­to nell’ RFC 6797 il mec­ca­ni­smo di sicurezza HSTS (HTTP Strict Transport Security). Ciò consente ai web server di co­mu­ni­ca­re ai client che in­stau­ra­no una con­nes­sio­ne che, per un dato periodo di tempo, è possibile rag­giun­ge­re il sito esclu­si­va­men­te tramite una con­nes­sio­ne HTTPS.

A questo scopo il server utilizza nell’header di una classica risposta HTTP il campo “Strict-Transport-Security“ più la direttiva “max-age”, con la quale viene stabilita la validità della direttiva in secondi. Per rendere rag­giun­gi­bi­le un dominio per un anno esclu­si­va­men­te tramite con­nes­sio­ne crit­to­gra­fa­ta, la risposta HTTP del web server deve ad esempio com­pren­de­re la seguente riga:

Strict-Transport-Security: max-age=31536000

Inoltre tramite il parametro “in­clu­de­Sub­Do­mains“ si può estendere il comando a tutti i sot­to­do­mi­ni del sito web, così che anche qui venga forzato l’utilizzo di SSL/TLS. Se un browser riceve dal web server con­tat­ta­to un messaggio con la direttiva “Strict-Transport-Security“, nelle con­nes­sio­ni future sul dominio coinvolto vengono au­to­ma­ti­ca­men­te con­ver­ti­te tutte le richieste non crit­to­gra­fa­te in crit­to­gra­fa­te. Se la sicurezza della con­nes­sio­ne non si può garantire, compare un messaggio di errore e la pagina richiesta non viene aperta. HSTS rap­pre­sen­ta una soluzione per­ma­nen­te per pro­teg­ge­re un sito web e i po­ten­zia­li vi­si­ta­to­ri da SSL Strip e da attacchi com­pa­ra­bi­li. Prima che possa entrare in azione il mec­ca­ni­smo di sicurezza, viene però previsto sempre un pri­mis­si­mo tentativo di con­nes­sio­ne, che è ugual­men­te ma­ni­po­la­bi­le, come è già stato descritto in questo articolo. Per fron­teg­gia­re questo problema, Google ha in­tro­dot­to per il suo browser Chrome una lista preload, che comprende quei progetti web apribili esclu­si­va­men­te tramite HTTPS. Altri pro­dut­to­ri di browser hanno adottato questo sistema e im­ple­men­ta­to ugual­men­te liste preload di HSTS che si basano sulla lista di Chrome. Per inserire il vostro sito web nella lista, potete fare domanda sulla pagina del progetto, creata da Google per questo scopo.

Fatto

Per essere inseriti nella lista preload devono essere sod­di­sfat­ti dei precisi requisiti: è lo­gi­ca­men­te ne­ces­sa­rio essere in grado di pre­sen­ta­re un cer­ti­fi­ca­to valido e far fun­zio­na­re tramite HTTPS anche tutti i sot­to­do­mi­ni. Inoltre il campo HSTS deve essere pro­get­ta­to nelle risposte del web server sul dominio prin­ci­pa­le:

  • La direttiva “max-age” deve avere almeno una validità di 18 settimane (10886400 secondi).
  • La direttiva “in­clu­de­Sub­Do­mains“ deve essere spe­ci­fi­ca­ta.
  • In più deve essere impostata la direttiva “preload”.
  • Se esiste un inoltro, deve contenere anche l’header HSTS.
Vai al menu prin­ci­pa­le