it-swarm.it

Https impedisce gli attacchi man in the middle da parte del server proxy?

Esiste un client desktop A che si collega al sito Web W in una connessione https

A --> W

In qualche modo tra A e W, c'è un proxy G.

A --> G --> W
  • In questo caso, G sarà in grado di ottenere il certificato che A ha ottenuto in precedenza da W?
  • Se G può ottenere il certificato, significa che G sarà in grado di decrittografare i dati?
183
jojo

Come funziona HTTPS?

HTTPS si basa su crittografia a chiave pubblica/privata. Ciò significa fondamentalmente che esiste una coppia di chiavi: la chiave pubblica viene utilizzata per la crittografia e la chiave privata segreta è necessaria per la decrittografia.

Un certificato è fondamentalmente una chiave pubblica con un'etichetta che identifica il proprietario.

Pertanto, quando il browser si connette a un server HTTPS, il server risponderà con il suo certificato. Il browser controlla se il certificato è valido:

  • le informazioni sul proprietario devono corrispondere al nome del server richiesto dall'utente.
  • il certificato deve essere firmato da un'autorità di certificazione attendibile.

Se una di queste condizioni non viene soddisfatta, l'utente viene informato del problema.

Dopo la verifica, il browser estrae la chiave pubblica e la utilizza per crittografare alcune informazioni prima di inviarle al server. Il server può decrittografarlo perché il server ha la chiave privata corrispondente.

In che modo HTTPS impedisce gli attacchi man in the middle?

In questo caso, G sarà in grado di ottenere il certificato che A ha ottenuto in precedenza da W?

Sì, il certificato è la chiave pubblica con l'etichetta. Il server web lo invierà a chiunque si colleghi ad esso.

Se G può ottenere il certificato, significa che G sarà in grado di decrittografare i dati?

No. Il certificato contiene chiave pubblica del server web. Il proxy dannoso non è in possesso della chiave privata corrispondente. Pertanto, se il proxy inoltra il certificato reale al client, non può decrittografare le informazioni che il client invia al server web.

Il server proxy può tentare di falsificare il certificato e fornire invece la propria chiave pubblica. Questo, tuttavia, distruggerà la firma delle autorità di certificazione. Il browser avviserà del certificato non valido.

Esiste un modo in cui un server proxy può leggere HTTPS?

Se l'amministratore del tuo computer collabora, è possibile per un server proxy annusare le connessioni https. Questo viene utilizzato in alcune aziende al fine di cercare virus e applicare linee guida per un uso accettabile.

A autorità di certificazione locale è impostato e l'amministratore comunica al browser che questo CA è affidabile. Il server proxy utilizza questa CA per firmare i suoi certificati contraffatti.

Oh, e ovviamente, l'utente tende a fare clic sugli avvisi di sicurezza.

209

Supponendo che gli utenti non facciano clic sugli avvisi di avviso (e supponendo che si stia eseguendo un client non modificato), la risposta è: No, il proxy non può decrittografare i dati .

Per una spiegazione dettagliata di come HTTPS impedisce a un man-in-the-middle di decrittografare il traffico, vedere qualsiasi risorsa standard su SSL/TLS, ad es.

Post scriptum Il certificato è dati pubblici. Contiene la chiave pubblica e il nome di dominio del server, nessuno dei quali è segreto. L'osservazione del certificato non aiuta l'utente malintenzionato a decrittografare i dati. (Sì, il proxy può osservare il certificato, ma questo è innocuo.)

20
D.W.

Da blog tecnico di Philipp C. Heckel con alcune modifiche leggere:

Mentre è possibile attaccare il traffico HTTP non crittografato senza dover gestire i certificati X.509 e le autorità di certificazione (CA), le connessioni HTTPS crittografate con SSL crittografano ogni richiesta e risposta tra client e server end-to-end. E poiché i dati trasferiti sono crittografati con un segreto condiviso, un intermediario (o un proxy) non può decifrare i pacchetti di dati scambiati. Quando il client apre una connessione SSL/TLS al server Web sicuro, verifica l'identità del server verificando due condizioni: in primo luogo, controlla se il suo certificato è stato firmato da una CA nota al client. E in secondo luogo, si assicura che il nome comune (CN, anche: nome host) del server corrisponda a quello a cui si connette. Se entrambe le condizioni sono vere, il client presuppone che la connessione sia sicura.

Per essere in grado di annusare la connessione, il server proxy può fungere da autorità di certificazione, tuttavia non molto affidabile: invece di rilasciare certificati a persone o organizzazioni reali, il proxy genera dinamicamente certificati per qualsiasi nome host necessario per una connessione . Se, ad esempio, un client desidera connettersi a https://www.facebook.com , il proxy genera un certificato per "www.facebook.com" e lo firma con la propria CA. A condizione che il client si fidi di questa CA, entrambe le condizioni sopra menzionate sono vere (CA fidata, stesso CN), il che significa che il client ritiene che il server proxy sia in realtà "www.facebook.com". La figura seguente mostra il flusso di richiesta/risposta per questo scenario. Questo meccanismo è chiamato proxy HTTPS trasparente.

enter image description here

Perché questo attacco funzioni, ci sono alcune condizioni che devono essere soddisfatte:

  • Server proxy come gateway standard (HTTP e HTTPS) : per il proxy HTTP e HTTPS, il server proxy deve ovviamente essere in grado di intercettare i pacchetti IP - nel senso che deve trovarsi da qualche parte lungo il percorso del percorso del pacchetto. Il modo più semplice per raggiungere questo obiettivo è cambiare il gateway predefinito nel dispositivo client nell'indirizzo del server proxy.
  • CA del proxy attendibile (solo HTTPS) : affinché il proxy HTTPS funzioni, il client deve conoscere (e fidarsi!) Della CA del proxy, ovvero della chiave della CA il file deve essere aggiunto al truststore del client.

