Protocollo PROXY di Squid: fidarsi del mittente prima dei controlli di accesso HTTP

Usate proxy_protocol_access per fidarvi del relay che fornisce i metadati, non per scegliere i siti web consentiti. In Squid 5–7 il controllo viene eseguito una volta dopo l'instaurazione del TCP su un listener require-proxy-header, prima che le intestazioni della richiesta HTTP vengano elaborate:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

Sostituite l'indirizzo del relay dell'esempio e limitate l'accesso di rete a questo listener. In questa fase Squid controlla il peer TCP effettivo prima di accettare i metadati forniti. Dopo l'accettazione usa l'indirizzo client dichiarato per i successivi controlli ACL e per la registrazione. Fidarsi di un relay in base all'indirizzo client che dichiara invertirebbe questo ordine.

Riservate http_access alle successive autorizzazioni per l'origine client e la destinazione. Accettare i metadati non autorizza l'accesso ai siti web, e un'ACL del dominio di destinazione non può rispondere alla domanda precedente sulla fiducia nel mittente.

Mittente e destinatario devono concordare una versione supportata del protocollo PROXY. Un client HTTP semplice non può usare questo listener con prefisso obbligatorio come normale endpoint proxy. Se servono entrambe le forme, usate deliberatamente endpoint separati invece di duplicare lo stesso indirizzo di ascolto e la stessa porta.

Un relay fidato può influenzare l'autorizzazione basata sull'indirizzo tramite l'identità client che fornisce. Concedete questa capacità solo all'intermediario previsto.