it-swarm-eu.dev

Come funziona SSLstrip?

Ho letto su SSLstrip e non sono sicuro al 100% della mia comprensione di come funziona.

Molta documentazione sembra indicare che sostituisce semplicemente le occorrenze di "https" con "http" nel traffico a cui ha accesso. Quindi un URL che passa come " https://Twitter.com " verrebbe passato alla vittima come " http://Twitter.com ".

A questo punto SSLstrip continua a comunicare con Twitter tramite HTTPS per nostro conto? Qualcosa come questo:

Victim  <== HTTP ==>  Attacker  <== HTTPS ==>  Twitter

O è solo il fatto che il client sta ora comunicando con Twitter su HTTP che ci dà accesso al traffico?

Victim  <== HTTP ==>  Attacker  <== HTTP ==>  Twitter

La mia ipotesi è che sarebbe la prima opzione in cui l'attaccante continua a comunicare con Twitter tramite HTTPS in quanto è applicato da Twitter, ma vorrei solo qualche chiarimento, grazie.

92
Scott Helme

Dovresti guardare il discorso di Moxie Marlinspike Sconfiggere SSL usando SSLStrip . In breve SSLStrip è un tipo di attacco MITM che obbliga il browser di una vittima a comunicare con un avversario in testo normale su HTTP e l'avversario inoltra il contenuto modificato da un server HTTPS. Per fare ciò, SSLStrip sta "spogliando" https:// URL e trasformandoli in http:// URL.

HSTS è una soluzione proposta a questo problema.

76
rook

Parlando di possibili soluzioni: L'unico modo veramente affidabile per prevenire/rilevare lo stripping SSL è utilizzare la comunicazione sempre crittografata e l'autenticazione del canale laterale del TLS (fondamentalmente utilizzare lo scambio di chiavi TLS, ma sostituire l'autenticazione basata su PKI/certificato con utente o dispositivo basato autenticazione). Ciò significa in pratica che dopo uno scambio di chiavi il server e l'utente finiscono con alcuni segreti o chiavi condivisi. Il client e il server utilizzano quindi un canale di autenticazione discreto (ad es. Utilizzando SSH o altri metodi di autenticazione asimmetrica avanzata) e autenticano sia le loro identità sia le chiavi TLS. Se le chiavi sono uguali, hai una certezza del 100% del canale crittografato end-to-end.

Se c'è un uomo nel mezzo, potrebbe fare 2 vettori di attacco:

  1. Al momento MITM potrebbe interrompere la comunicazione TLS con il server e consentire all'utente di comunicare tramite HTTP. Ciò non causa avvisi nel TLS/HSTS tradizionale. Tuttavia, questo verrà scoperto dall'autenticazione del canale laterale, poiché il server e il client hanno chiavi TLS diverse (chiave 1 e nessuna chiave).

  2. MITM potrebbe utilizzare un certificato contraffatto o rubato. Questo potrebbe o meno attivare un avviso, a seconda del certificato utilizzato (potrebbe essere sempre più facile grazie all'iniziativa Let's Encrypt). Questo attacco verrebbe nuovamente scoperto dal TLS autenticato sul canale laterale, perché il server avrebbe una chiave diversa rispetto al client (il server ha la chiave1, MITM ha la chiave1 al server, MITM ha la chiave2 al client, il client ha la chiave2).

Questo uccide i certificati SSL come bonus e funzionerebbe anche con i CDN Si noti che questa soluzione non è immune alle backdoor alla crittografia.

3
Ivo

Penso che sia importante notare che lo stripping viene eseguito sui payload dal client al server e richiede che il client richieda prima il contenuto HTTP.

Utilizzando l'esempio di Twitter, il client dovrebbe prima richiedere http://www.Twitter.com - quando il sito reindirizza il client su HTTPS SSL Strip rimuoverà la "s" nella risposta in modo tale che il client continuerà a richiedere contenuto HTTP, non HTTPS.

Se un client richiede https://www.Twitter.com (o è in uso HSTS), sarebbe necessario un attacco MiTM SSL per intercettare la risposta, il che vanifica lo scopo di questo attacco.

1
Matt

HSTS è una semplice "intestazione http" che può essere manomessa e modificata dal MITM

Preferisci addon come HTTPnowhere o HTTPS Everywhere, con il 90% di successo ... Un altro tipo di addon è https://addons.mozilla.org/en-US/firefox/addon/enable-disable-weak-ssl -cip / per crittografare i dati dopo la negoziazione dell'handshake SSL.

Ovvio come cliente, sei in una posizione INFERIORE e i router tra te e Internet sono controllati facilmente. Quindi, comprendi che i clienti hanno scarse risorse per controllare il traffico ... e per questo solo la soluzione migliore è VPN/Stunnel .. ma non sa mai se le persone NSA/ISP/prevenute hanno il segreto magico per intercettare e decrittografare quella comunicazione ..

1
Mário Guedes