Rileva man-in-the-middle sul lato server per HTTPS

7

Background: abbiamo un sito che funziona su HTTPS (HTTP non supportato, usiamo HSTS). È distribuito in cloud di terze parti, che limita le nostre capacità di controllo e di registro sull'hardware del server. Non possiamo forzare l'utilizzo dell'autenticazione del certificato client. Quindi, in pratica, quello che abbiamo è un sito HTTPS pubblico con autenticazione standard a 2 fattori (login / passaggio + SMS), accessibile dal browser desktop o mobile, e API aggiuntiva sullo stesso sito all'interno di app mobili native. Il software del server è basato su .Net / IIS.

Stiamo prendendo in considerazione il seguente scenario: in qualche modo il computer / smartphone dell'utente ha fatto affidamento sul certificato dell'attaccante, consentendo così il classico attacco MiM (quindi l'utente è connesso al proxy con certificato attendibile e il proxy è connesso al nostro server). Uno degli scenari comuni (in alcuni paesi) per questo è che il provider Internet richiede che l'utente abbia fiducia nel proprio certificato autofirmato.

Lasciando da parte la sicurezza sul lato client (controlla l'identificazione del certificato ecc.) - esiste un modo per il server (ad es. per la nostra applicazione) per capire che l'attacco MiM è a posto?

Questa è una domanda come questa HTTPS - Can il server visualizza i dettagli del certificato lato client? , ma non cerco solo i modi per rilevare immediatamente tale attacco (il che sarebbe ovviamente buono se possibile), ma anche per i modi che possono aiutarci a rilevare tale attacco a lungo termine , con ad esempio alcuni record storici.

    
posta Lanorkin 14.01.2016 - 12:29
fonte

1 risposta

3

Un uomo perfetto e l'attacco centrale probabilmente non possono essere rilevati, ma solitamente questi attacchi (o intercettazioni SSL legali nei firewall) non sono perfetti. Suggerirei di dare un'occhiata a ClientHello, in particolare riguardo ai codici offerti dal cliente. Quali codici sono ordinati e in quale ordine è molto tipico per i browser di oggi. L'uomo nelle soluzioni centrali di solito non si preoccupa di replicare i cifrari esatti ma semplicemente usa il proprio set di cifratura. Altre caratteristiche sono la versione del protocollo o l'uso di estensioni specifiche come SNI o ALPN.

Si noti che probabilmente non si ottengono molte di queste funzionalità da un normale server, cioè di solito si ottiene principalmente il cifrario finale e la versione del protocollo. Per ottenere di più potrebbe essere necessario strumentare la libreria TLS o annusare il traffico e analizzarlo in seguito.

    
risposta data 14.01.2016 - 13:44
fonte

Leggi altre domande sui tag