Come faccio a verificare di avere una connessione SSL diretta a un sito web?

11

Ho sempre pensato che se avessi una connessione SSL non ci sarebbero stati attacchi MITM. Ora sembra che non sia vero (vedi i commenti in questa domanda Va bene dal punto di vista della sicurezza leggere i cookie stranieri (non attendibili) in una rete attendibile? )

Non sono ancora sicuro di come funzioni e se ciascun browser debba installare un certificato, ma suona come un proxy sulla tua connessione LAN o reindirizza il dominio (probabilmente non ho capito bene) o usa un certificato alternativo (non cert è necessario abbinare il dominio? Sono ancora confuso).

Sarebbe possibile verificare se sono connesso al sito vero? Sarebbe anche utile se puoi spiegare come il proxy può creare un certificato valido per un dominio per cui non ha le chiavi / chiavi reali. (So che si tratta di due domande, ma entrambe possono essere spiegate da una sola risposta.)

    
posta Community 06.05.2012 - 23:29
fonte

3 risposte

8

Per verificare che stai parlando con il server remoto che desideri direttamente, sono necessari due punti:

Ciò che costituisce quel server remoto dipende dal fornitore di servizi. Stai confondendo più tipi di server proxy qui.

  • Esistono normali server proxy HTTP che possono essere utilizzati per le connessioni HTTPS. Questo viene fatto usando il verbo HTTP CONNECT e l'intero traffico SSL / TLS tra il browser e il server di destinazione viene semplicemente trasmesso dal server proxy. Per quanto riguarda la connessione SSL / TLS, questo è approssimativamente equivalente al routing IP: il proxy non vedrà nulla.

  • Ci sono server reverse proxy HTTP. Questo è ciò che è discusso in la domanda a cui ti colleghi . Tuttavia, la richiesta viene gestita internamente fino al fornitore di servizi.

    Allo stesso modo di per le connessioni al database , può essere utile che il fornitore di servizi protegga i suoi interni Traffico HTTP che utilizza SSL / TLS, se le richieste sono servite da nodi worker HTTP. In questo caso, il nodo principale del bilanciamento del carico / proxy inverso sarà il client di quei server Web interni.

    Per quanto ti riguarda, il "vero sito" è il nodo principale / proxy inverso. https://www.google.com/ ha certamente più di una sola casella per gestire le richieste che ottiene. Per quanto ti riguarda, l'intero cluster dietro di esso è la (grande) macchina.

  • Server proxy MITM. Alcuni server proxy HTTP saranno in grado di esaminare il traffico HTTP (ad esempio Squid + SSL Bump ). Per fare ciò, essi genereranno di nuovo un certificato utilizzando la propria Autorità di certificazione al volo. Tali certificati non verranno convalidati nel browser (passaggio 1 precedente), a meno che la macchina non sia stata configurata in modo esplicito per fidarsi di questa CA locale.

risposta data 07.05.2012 - 15:05
fonte
5

Se stai utilizzando un proxy SSL, devi essere specificamente configurato per fidarti del proxy. Il proxy utilizza un certificato con caratteri jolly, pertanto il browser accetterà il certificato per qualsiasi sito. Ovviamente, l'utilizzo di un proxy SSL di cui non ti fidi completamente è una pessima idea molto .

I normali proxy HTTP possono proxy SSL, ma semplicemente copiano i dati, non possono modificarli o decodificarli. Continui a vedere il normale certificato del sito.

Se sei preoccupato per la scarsa sicurezza sul lato del sito web, non c'è nulla che tu possa controllare o fare al riguardo. Hanno il diritto di decifrare tutti i dati che scegli di inviare loro. Se non lo proteggono, non c'è nulla che tu possa fare al riguardo. Se stanno utilizzando un proxy internamente per essere l'endpoint SSL, è loro responsabilità mantenere i dati decrittografati sulla loro rete interna. Non c'è niente che puoi fare se compromettono i dati. Dovrebbero essere in grado di gestire i dati decrittati come vogliono.

SSL protegge solo i dati tra i due endpoint SSL.

    
risposta data 07.05.2012 - 02:02
fonte
3

L'unico modo in cui un proxy può agire come un man-in-the-middle (presupponendo che il client e il server implementino correttamente una versione non interrotta del protocollo SSL / TLS e che le autorità di certificazione svolgano correttamente il loro lavoro ) è se il tuo browser si fida del proxy. Questo perché all'inizio della connessione, il client convalida che l'altro endpoint ha un certificato valido generato da un'autorità di certificazione riconosciuta.

Potrebbe esserci un proxy tra il client e il server. Questo è comune sulle reti aziendali, ad esempio, che spesso non hanno una connessione diretta tra gli host interni e Internet. Ma il proxy può scambiare solo byte avanti e indietro. Non può sapere, e tanto meno modificare, il contenuto. Può sapere a quale indirizzo IP ti stai collegando, ma non quale URL stai sfogliando.

Quindi cosa può andare storto? Se il tuo browser riconosce una CA che è intenzionata a firmare che proxy.example.com è il server a cui il client sta tentando di connettersi, allora proxy.example.com può effettuare la propria connessione al server e la connessione del client può essere reindirizzata in modo visibile o trasparente al proxy. Quindi il proxy è un man-in-the-middle.

Alcune reti aziendali configurano tutti i client in modo che si fidino dell'autorità di certificazione aziendale e impongono un proxy che riscrive tutte le connessioni SSL. Il client vede quindi ogni sito con un certificato firmato dalla CA dell'organizzazione. Dal momento che tutti i certificati hanno una firma valida, non lo noterai nell'uso quotidiano. Il modo per scoprire se questo sta accadendo (supponendo che il browser stesso non sia stato manomesso, solo il suo elenco di certificati) è quello di verificare chi ha firmato un particolare certificato, o di consultare l'elenco delle autorità di certificazione attendibili.

    
risposta data 07.05.2012 - 02:53
fonte