enter image description here

Se sei interessato ad annusare in modo trasparente socket SSL semplici, potresti provare SSLsplit, un proxy man-in-the-middle TLS/SSL trasparente. Esistono molti modi per attaccare SSL, ma non sono necessari certificati SSL falsi, un'autorità di certificazione non autorizzata (CA) o variazioni sugli attacchi SSL man-in-the-middle dell'esperto di sicurezza Moxie Marlinspike. Perché andare a tutti quei problemi quando puoi semplicemente acquistare un proxy di intercettazione SSL, come ProxySG di Blue Coat Systems o il loro dispositivo Netronome SSL acquisito di recente per fare il lavoro per te?


Da Steven J. Vaughan-Nichols su ZDNet (estratto):

Blue Coat, il più grande nome nel settore dell'intercettazione SSL, è tutt'altro che l'unico che offre l'intercettazione SSL e si rompe in una scatola. Fino a poco tempo fa, ad esempio, Microsoft avrebbe venduto un programma, Forefront Threat Management Gateway 2010, che avrebbe potuto svolgere anche il lavoro per te. Con un programma proxy di intercettazione SSL o un dispositivo in atto, ecco cosa succede davvero:

enter image description here

Se la tua azienda ha impostato correttamente il proxy, non saprai che nulla è spento perché avranno predisposto la registrazione del certificato SSL interno del proxy sul tuo computer come certificato valido. In caso contrario, riceverai un messaggio di errore pop-up che, se fai clic su per continuare, accetterà il certificato digitale "falso". In entrambi i casi, si ottiene una connessione sicura al proxy, si ottiene una connessione sicura al sito esterno e tutto ciò che viene inviato tramite il proxy può essere letto in chiaro. Ops.

19
manav m-n

A seconda della configurazione della rete in cui ci si trova, potrebbe essere possibile per gli amministratori visualizzare i contenuti delle connessioni HTTPS (e possibilmente delle VPN).

È ovviamente possibile intercettare il traffico sulla rete, ma il solito problema è che non possono emettere certificati validi per tutti i siti visitati, quindi vedresti molti avvisi di certificato ogni volta che accedi a un sito HTTPS, se provano a decifrare il traffico per guardarlo.

Tuttavia, se stai utilizzando una macchina fornita dalla società, potrebbero installare una nuova autorità di certificazione e quindi utilizzarla per creare certificati SSL per i siti visitati, in modo che non si verifichino problemi.

Con il lato VPN delle cose potrebbe essere più complesso se la VPN non utilizza SSL, ma si applica la stessa teoria. Se accedi a Internet da una macchina di proprietà di qualcun altro su una rete che controllano, è probabile che possano accedere a qualsiasi contenuto inserito.

Se stai cercando di evitare questo tipo di problema, utilizzerei un dispositivo che possiedi/controlli per accedere a Internet, in questo modo dovresti essere avvisato se si verifica un'intercettazione SSL.

8
Rory McCune

Bene, gli amministratori della rete aziendale implementano un attacco man-in-the-middle contro il client TLS con la propria CA in modo che possano vedere cosa sta lasciando la loro rete. Probabilmente avranno un dispositivo che creerà un certificato al volo valido per gmail.com quando visiti gmail.com. La ragione per cui lo fanno non è interpretare il Dr. Evil, ma è così che possono proteggersi dal fatto che i segreti commerciali vengano svelati dal loro edificio attraverso la loro connessione Internet. Seriamente, non fare il tuo private banking su un computer da lavoro.

Se si utilizza un prodotto software che non utilizza l'archivio certificati di sistema (ad esempio un'istanza OpenVPN), allora no, non possono intercettare e decodificare il traffico perché non si fidano della propria CA. Ad esempio, potresti ottenere lo stesso risultato utilizzando un'app portatile Firefox. E nella maggior parte dei browser puoi controllare i dettagli della tua connessione sicura e vedere chi è la CA, per essere sicuro di chi sta ascoltando o meno.

7
Bill McGonigle

Il proxy può bloccare https e consentire solo http dal browser. Quindi può avviare la propria connessione https per passare le richieste al server.

La maggior parte degli utenti non lo noterà.

HSTS dovrebbe fermare questo, ma non è ampiamente usato.

4
Erik van Velzen

La terminazione SSL o i prodotti proxy SSL come Bluecoat devono essere sulla tua rete e considerando il costo, le procedure di installazione coinvolte e la normale politica di sicurezza che qualsiasi organizzazione avrebbe chi installa questi prodotti - le minacce di un utente malintenzionato che utilizza un prodotto di terminazione SSL commerciale è quasi zero. OTOH - un insider di fiducia con accesso al NOC (centro operativo di rete) potrebbe infatti monitorare il traffico terminato con SSL e divulgare informazioni sensibili.

Questa è una preoccupazione comune (giustificata o meno) per le aziende che implementano sistemi DLP.

TUTTAVIA DETTO TUTTO QUESTO - esiste un altro vettore di attacco che è comune nello spazio di home banking che non richiede un proxy di rete ed è attacchi piggback/shim nel browser - poiché il DOM ha accesso a cancellare il traffico di testo prima che colpisca il Pipa SSL: questo è un comodo vettore di attacco ed è spesso installato tramite un'estensione del browser. Esiste un eccellente articolo di Stackexchange sugli spessori: È possibile installare uno shim (aka polyfill) in IE, FF o Chrome a insaputa dell'utente e può leggere le password inserite dall'utente su una pagina di accesso?

2
Danny Lieberman