Domanda:
Https impedisce agli attacchi man in the middle da parte del server proxy?
jojo
2011-10-15 05:23:38 UTC
view on stackexchange narkive permalink

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  
  • In questo caso, G sarà in grado di ottenere il certificato che apreviously ottenuto da W?
  • Se G può ottenere il certificato, significa che G sarà in grado di decriptare i dati?
Sette risposte:
#1
+213
Hendrik Brummermann
2011-10-22 01:19:03 UTC
view on stackexchange narkive permalink

Come funziona HTTPS?

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 :

  • le informazioni sul proprietario devono corrispondere al nome del server richiesto dall'utente.
  • il certificato deve 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 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.

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

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.

Se l'amministratore e il computer collaborano, non ci saranno avvisi sui certificati. Come può l'utente sapere se il proxy ascolta la conversazione? Afaik, la mia azienda esegue la scansione di https, ma non vedo il certificato autofirmato nel trust della catena quando esamino i certificati dei siti https.
Puoi rilevarlo. Primo, il certificato della tua azienda non è autofirmato. È un certificato debitamente firmato da un'autorità che è automaticamente incorporato in tutti gli Internet Explorer del mondo. Per rilevare tutte le quote di certificati ** magic ** senza il tuo preavviso, è disponibile un percorso unico ma difficile. Rimuovi tutti i certificati radice magicamente autorizzati all'interno di Internet Explorer. Da questo punto di partenza, dovrai accettare esplicitamente ** tutti i certificati dei server **. Dovrai leggerli, capirli e accettare quelli di cui ** ti fidi **.
una domanda è: non riesco a vedere cosa sta lasciando la rete, ma per quanto riguarda la risposta che il server ha inviato al browser, ora ho la chiave pubblica, significa che posso decodificare tutte le risposte e ho visto tutto ciò che è il browser vedendo ?
La chiave pubblica consente solo di crittografare i dati e viene utilizzata solo per la negoziazione della chiave di sessione. (@Hendrik potresti forse migliorare la parte sull'utilizzo della chiave pubblica da parte del browser)
Chiunque sia in grado di generare un certificato per il proxy che viene firmato utilizzando un certificato di firma di qualsiasi CA attendibile dal tuo computer sarà in grado di intercettare la tua connessione. Ci sono RFC / tecnologia in grado di impedirlo? Sono a conoscenza di alcuni plugin che forniscono un db di impronte digitali certificato e ti avvisano se l'impronta digitale del certificato che ottieni non è la stessa che riceve il server dei plugin, ma anche quelli potrebbero essere intercettati. Sebbene i proxy https siano oggi utilizzati solo nelle aziende come hai descritto, questo apre la strada agli attacchi mitm per gli aggressori con sufficiente influenza da mettere le mani su CA affidabili.
@masi Esiste un progetto chiamato [Certificate Patrol] (http://patrol.psyced.org/) che tiene traccia dei certificati visti in precedenza e può avvisarti se un certificato cambia in modo imprevisto. Non è utile nel contesto aziendale sopra descritto, ma potrebbe essere utile su un dispositivo mobile per avvisarti quando la tua rete locale è ostile.
E che dire della risposta che W invia ad A? G sarà in grado di leggerlo?
@se7entyse7en n.Proprio come W ha una chiave privata, anche A stabilisce tale chiave all'inizio della comunicazione.G non ha nessuna di queste chiavi.
@zinking No, non è possibile, la chiave pubblica / privata viene utilizzata solo per creare una chiave di sessione e tale chiave di sessione viene utilizzata per crittografare / decrittografare tutto il traffico tra client / server https poiché la crittografia simmetrica è più veloce.
Buon articolo.Grazie.Ho una domanda: prima della negoziazione della chiave di sessione, può `G` acquisire la chiave pubblica dal server web e procedere con una negoziazione della chiave di sessione prima di` A`, in modo che possa agire come `A`?
@Jeon, la chiave pubblica (e le informazioni sul certificato) sono pubbliche, quindi chiunque può prenderle.Ma durante l'handshake TLS, il server deve dimostrare di conoscere la chiave privata associata.Ad un certo punto il client crittograferà un'informazione indovinabile con la chiave pubblica e il server deve decrittarla con la sua chiave privata per continuare l'handshake.Per i dettagli, consultare l '[articolo di Wikipedia sul TLS] (https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake).
Puoi aggiungere ulteriori informazioni qui: "distruggere la firma delle autorità di certificazione".Allora perché "G" non può fornire la sua chiave pubblica ad "A" e falsificare il certificato in modo che sia firmato correttamente con la sua chiave privata?Quindi è doppio firmato, una volta da `W` e una volta da` the truzsted certificate provider` e `A` conosce anche questa chiave pubblica.
In che modo ciò rappresenta un rischio per la sicurezza delle applicazioni web?
Un altro caso che mina il concetto può essere forme di bloatware preinstallato.Il caso più importante che ricordo sia stato Lenovo che installava "SuperFish".Anche se alla fine questo è solo l'equivalente di "l'amministratore collabora", anche se in questo caso inconsapevolmente.
Si noti che le versioni più recenti di Firefox visualizzeranno "Connessione verificata da un emittente di certificati non riconosciuto da Mozilla" per i certificati non approvati da NSS, quindi (a differenza di Chrome e IE) gli attuali proxy COTS TLS possono essere notati da un utente Firefox consolo 1 clic di indagine forense.
#2
+21
D.W.
2011-10-15 07:38:17 UTC
view on stackexchange narkive permalink

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.)

Supponendo che nessuna CA radice venga visualizzata e perda il controllo della sua chiave privata.
È giusto presumere che le CA (root e delegate) forniranno certificati fasulli alle loro agenzie di intelligence nazionali. Apparentemente c'è stata, presumibilmente accidentale, commercializzazione pubblica di dispositivi proxy che utilizzano questo tipo di certificati.
In realtà [Blue Coat ProxySG] (https://www.bluecoat.com/products/proxysg) esegue MiTM su HTTPS da molto tempo a seconda dei certificati attendibili personalizzati installati sui client che accedono attraverso di loro, fondamentalmente fingendo di essere CA oltre ad essere un proxy _caching_. Simili stanno facendo Nokia, Opera mobile, Amazon Kindle, e.t.c., installando certificati root affidabili sui loro client e quindi inviando tramite proxy tutte le richieste attraverso i loro server CA falsificati. In breve, chiunque affermi o sembri eseguire il caching, la ricompressione o l'ottimizzazione in altro modo dei contenuti HTTPS "in mezzo" lo sta facendo.
Ovviamente un proxy può decrittografare i dati: si stabilisce una connessione ssl al proxy, il proxy decrittografa tutto, quindi stabilisce la connessione ssl alla destinazione effettiva e viceversa sulla risposta: http://www.zdnet.com/article/how-the- nsa-e-il-tuo-capo può intercettare-e-rompere-ssl /
@markmnl Ciò richiede che i client siano configurati in modo da considerare attendibili i certificati del proxy o che gli utenti ignorino ciecamente i messaggi di errore risultanti (una buona scommessa, ad essere onesti). Dall'articolo che hai collegato: "Se la tua azienda ha impostato correttamente il proxy, non saprai che nulla è spento perché avranno 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". "
#3
+19
manav m-n
2014-09-17 12:33:31 UTC
view on stackexchange narkive permalink

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.

enter image description here

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.

enter image description here

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:

enter image description here

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.

È possibile distinguere il certificato originale di Facebook da generato da man-in-the-middle?
@manav sei sicuro dicendo a facebbok.com e mostrando ovunque il certificato funzionerà ??
@SudhanshuGaur credi davvero che le informazioni di cui sopra siano sufficienti per hackerare facebbok.com !!Le informazioni fornite sono molto semplici, più vecchi e gli odierni sistemi di sicurezza organizzativa sono miglia avanti sia nella decrittazione HW che SW
#4
+8
Rory McCune
2014-03-26 13:52:25 UTC
view on stackexchange narkive permalink

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.

#5
+8
Bill McGonigle
2014-03-30 08:43:06 UTC
view on stackexchange narkive permalink

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.

#6
+4
Erik van Velzen
2017-03-10 05:16:09 UTC
view on stackexchange narkive permalink

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.

#7
+2
Danny Lieberman
2015-09-01 14:46:51 UTC
view on stackexchange narkive permalink

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?



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...