Come funziona SSLstrip?

82

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

Un sacco di documentazione sembra indicare che sostituisce semplicemente le occorrenze di "https" con "http" nel traffico a cui ha accesso. Quindi un URL che passa come " link " verrebbe trasmesso alla vittima come " link ".

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

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

O è solo il fatto che ora il client sta 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 poiché viene applicato da Twitter, ma vorrei solo qualche chiarimento, grazie.

    
posta Scott Helme 07.09.2013 - 21:49
fonte

5 risposte

71

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

HSTS è una soluzione proposta a questo problema.

    
risposta data 07.09.2013 - 22:43
fonte
3

Parlando di possibili soluzioni: l'unico modo veramente affidabile per prevenire / rilevare lo stripping SSL è l'utilizzo di comunicazioni e ampli crittografati sempre; autenticazione del canale laterale del TLS (in pratica utilizzare lo scambio di chiavi TLS, ma sostituire l'autenticazione basata su PKI / certificato con l'autenticazione basata su utente o dispositivo). Ciò significa in pratica che dopo uno scambio di chiavi il server e l'utente finiscono con determinati segreti o chiavi condivise. Client e server quindi utilizzano un canale di autenticazione discreto (ad esempio utilizzando SSH o altri metodi di autenticazione asimmetrica strong) e autenticano sia le loro identità che le chiavi TLS. Se le chiavi sono le stesse, hai una certezza del 100% di canale cifrato end-to-end.

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

  1. MITM potrebbe terminare la comunicazione TLS con il server al suo punto e consentire all'utente di comunicare tramite HTTP. Ciò non causa avvisi in TLS / HSTS tradizionali. Tuttavia, questo verrà rilevato dall'autenticazione del canale laterale, poiché il server e il client hanno chiavi TLS diverse (chiave 1 e no chiave).

  2. MITM potrebbe utilizzare un certificato contraffatto o rubato. Questo potrebbe o non potrebbe innescare un avviso, a seconda del certificato utilizzato (potrebbe essere sempre più semplice grazie all'iniziativa Let's Encrypt). Questo attacco verrebbe nuovamente scoperto dal TLS autenticato dal canale laterale, poiché il server avrebbe una chiave diversa dal client (il server ha key1, MITM ha key1 per il server, MITM ha key2 per il client, client ha key2).

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

    
risposta data 09.10.2015 - 04:00
fonte
1

HSTS è una semplice "http header" che può essere manomessa e modificata da MITM

Preferoni addons come HTTPnowhere o HTTPS Everywhere, con il 90% di successi ... Un altro tipo di addon è link per crittografare i dati dopo la negoziazione di handshake SSL.

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

    
risposta data 15.09.2015 - 14:48
fonte
1

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 cliente dovrebbe prima richiedere il collegamento - quando il sito reindirizza il client alla striscia SSL HTTPS si spoglierà "s" nella risposta tale che il client continuerà a richiedere il contenuto HTTP, non HTTPS.

Se un cliente ha richiesto il link (o HSTS è in uso), sarebbe necessario un attacco MiTM SSL per intercettare la risposta, che sconfigge lo scopo di questo attacco.

    
risposta data 18.10.2017 - 07:23
fonte
0

Spero che questo risponda alla domanda

Passaggio 1: Vittima < == HTTP == > Attacker < == HTTPS == > Twitter

Passaggio 2: Twitter < == HTTPs == > Attacker ("Stipping" S "con SSL STRIP) == > HTTP == > Vittima

Passaggio 3: Ora il Victim riceverà link e continuerà con lo stesso che è testo normale e non crittografato.

    
risposta data 07.11.2017 - 16:49
fonte

Leggi altre domande sui tag