it-swarm.dev

Autenticazione di un server proxy su HTTPS

Quando si accede a un sito Web tramite HTTPS, il browser Web in genere esegue molto lavoro in background: negoziazione di un canale sicuro, convalida del certificato del sito, verifica della catena di attendibilità, ecc.

Se il browser è configurato per utilizzare un proxy Web, l'attuale protocollo HTTP supporta un metodo CONNECT: ciò consente al browser di configurare il tunnel TLS sul sito Web, senza rivelare alcun contenuto della richiesta al proxy (diverso dal nome del sito, ovviamente).

Cosa fa il browser in merito all'identità del server proxy?
Se il proxy non ha un certificato, potenzialmente potrebbe essere rappresentato da un MitM.
Anche se il proxy ha ha un certificato, se non è verificato, potrebbe essere comunque possibile impersonarlo.

Il protocollo (o qualsiasi altro RFC associato) definisce come deve essere gestito? In che modo i browser Web comuni in genere gestiscono questo?
Se il proxy non ha un certificato, c'è un feedback per l'utente? Se il proxy ha un certificato, ma non è valido, allora c'è un feedback?


Inoltre, esiste una disposizione per l'autenticazione sicura del proxy Web, anche quando la richiesta è semplice HTTP?
Ad esempio, la connessione al proxy su HTTPS anche se la richiesta al sito Web è su HTTP ...


NOTA: non sto chiedendo come identificare sito web, sia sintonizzato attraverso il proxy o se intercetta la catena SSL.
Piuttosto, voglio verificare l'identità del proxy stesso, per assicurarmi che nessun server non autorizzato mi stia mitigando ...

26
AviD

Come di consueto, prima rispondiamo alla domanda esatta che è stata posta.

Al momento, l'utilizzo di HTTPS per connettersi a proxy non è ampiamente supportato. calamari documentazione contiene alcune informazioni sull'argomento; per riassumere:

  • Chrome lo supporta, ma deve essere configurato tramite un script di autoconfigurazione del proxy perché non c'è supporto GUI. Questo significa anche no utilizzando la "configurazione proxy a livello di sistema".

  • Firefox non lo supporta, sebbene la funzionalità sia stata contrassegnata come richiesto dal 2007. (AGGIORNAMENTO: Supportato in FF 33 + )

  • Nessuna indicazione su altri browser, che si può supporre significhi "nessun supporto".

Cosa Chrome quando si incontra un certificato "piuttosto non valido" per il proxy dovrebbe essere testato, ma è probabile che dipenda dalla versione esatta del browser (che cambia continuamente, spesso in modo trasparente), il sistema operativo (poiché la gestione dei certificati tende a essere delegata al sistema operativo) e in che modo il certificato non è valido (scaduto, nome del server errato, ancora di fiducia sconosciuta, ...). Inoltre, è presente un pollo intrinseco e Emissione dell'uovo qui: la convalida completa del certificato, come richiesto da X.509 , include il controllo della revoca, ovvero il download di CRL per tutti i certificati nel percorso. L'URL per il download CRL si trova di solito nei certificati stessi. Ma se stai usando un proxy per il tuo traffico HTTP, allora il download CRL dovrà passare attraverso quel proxy ... e non hai ancora convalidato il certificato proxy. Nessun pollo, nessun uovo.

Possiamo anche notare che il formato del file di configurazione automatica del proxy non supporta realmente il proxy HTTPS. Non esiste un formale standard per questo file, ma l'abitudine è quella di seguire una vecchia bozza di Netscape che dice che un file PAC definisce una funzione Javascript che può restituire proxy nome host e porte, ma non protocollo. Quindi, nessun HTTPS. Per il suo supporto proxy HTTPS, Chrome utilizza implicitamente un'estensione di questa convenzione di fatto inserendo un URL HTTPS dove non ha il diritto di essere e sperando affinché il browser ne abbia un senso.


Come di consueto, vediamo quali proposte alternative possono essere fatte.

Per garantire una comunicazione protetta tra il client e il proxy, possono essere applicabili le due seguenti soluzioni:

  • Usa un VPN . Questo è altamente generico e poiché funziona a livello di sistema operativo, si applicherà a tutti i browser. Ovviamente, richiede che chiunque installi la cosa sul client macchina abbia diritti amministrativi su quella macchina (non puoi farlo come un semplice utente non privilegiato).

  • Utilizza un proxy SOCKS basato su SSH . Sul tuo sistema client, esegui: ssh -N -D 5000 theproxy; quindi imposta il tuo browser per utilizzare localhost:5000 come proxy SOCKS. Questa soluzione richiede che il server proxy (theproxy) sia anche un server SSH e che sia presente un account e che la porta SSH non sia bloccata da un firewall mal temperato.

La soluzione proxy SOCKS assicurerà che il traffico passi attraverso la macchina proxy, ma non include memorizzazione nella cache, che è uno dei motivi per cui in genere si desidera utilizzare un proxy in primo luogo. Tuttavia, può essere modificato utilizzando alcuni strumenti aggiuntivi. Il proxy SOCKS consiste nel reindirizzare tutto il traffico TCP/IP (genericamente) attraverso un tunnel personalizzato. È possibile il supporto generico per le applicazioni, "sostituendo" le normali chiamate di rete a livello di sistema operativo con versioni che utilizzano SOCKS. In pratica, utilizza uno specifico DLL che viene inviato alle librerie del sistema operativo standard; questo è supportato nei sistemi basati su Unix con LD_PRELOAD, e suppongo che ciò possa essere fatto anche con Windows. Quindi la soluzione completa sarebbe:

  • Si utilizza un tunnel SOCKS basato su SSH dal client al computer proxy.
  • Il client SOCKS DLL viene applicato sul browser e configurato per utilizzare localhost:5000 come proxy SOCKS.
  • Il browser vuole solo usare theproxy:3128 come semplice proxy HTTP.

