Quali usi legittimi hanno i proxy del browser?

Uno dei primi usi dei proxy HTTP era la memorizzazione nella cache dei proxy al fine di utilizzare meglio la costosa larghezza di banda e velocizzare la navigazione memorizzando nella cache il contenuto pesantemente utilizzato vicino all'utente. Ricordo un periodo in cui gli ISP utilizzavano proxy espliciti obbligatori per gli utenti. Questo era in un momento in cui la maggior parte dei contenuti su Internet era statica e non specifica dell'utente e quindi il caching era molto efficace. Ma anche molti anni dopo i proxy trasparenti (cioè nessuna configurazione esplicita necessaria) venivano ancora utilizzati nelle reti mobili.

Un altro caso di utilizzo importante e anticipato sono i proxy nelle aziende. Questi sono usati per limitare l'accesso e anche ancora usati per il contenuto nella cache. Sebbene molti firewall perimetrali impieghino proxy trasparenti in cui non è necessaria alcuna configurazione, i classici gateway web sicuri di solito hanno almeno la capacità di richiedere un accesso proxy esplicito (non trasparente). Di solito non tutto il traffico viene inviato attraverso il proxy, cioè il traffico interno è solitamente escluso con qualche configurazione esplicita o utilizzando un file PAC che definisce il proxy in base all'URL di destinazione. Un proxy comunemente usato in quest'area è il proxy Squid gratuito che fornisce ACL estesi, cache distribuita, autenticazione, ispezione del contenuto, intercettazione SSL ecc.

L'uso di un proxy esplicito per il filtraggio ha il vantaggio che può essere richiesta l'autenticazione in-band contro il proxy, ovvero l'identificazione dell'utente per nome utente invece dell'indirizzo IP sorgente. Un altro vantaggio è che la connessione dal client termina con il proxy e il proxy inoltra solo la richiesta al server indicata nella richiesta proxy HTTP se il controllo ACL è corretto e forse dopo aver riscritto parti della richiesta (come assicurarsi che l'intestazione Host corrisponde effettivamente all'host di destinazione). Contrariamente a questo in linea-IDS / IPS (che è la tecnologia di base in molti NGFW) l'impostazione della connessione dal client è già inoltrata al server finale e i controlli ACL vengono eseguiti in base all'intestazione Host , che potrebbe o meno abbinare l'indirizzo IP al quale il client si sta connettendo. Questo è effettivamente utilizzato da alcune comunicazioni C2 malware per ignora il blocco o il rilevamento rivendicando un host autorizzato nell'intestazione Host ma avendo in realtà una destinazione diversa come indirizzo IP.

Alcuni esempi come segue:

• Per abilitare una regola del firewall come "server proxy a qualsiasi destinazione su 80, 443" anziché "qualsiasi interno a qualsiasi esterno"
• Per monitorare tutti i siti web visitati tramite i log
• Per controllare, limitare, filtrare i siti web visitati applicando le regole - questi potrebbero essere elenchi di siti approvati, siti in lista nera, categorie di contenuti ecc.
• Per rafforzare l'autenticazione dell'utente per utilizzare Internet - ad es. limitando agli utenti del dominio, i titolari di certificati
• Potresti avere punti di uscita separati per diversi contesti se sei su VPN, in ufficio locale, su workstation, su un server

Per la ragione "originale", ripensa al 1993, quando è stato rilasciato Netscape 0.9. Aveva una finestra di dialogo Opzioni "Mail and Proxies" (per una copia del manuale ). A quel tempo, la maggior parte dei collegamenti Internet era di 56 kbit o linee T1 frazionarie tra campus universitari e governo. Esistevano diversi modi in cui un proxy HTTP poteva essere d'aiuto o addirittura richiesto:

• Il browser Web potrebbe essere su una LAN TCP / IP senza instradamento (a livello IP) su Internet, ma con un host dual-homed su quella LAN e Internet. L'host dual-homed può eseguire un servizio proxy HTTP e un servizio proxy DNS, consentendo ai client sulla LAN di accedere al Web. (Si noti che le RFC descrivono gli intervalli di indirizzi privati standard e NAT, RFC 1597 e RFC 1631 , non sono stati pubblicati fino a marzo e maggio del 1994.)
• Anche se la LAN aveva indirizzi instradabili, o anche dopo che il NAT era stato distribuito, la larghezza di banda fuori sito era probabilmente molto inferiore alla larghezza di banda locale tra i client e una potenziale posizione proxy. Finché i client stavano esplorando una quantità significativa dello stesso contenuto statico o che cambiava lentamente, il proxy ha reso le cose migliori per i client (restituendo rapidamente il contenuto memorizzato nella cache) e l'operatore di rete (liberando la larghezza di banda per altri funzioni di rete o riduzione dei costi per l'utilizzo dei dati quando la fatturazione era per pacchetto o per byte).
• Se un numero sufficiente di utenti finali era dietro ai proxy, ha preso il bordo di quello che 10 anni dopo sarebbe stato chiamato "effetto Slashdot": i server di origine per i contenuti più diffusi in tutto il mondo dovrebbero solo servirlo a ciascun proxy, non a ciascuna estremità utente.

