2010-06-20 16 views
5

Nel modello di sicurezza HTTPS, la parte più debole è l'elenco di CA attendibile nel browser. Ci sono molti modi in cui qualcuno potrebbe iniettare CA in più alla lista che gli utenti si fidano del ragazzo sbagliato.Come prevenire l'attacco man-in-middle HTTPS dal lato server?

Ad esempio, un computer pubblico o un PC nella propria azienda. L'amministratore potrebbe forzare a fidarsi di una CA emessa da lui stesso, potrebbe essere molto insicuro con un server proxy HTTPS con inoltro HTTPS. Di conseguenza, saranno in grado di SPY il tuo messaggio, login e password anche se il browser ti dice che sei in una connessione SSL affidabile.

In questo caso, cosa può fare lo sviluppatore di applicazioni Web per proteggere l'utente e anche il sistema?

+1

Per installare un certificato di autorità radice attendibile è necessario l'accesso al computer degli utenti. Una volta che hai accesso a una macchina, esistono modi molto più semplici per rubare i dati che installare un certificato, quindi questo scenario non è realmente valido in termini di utilità della sicurezza SSL. SSL è più da proteggere dagli attacchi man-in-the-middle in cui un utente sta semplicemente sniffando il traffico inviato sul filo senza accesso diretto al computer degli utenti. – TheCodeKing

risposta

4

In qualità di sviluppatore di applicazioni Web, non si può fare molto a riguardo.

Questo problema deve essere affrontato più in basso.

Se qualcuno a metà strada in tutto il mondo vuole:

a. Mettere una CA falsa radice sul computer di qualcuno

b. Emettere un certificato per il proprio dominio in base a tale CA

c. Impersonare il tuo sito

d. Indirizza la voce DNS locale di qualcuno per il tuo dominio a un diverso IP

In nessuno dei passaggi precedenti la tua applicazione è stata coinvolta o consultata, quindi è qui che è importante una buona amministrazione e sicurezza della rete.

A parte questo, forse c'è un motivo legittimo per qualcuno a fare proprio questo sulla propria rete personale. Chi sono io per fermarli?

Questo è essenzialmente ciò che i filtri proxy Web aziendali fanno e sono nei loro diritti per farlo.

Per quanto riguarda l'arresto di qualcuno malintenzionato da eseguire i passaggi precedenti è qualcosa che deve essere messo sugli amministratori delle macchine clienti.

+0

Alcune domande recenti http://stackoverflow.com/questions/19993696/is-there-any-way-to-access-ssl-certificate-details-using-javascript mi ​​indicano una possibile soluzione alternativa. Questo progetto https://github.com/digitalbazaar/forge può aiutare JavaScript a leggere le informazioni SSL, potrebbe aiutare ad avere un qualche tipo di avviso se il nome dell'emittente di CA non corrisponde. –

1

Teoricamente parlando, se l'utente del terminale è di proprietà di un avversario, hai già perso e non c'è niente che tu possa fare a questo proposito - se arriva il momento critico che possano filtrare le vostre contromisure o anche raschiare e spoofing l'intero sito.

In pratica, puoi fare cose per rendere più difficile il lavoro dell'avversario, ma è una corsa agli armamenti. Probabilmente dovrai utilizzare tutti gli stessi tipi di contromisure che il software dannoso utilizza contro gli scanner, perché dal punto di vista dell'avversario il tuo sito si sta comportando in modo malevolo cercando di impedirne l'override! - e sappi che tutto ciò che fai può essere rapidamente neutralizzato se il tuo avversario si preoccupa abbastanza.

È possibile, ad esempio, aprire le prese o utilizzare XmlHttpRequest da JavaScript o da applet, ma non è possibile impedire all'avversario di aggiornare i propri filtri per rimuovere tutto ciò che si aggiunge.

È possibile ottenere un maggior numero di chilometri emettendo un output polimorfico o utilizzando altre tecniche di anti-reverse engineering, quindi non sembra che due hit al sito producano codice/risorse simili inviati al browser.È una quantità eccessiva di lavoro, ma dà al tuo avversario un rompicapo da masticare se vuole interpretare l'uomo nel mezzo.

Problemi correlati