SSL Strip: nozioni di base e possibilità di protezione
Il protocollo di trasferimento Secure Sockets Layer (SSL) e il suo successore Transport Layer Security (TLS) rientrano tra i componenti più importanti che servono per assicurare la navigazione su un sito sicuro. Questi protocolli 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 crittografata e una non protetta. In questo modo non solo il trasferimento di dati classico è ostacolato nel testo in chiaro, ma viene anche impedito che un cookie impostato in una connessione SSL venga inviato in una connessione non crittografata.
Inoltre questi utili certificati garantiscono al client richiedente l’autenticità del nome host del server. Il protocollo TLS offre quindi sicurezza sotto molti punti di vista, cosa che ne rende indispensabile il suo utilizzo in tutti quei casi in cui devono essere trasmessi dei dati sensibili.
Generalmente TLS è uno dei protocolli più sicuri e si è dimostrato efficace contro i tentativi di attacchi hacker. In presenza di condizioni definite, dei tool specifici (come ad esempio SSL Strip, programmato per scopi illustrativi) sono però in grado di ottenere l’accesso alla trasmissione dati prima che inizi il processo di crittografia. Gli accessi non autorizzati di questo tipo sono chiamati SSL Strip.
Evita che venga visualizzata un'allerta nella barra degli indirizzi e ottieni la fiducia dei clienti con un sito crittografato tramite SSL.
![](https://www.ionos.it/digitalguide/fileadmin/DigitalGuide/IAS/CTAs/SEO_Digital_Guide_Mobile_nur-Nlement_900x750.png)
Che cos’è l’SSL Strip?
Già nel 2002 lo sviluppatore Moxie Marlinspike ha programmato un tool con sslsniff che avrebbe potuto impedire la crittografia SSL. Il software proxy ha consentito di infiltrarsi nei flussi di dati SSL e di scambiare il certificato del server con uno a scelta. Con la sua applicazione Marlinspike voleva richiamare soprattutto l’attenzione su una vulnerabilità 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 ampiamente utilizzati sono oggi nella versione attuale e con la giusta configurazione ben equipaggiati contro attacchi di questo tipo.
Marlinspike ha presentato il già menzionato programma sslstrip nel 2009 nell’ambito della conferenza di sicurezza Black Hat DC. Così come il suo tool precedente, anche sslstrip è un proxy che si posiziona tra client e server e tenta di aggirare la certificazione lato client. A questo scopo il tool analizza le pagine web consegnate 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 trasformato in un link HTTP equivalente, così che l’utente al momento del login invii un testo in chiaro al posto dei supposti dati crittografati. Il potenziale hacker può leggere senza problemi la comunicazione grazie a sslstrip, che ricopre il ruolo di stazione intermedia, e giungere così a informazioni riservate. Solitamente l’utente non si accorge neanche che sta trasmettendo i propri dati in maniera non protetta, poiché, visto che SSL Strip non genera alcuna connessione non valida, all’utente non compare alcun messaggio di avviso.
Come viene implementato SSL Strip?
Non importa se viene utilizzato sslstrip o un’applicazione programmata in modo simile: prima di tutto è necessario che l’hacker attivi il suo proxy tra browser e web server. Il software potrà infatti inserire degli URL modificati tramite SSL Strip solamente nel caso in cui sia riuscito a intercettare e/o inoltrare flussi di dati. Per l’implementazione sono soprattutto diffusi i seguenti tre metodi:
- Inserimento del proxy di nascosto nelle opzioni del browser: se il vostro sistema finisce nel mirino dei cybercriminali, spesso non è tutto il computer ad essere l’obiettivo dell’attacco, ma solo il browser. Un malware si occupa poi di inserire automaticamente nelle impostazioni un server proxy, senza che l’utente se ne accorga.
- ARP spoofing o NDP spoofing: all’interno di una sottorete un hacker può ricorrere al cosiddetto ARP spoofing (per IPv4) o all’NDP spoofing (per IPv6) per far entrare in gioco il suo proxy. Entrambi i protocolli soddisfano lo scopo di risolvere gli indirizzi IP nei corrispondenti indirizzi hardware (anche conosciuti come indirizzi MAC). Grazie ai messaggi manipolati di questi protocolli l’hacker può sostituire gli indirizzi hardware richiesti tramite il proprio sistema e intercettare infine i pacchetti trasmessi.
- Mettere a disposizione un proprio hotspot: la terza possibilità prevede che il dispositivo sul quale si basa il server proxy possa fungere anche da router. Come standard gateway comprensivo 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 contemporaneamente 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 funzionare il tool, che nelle giuste situazioni farà visualizzare link modificati e in caso di successo consegna informazioni non crittografate, come ad esempio i dati di login o quelli bancari dell’utente.
L’utente può riconoscere l’SSL Strip?
Il server e il browser non hanno nessuna possibilità di riconoscere l’SSL Strip. Entrambe le applicazioni partono dal presupposto di comunicare con il partner contattato vero e proprio, perciò non mettono in discussione l’integrità dei dati trasmessi. Per gli utenti la situazione è molto simile, perché di primo acchito la visita al sito sembra procedere come sempre. Le pagine manipolate da SSL Strip sono infatti riconoscibili solo in alcuni casi eccezionali sulla base di dettagli tecnici o del loro design. Quindi se non viene presentato un layout errato o non compaiono sostanziali ritardi nel caricamento della pagina, le indicazioni per sapere se sta avvenendo una crittografia SSL o meno sono estremamente minime.
Le barre degli indirizzi del browser forniscono però da un po’ di tempo alcune indicazioni, in parte in modi molto diversi: per segnalare le pagine web con una connessione sicura, la barra degli indirizzi nelle precedenti versioni di Internet Explorer di Microsoft era ad esempio colorata di verde. Altri browser evidenziavano semplicemente il nome dell’azienda con un altro colore, fino a quando a questo tipo di segno distintivo, con la diffusione dei dispositivi mobili capaci di navigare su Internet, sono succeduti oggigiorno i simboli comuni come il tipico lucchetto di sicurezza.
Ma anche queste indicazioni ottiche non garantiscono sempre che la pagina visitata non sia stata manipolata da tool come sslstrip. Visto che un hacker controlla il traffico dati completo, è in grado nel frattempo di riprodurre un simile simbolo come favicon, per rendere perfetto il suo inganno.
Quali possibilità di protezione ci sono?
La difficoltà di riconoscere le pagine manipolate rende gli attacchi di SSL Strip molto pericolosi per gli utenti: i certificati di crittografia che dovrebbero essere utilizzati da ogni gestore di siti consapevole dei suoi obblighi sono un simbolo di sicurezza e affidabilità e tolgono perciò i dubbi ai visitatori di stare rivelando i loro dati riservati. Principalmente l’SSL offre anche la protezione necessaria, perché infatti la possibilità di leggere e intercettare i pacchetti non risulta da una falla di sicurezza del protocollo, ma dal fatto che la crittografia in sé viene impedita. Per proteggersi dall’SSL Strip, ogni utente dovrebbe perciò forzare la struttura delle connessioni crittografate HTTPS, ad esempio ricorrendo ai seguenti mezzi:
- Inserimento manuale dell’URL: una misura estremamente faticosa ma di successo è quella di inserire un URL HTTPS completo manualmente.
- Estensione per il browser: ci sono diverse estensioni per il browser che vi aiutano a richiamare versioni crittografate, a patto che siano disponibili. L’estensione HTTPS Everywhere ricorre ad esempio alle liste di dominio e alle regole per richiamare le pagine tramite connessioni HTTPS. Trovate delle versioni per Firefox, Firefox for Android, Chrome e Opera sul sito dell’Electronic Frontier Foundation, che sviluppa e cura l’estensione insieme al progetto Tor.
- Salvare URL sicuri come segnalibro: se utilizzate frequentemente un servizio web protetto da SSL (online banking, archiviazione cloud, ecc.), potete salvare la versione HTTPS come segnalibro e richiamare il servizio sempre in questo modo. Il prerequisito è che vi troviate in una rete sicura nel momento in cui impostiate un segnalibro. Altrimenti è possibile che inseriate tra la lista dei preferiti un URL già manipolato.
Anche come gestore di un progetto web si può lottare attivamente contro l’SSL Strip. Un passaggio basilare può ad esempio essere quello di attivare la crittografia per tutte le pagine del sito e di forzare il reindirizzamento delle connessioni HTTP in entrata sulle pagine sicure. Lo stesso vale per i cookie impostati: se non volete rinunciare a pratici set di dati ai fini dell’analisi web, dovreste assicurarvi che questi non vengano rinviati tramite connessioni non sicure. Perciò contrassegnate i cookie con l’attributo “Secure” e assicuratevi 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 successivo.
In che modo l’HSTS aiuta contro l’SSL Strip?
Tre anni dopo che Marlinspike ha richiamato l’attenzione con il suo software sslstrip sulla vulnerabilità dei siti certificati tramite SSL, l’IETF (Internet Engineering Task Force) ha specificato nell’ RFC 6797 il meccanismo di sicurezza HSTS (HTTP Strict Transport Security). Ciò consente ai web server di comunicare ai client che instaurano una connessione che, per un dato periodo di tempo, è possibile raggiungere il sito esclusivamente tramite una connessione 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 raggiungibile un dominio per un anno esclusivamente tramite connessione crittografata, la risposta HTTP del web server deve ad esempio comprendere la seguente riga:
Strict-Transport-Security: max-age=31536000
Inoltre tramite il parametro “includeSubDomains“ si può estendere il comando a tutti i sottodomini del sito web, così che anche qui venga forzato l’utilizzo di SSL/TLS. Se un browser riceve dal web server contattato un messaggio con la direttiva “Strict-Transport-Security“, nelle connessioni future sul dominio coinvolto vengono automaticamente convertite tutte le richieste non crittografate in crittografate. Se la sicurezza della connessione non si può garantire, compare un messaggio di errore e la pagina richiesta non viene aperta. HSTS rappresenta una soluzione permanente per proteggere un sito web e i potenziali visitatori da SSL Strip e da attacchi comparabili. Prima che possa entrare in azione il meccanismo di sicurezza, viene però previsto sempre un primissimo tentativo di connessione, che è ugualmente manipolabile, come è già stato descritto in questo articolo. Per fronteggiare questo problema, Google ha introdotto per il suo browser Chrome una lista preload, che comprende quei progetti web apribili esclusivamente tramite HTTPS. Altri produttori di browser hanno adottato questo sistema e implementato ugualmente 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.
Per essere inseriti nella lista preload devono essere soddisfatti dei precisi requisiti: è logicamente necessario essere in grado di presentare un certificato valido e far funzionare tramite HTTPS anche tutti i sottodomini. Inoltre il campo HSTS deve essere progettato nelle risposte del web server sul dominio principale:
- La direttiva “max-age” deve avere almeno una validità di 18 settimane (10886400 secondi).
- La direttiva “includeSubDomains“ deve essere specificata.
- In più deve essere impostata la direttiva “preload”.
- Se esiste un inoltro, deve contenere anche l’header HSTS.