Quindi, quando il browser desidera navigare, apre una connessione a theproxy:3128, che DLL intercetta e reindirizza a un tunnel SOCKS che apre a localhost:5000. A quel punto, SSH prende i dati e li invia a theproxy sotto la protezione del tunnel SSH. I dati escono su theproxy, a quel punto la connessione alla porta 3128 è puramente locale (quindi immune da aggressori basati su rete).

Un altro modo per aggiungere la memorizzazione nella cache sull'impostazione SSH-SOCKS è applicare un proxy trasparente . Squid può farlo (sotto il nome di "intercettazione nella cache").

Ancora un altro modo per eseguire la memorizzazione nella cache con la protezione SSH è utilizzare SSH per creare un tunnel generico dal computer al proxy. Esegui questo:

ssh -N -L 5000:localhost:3128 theproxy

e quindi imposta il tuo browser per utilizzare localhost:5000 come proxy [~ # ~] http [~ # ~] proxy (non SOCKS). Questo non si applica al proxy su protocolli alternativi come FTP o Gopher, ma chi li usa comunque?


Come di consueto, facciamo ora la domanda.

Dici di voler proteggere da un attacco man-in-the-middle . Ma, in realtà, il proxy è un MitM. Quello che vuoi davvero è che il proxy sia l'entità only che fa un MitM. L'HTTPS tra il browser e il proxy (o SSH-SOCKS o una VPN) può proteggere solo il collegamento tra il client e il proxy e non tra il proxy e il server Web di destinazione. Sarebbe presuntuoso affermare che gli attacchi MitM sono contrastati in modo affidabile senza tener conto di ciò che accade su Internet, che è noto per essere un luogo duro.

Per la protezione end-to-end contro MitM, utilizzare SSL, ovvero esplorare i server Web HTTPS. Ma se lo fai, allora la protezione aggiuntiva per il collegamento browser-proxy è superflua.

Proteggere il traffico tra browser e proxy ha senso se si considera autenticazione proxy. Alcuni proxy richiedono un'autenticazione esplicita prima di concedere l'accesso ai loro servizi; questo è (era?) comune nelle grandi organizzazioni, che volevano riservare "accesso illimitato a Internet" ad alcuni pochi felici (di solito, il Boss e i suoi favoriti preferiti). Se si invia una password al proxy, non si desidera spiare la password, quindi SSL. Tuttavia, un utente malintenzionato che può intercettare sulla rete locale controlla necessariamente un computer locale con privilegi di amministratore (possibilmente, un laptop che si è portato da solo). I suoi poteri di disturbo sono già ben al di là del semplice sanguisuga sulla larghezza di banda di Internet. Inoltre, la limitazione dell'accesso a Internet in base a per utente si associa piuttosto male ai moderni sistemi operativi, che tendono a fare affidamento sull'accesso a Internet per molte attività, inclusi gli aggiornamenti del software. L'accesso a Internet è controllato in modo più efficiente su base per utilizzo.

Pertanto, penso che proteggere l'accesso a un proxy HTTP has alcuni meriti, ma solo in scenari piuttosto rari. In particolare, ha ben poco a che fare con la sconfitta della maggior parte degli attacchi MitM.

25
Thomas Pornin

Chrome sul lato client e Squid sul lato proxy possono funzionare tramite https. Vedi Secure Web Proxy per maggiori dettagli.

Spero che Chrome ti avvertirà del certificato proxy non valido, ma non ho esperienza con questa configurazione, quindi non posso confermare.

3
lubas

In alternativa all'utilizzo della risposta di @Thomas Pornin (dove ha suggerito di utilizzare SSH) è possibile utilizzare il bus di servizio per mantenere una connessione trasparente da una porta locale a un server remoto.

L '"autenticazione" si verifica quando il software client proxy si collega al bus di servizio ... l'endpoint di questo bus di servizio può essere qualsiasi cosa, come una intranet, un proxy aziendale, ecc. Una volta che il software client ti ha autenticato, un mini-vpn è creato (proprio come SSH).

Come iniziare

Questo client .Net è installato localmente e la destinazione è un proxy o un altro dispositivo di cui ti devi fidare.

Installa Port Bridge

Nota: sostituisci mentalmente SQL Client e 1433 con una porta di tua scelta ... è lo stesso con questo TCP

Questo progetto consente a diversi server NAT di accedere a diversi client NAT su Internet tramite una singola connessione del bus di servizio.

alt text

È un'implementazione piuttosto intelligente che ti farà davvero pensare. Di seguito è la fonte

http://blogs.msdn.com/b/clemensv/archive/2009/11/18/port-bridge.aspx

... e un'altra spiegazione della stessa.

http://brentdacodemonkey.wordpress.com/2010/05/05/Azure-appfabric-%e2%80%93-a-bridge-going-anywhere/

Inoltre, esiste un progetto correlato chiamato "SocketShifter" su codeplex: http://socketshifter.codeplex.com/ Anche se il sito codeplex consiglia di usare portbridge, vedo i check-in a partire da (agosto 2010) e non sono sicuro di quale sia più aggiornato. Potrebbe valere la pena indagare.

0