Qual è il punto di SSL se Fiddler 2 può decifrare tutte le chiamate su HTTPS?

Question

Ho fatto una domanda qui un po 'indietro su come nascondere le mie chiamate di richieste http e renderle più sicure nella mia applicazione. Non volevo che la gente usasse il violinista 2 per vedere la chiamata e impostare un risponditore automatico. Tutti mi hanno detto di andare su SSL e le chiamate saranno nascoste e le informazioni saranno mantenute al sicuro.

Ho acquistato e installato un certificato SSL e ho impostato tutto. Ho avviato il fiddler 2 e ho eseguito un'applicazione di test che si collega a un servizio Web https e che è connessa a uno script https php.

Fiddler 2 è stato in grado non solo di rilevare entrambe le richieste, ma anche di decrittografarle! Sono stato in grado di vedere tutte le informazioni che tornano indietro e la quarta, che mi porta alla mia domanda.

Qual è il punto di avere SSL se ha fatto zero differenza di sicurezza. Con o senza SSL, posso vedere tutte le informazioni tornare indietro e la quarta e STILL impostare un risponditore automatico.

C'è qualcosa in .NET che mi manca per nascondere meglio le mie chiamate su SSL?

EDIT

Io sono l'aggiunta di una nuova parte a questa domanda a causa di alcune delle risposte che ho ricevuto. Cosa succede se un'app si connette a un servizio Web per accedere. L'app invia al servizio web un nome utente e una password. Il servizio Web invia quindi i dati all'app dicendo che i dati di accesso sono buoni o cattivi. Anche se si passa attraverso SSL, la persona che usa il fiddler 2 potrebbe semplicemente impostare un risponditore automatico e l'applicazione viene quindi "incrinata". Capisco come potrebbe essere utile vedere i dati nel debug, ma la mia domanda è esattamente cosa si dovrebbe fare per assicurarsi che SSL si stia connettendo a quello che stava richiedendo. Fondamentalmente dicendo che non può esserci un uomo di mezzo.

Answer 1

Questa è coperto qui: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp

Fiddler2 si basa su un "man-in-the-middle" approccio alla HTTPS intercettazioni. Al tuo browser web, Fiddler2 afferma di essere il server web sicuro, e al server web, Fiddler2 imita il browser web. Per fingere di essere il web server, Fiddler2 genera dinamicamente un certificato HTTPS.

In sostanza vi fidate manualmente qualsiasi certificato di Fiddler fornisce, lo stesso sarà vero se si accetta manualmente certificato da persona a caso che non corrisponde nome di dominio.

EDIT: Ci sono modi per prevenire Fiddler/man-in-the-middle - vale a dire in applicazione personalizzata utilizzando SSL può richiedere i certificati particolari da utilizzare per la comunicazione. In caso di browser hanno l'interfaccia utente per informare l'utente della mancata corrispondenza del certificato, ma alla fine consentono tale comunicazione.

Come esempio pubblicamente disponibile per i certificati espliciti, è possibile provare a utilizzare i servizi di Azure (ad esempio con gli strumenti PowerShell per Azure) e sniffare il traffico con Fiddler. Fallisce a causa del requisito di cert esplicito.

Answer 2

È possibile configurare il proprio servizio Web per richiedere una certificazione lato client per l'autenticazione SSL, nonché lato server. In questo modo, Fiddler non sarebbe in grado di connettersi al tuo servizio. Solo la tua applicazione, che ha il certificato richiesto, sarebbe in grado di connettersi.

Ovviamente, hai il problema di come proteggere il certificato all'interno dell'app, ma ora hai il problema con il tuo nome utente & password. Qualcuno che vuole veramente decifrare la tua app può cimentarsi con Reflector, o addirittura eseguire una ricerca della memoria per la chiave privata associata al certificato del cliente.

Non c'è un modo reale per rendere questo 100% a prova di proiettile. È lo stesso problema che l'industria cinematografica ha nella protezione dei contenuti DVD. Se hai un software in grado di decifrare il DVD e riprodurre il contenuto, allora qualcuno può fare un dump della memoria mentre quel software è in azione e trovare la chiave di decodifica.

Answer 3

Il punto di SSL/TLS in generale è tale che l'intercettatore occasionale con Wireshark non è in grado di vedere i tuoi payload. Fiddler/Burp significa che hai interagito con il sistema. Sì, è un'interazione molto semplice, ma richiede (uno) dei sistemi di essere compromesso.

Se si desidera migliorare la sicurezza rendendo inutili questi programmi MITM a un livello di base, è necessario richiedere l'autenticazione del certificato client (SSL a 2 vie) e collegare entrambi i certificati server e client (ad esempio richiedono che solo il particolare il certificato è valido per le comunicazioni). Inoltre, crittografate i payload trasferiti sul cavo con le chiavi pubbliche di ciascuna parte e assicuratevi che le chiavi private risiedano esclusivamente sui sistemi a cui appartengono. In questo modo, anche se una parte (Bob) viene compromessa, l'utente malintenzionato può vedere solo ciò che viene inviato a Bob e non quello che Bob ha inviato ad Alice. Dovresti quindi prendere i payload crittografati e firmare i dati con un certificato verificabile per garantire che i dati non siano stati manomessi (c'è un sacco di dibattiti sull'opportunità di crittografare prima o firmare prima, btw). Inoltre puoi cancellare la firma usando diversi passaggi di qualcosa come sha2 per assicurarti che la firma sia "inviata" (sebbene questo sia in gran parte un passaggio oscuro).

In questo modo si ottiene il modo più sicuro possibile in modo ragionevole quando non si controlla (uno) dei sistemi di comunicazione.

Come altri hanno menzionato, se un utente malintenzionato controlla il sistema, controlla la RAM e può modificare tutte le chiamate di metodo in memoria.