Ovviamente, l'invio di tutto il traffico HTTP attraverso un processo designato rende anche quel processo un buon punto di controllo per l'applicazione della politica di sicurezza: filtraggio per parole chiave nella richiesta (decodificata) o nel corpo della risposta; consentendo solo l'accesso agli utenti che si autenticano al proxy; registrazione.

Sì, ci sono organizzazioni che "spingono" una politica di proxy verso i dispositivi degli utenti finali che controllano e la applicano con una politica restrittiva ai router di frontiera.

Nota anche che anche se pensi di navigare su una rete "pulita", il tuo traffico potrebbe passare attraverso un proxy; vedi ad esempio il Proxy trasparente con Linux e Squid mini-HOWTO .

Ma è vero che un proxy configurato in modo esplicito può dare poco vantaggio o addirittura peggiorare la navigazione su Internet di oggi. Quando i siti Web più diffusi utilizzano CDN e la maggior parte dei contenuti è dinamica, anche i contenuti che potrebbero essere memorizzati nella cache (come le tessere di Google Maps e i dati video di YouTube) variano a seconda della versione del browser, del sistema operativo, delle dimensioni dello schermo o persino di un cookie casuale < em> significa per renderlo non memorizzabile, il caching salva poca larghezza di banda per una cache vicino all'utente finale (sebbene i server di origine abbiano spesso cache di fronte a loro). Per il contenuto non memorizzabile, un'altra cache aggiunge RTT a ogni richiesta, rendendo la navigazione più lenta.

Sì, sono frequentemente usati nel mondo aziendale. Forse meno adesso rispetto al passato, ma anni fa erano comunemente l'unico gateway da una rete locale a Internet. In molti casi, solo alcuni utenti del dominio sono stati autorizzati ad accedere a Internet e un server proxy come ISA sarebbe stato configurato sul bordo della rete e gli utenti avrebbero dovuto autenticarsi per attraversarlo.

Oltre a limitare semplicemente chi può accedere a Internet, questo è stato effettivamente utilizzato per il filtraggio dei contenuti, l'ispezione dei contenuti e la segnalazione di chi stava spendendo tutto il proprio tempo di lavoro alla ricerca di nuovi posti di lavoro su Monster.com. C'erano anche altre funzioni non legate alla sicurezza, come il caching. 20 anni fa non era raro avere centinaia o anche diverse migliaia di persone in una struttura connessa a Internet usando una pipa relativamente piccola come un T-3 frazionato o persino un T-1. È stato molto utile poter memorizzare nella cache il contenuto sul bordo della rete locale, quindi la larghezza di banda molto limitata che il mondo esterno non era saturo di richieste ripetute per le stesse risorse.

L'accesso alla rivista accademica è spesso limitato e talvolta parte della restrizione è l'indirizzo IP. Usando il server proxy della mia università (che richiedeva un login valido) potevo accedere alle riviste mentre lavoravo da casa (il tempo passato solo perché non l'ho provato per un paio d'anni). Potrei impostarlo solo per i siti web di editori di riviste o utilizzare un'estensione di cambio proxy in Firefox.

In threery avrei potuto usare la VPN universitaria, ma qui richiede un programma client che non funzioni su Linux (figuriamoci sul mio Chromebook). Una VPN precedente richiedeva molte regole di impostazione in un'interfaccia utente stupida per far funzionare le cose di base (come qualsiasi email non gestita da loro).

Inoltre, ci sono casi d'uso per controllare il traffico HTTP non-browser :

Le funzionalità di aggiornamento automatico e "phoning home" nelle applicazioni desktop possono essere in misura controllate lasciando che i browser web reali basati su carne utilizzino un proxy che è meno restrittivo rispetto a ciò che l'infrastruttura di rete consente per impostazione predefinita.

Allo stesso modo, i server possono essere controllati - mentre ci sono alcuni processi su un server che creano traffico di eVage legittimo, consentendo a tutti gli eVirus di essere più utili a qualcuno che tenta di sabotare / sabotare il server. Inoltre, ha spesso senso document tutto il traffico di uscita del server (che un proxy può fare).

Inoltre, le reti a bassa larghezza di banda (ad es. satphone o umts) che richiedono di risparmiare larghezza di banda utilizzano spesso proxy per ricodificare immagini di grandi dimensioni e altri contenuti multimediali che non saranno utili nel formato ad alta risoluzione e ad alto traffico, specialmente sui dispositivi mobili dispositivi.