Esiste un client desktop A che si connette al sito Web W in una connessione https
A --> W In qualche modo tra A e W, lì è un proxy G.
A --> G --> W HTTPS si basa sulla 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 è richiesta per la decrittografia.
Un certificato è fondamentalmente una chiave pubblica con un etichetta che identifica il proprietario.
Quindi, quando il browser si connette a un server HTTPS, il server risponderà con il suo certificato. Il browser controlla se il certificato è valido :
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 questo case, 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 connetta ad esso.
Se G può ottenere il certificato, significa che G sarà in grado di decrittografare i dati?
No. Il certificato contiene la chiave pubblica del server web . Il proxy dannoso non è in possesso della chiave privata corrispondente. Quindi, se il proxy inoltra il certificato reale al client, non può decifrare le informazioni che il client invia al server web.
Il server proxy potrebbe provare a falsificare il certificato e fornire invece la propria chiave pubblica. Ciò, tuttavia, distruggerà la firma delle autorità di certificazione . Il browser avviserà del certificato non valido.
Se l ' amministratore del tuo computer collabora , è possibile che un server proxy rilevi le connessioni https. Viene utilizzato in alcune aziende per cercare virus e per applicare linee guida per un uso accettabile.
Viene configurata un ' autorità di certificazione locale e l'amministratore comunica al browser che questa CA è affidabile . Il server proxy utilizza questa CA per firmare i suoi certificati contraffatti.
Oh, e ovviamente gli utenti tendono a fare clic sugli avvisi di sicurezza.
Supponendo che gli utenti non facciano clic sugli avvisi del certificato (e supponendo che tu 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 tuo traffico, vedi qualsiasi risorsa standard su SSL / TLS, ad esempio,
PS Il certificato è un dato pubblico. Contiene la chiave pubblica del server e il nome di dominio, nessuno dei quali è segreto. L'osservazione del certificato non aiuta l'aggressore a decrittografare i dati. (Sì, il proxy può osservare il certificato, ma questo è innocuo.)
Dal blog tecnico di Philipp C. Heckel con alcune lievi modifiche:
Mentre l'attacco del traffico HTTP non crittografato può essere fatto senza dover gestire i certificati X.509 e autorità di certificazione (CA), 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 controllando due condizioni: in primo luogo, controlla se il suo certificato è stato firmato da una CA nota al client. 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 presume che la connessione sia sicura.
Per essere in grado di annusare la connessione, il server proxy può agire come un'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 sia 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 attendibile, stesso CN), il che significa che il client crede 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.
Perché questo attacco funzioni, ci sono alcune condizioni che devono essere soddisfatte:
- Server proxy come gateway standard (HTTP e HTTPS) : sia per il proxy HTTP che per quello HTTPS, il server proxy deve ovviamente essere in grado di intercettare i pacchetti IP, il che significa che deve trovarsi da qualche parte lungo il via del percorso del pacchetto. Il modo più semplice per ottenere ciò è modificare il gateway predefinito nel dispositivo client con l'indirizzo del server proxy.
- CA proxy attendibile (solo HTTPS) : affinché il proxy HTTPS funzioni , il client deve conoscere (e fidarsi!) della CA proxy, ovvero il file della chiave CA deve essere aggiunto al truststore del client.
Se sei interessato ad analizzare in modo trasparente i semplici socket SSL, 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 (CA) canaglia o variazioni sugli attacchi SSL man-in-the-middle dell'esperto di sicurezza Moxie Marlinspike. Perché darsi tutti quei problemi quando puoi semplicemente acquistare un proxy di intercettazione SSL, come ProxySG di Blue Coat Systems o il loro dispositivo SSL Netronome recentemente acquisito per fare il lavoro per te?
Da Steven J. Vaughan-Nichols su ZDNet (estratto):
Blue Coat, il nome più famoso nel settore delle intercettazioni SSL, è lungi dall'essere l'unico offrendo intercettazione SSL e rottura in una scatola. Fino a poco tempo, ad esempio, Microsoft ti vendeva un programma, Forefront Threat Management Gateway 2010, che potrebbe fare il lavoro anche per te. Con un programma o un dispositivo proxy di intercettazione SSL installato, ecco cosa succede realmente:
Se la tua azienda ha impostato correttamente il proxy, non saprai che nulla è disattivato perché avrà disposto che il certificato SSL interno del proxy sia registrato sulla tua macchina come certificato valido. In caso contrario, riceverai un messaggio di errore popup che, se fai clic su per continuare, accetterà il certificato digitale "falso". In entrambi i casi, ottieni una connessione sicura al proxy, ottiene una connessione sicura al sito esterno e tutto ciò che viene inviato tramite il proxy può essere letto in testo normale. Spiacenti.
A seconda della configurazione della rete in cui ti trovi, potrebbe essere possibile per gli amministratori visualizzare i contenuti delle connessioni HTTPS (e possibilmente VPN).
Ovviamente è possibile intercettare il traffico sulla rete, ma il solito problema è che non possono emettere certificati validi per tutti i siti che visiti, quindi vedresti ogni volta molti avvisi sui certificati si accede a un sito HTTPS, se cercano di decrittografare il traffico per guardarlo.
Tuttavia, se si utilizza una macchina fornita dalla società, potrebbero installare una nuova autorità di certificazione e quindi utilizzarla per crea certificati SSL per i siti che visiti, quindi non si presenterebbe come un problema.
Con il lato VPN delle cose potrebbe essere più complesso se la VPN non utilizza SSL, ma la stessa teoria si applica. Se accedi a Internet da una macchina di proprietà di qualcun altro su una rete che controlla, è probabile che questi possano accedere a qualsiasi contenuto che inserisci.
Se stai cercando di evitare questo tipo di problema, io userei un dispositivo che possiedi / controlli per accedere a Internet, in questo modo dovresti essere avvisato se si verifica un'intercettazione SSL.
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 lascia la loro rete. Probabilmente avranno un dispositivo che creerà un certificato al volo valido per gmail.com quando visiti gmail.com. Il motivo per cui lo fanno non è per interpretare il Dr. Evil, è per evitare che i segreti commerciali vengano portati fuori dal loro edificio tramite la loro connessione Internet. Seriamente, non eseguire operazioni bancarie private su un computer di lavoro.
Se utilizzi un prodotto software che non utilizza l'archivio dei certificati di sistema (ad esempio, un'istanza di OpenVPN), no, non possono intercettare e decodifica il tuo traffico perché non ti fidi della loro 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 protetta e vedere chi è la CA, per essere sicuro di chi sta ascoltando o meno.
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 se ne accorgerà.
HSTS dovrebbe fermare tutto questo ma non è ampiamente utilizzato.
La terminazione SSL o i prodotti proxy SSL come Bluecoat devono essere sulla rete e considerando il costo, le procedure di installazione coinvolte e la normale politica di sicurezza che qualsiasi organizzazione avrebbe a disposizione di chi installa questi prodotti: le minacce di un malintenzionato che utilizza un SSL commerciale prodotto di terminazione è quasi zero. OTOH: un membro fidato 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 AVENDO DETTO TUTTO QUESTO - c'è un altro vettore di attacco comune nello spazio home banking che non richiede un proxy di rete ed è attacchi piggback / shim nel browser - poiché il DOM ha accesso per cancellare il traffico di testo prima che raggiunga il pipe SSL: questo è un comodo vettore di attacco e viene spesso installato tramite un'estensione del browser. C'è un ottimo articolo Stackexchange sugli shim: È possibile installare uno shim (noto anche come polyfill) in IE, FF o Chrome senza che l'utente ne sia a conoscenza e può leggere le password inserite dall'utente in una pagina di accesso?