On 10/29/2015 11:29 AM, Matus UHLAR - fantomas wrote: >> On 10/28/2015 10:46 PM, Amos Jeffries wrote: >>> NP: these problems do not exist for forward proxies. Only for traffic >>> hijacking interceptor proxies. > > On 29.10.15 09:05, Alex Rousskov wrote: >> For intercepted connections, Squid should, with an admin permission, >> connect to the intended IP address without validating whether that IP >> address matches the domain name (and without any side effects of such >> validation). In interception mode, the proxy should be as "invisible" >> (or as "invasive") as the admin wants it to be IMO -- all validations >> and protections should be optional. We could still enable them by >> default, of course. >> >> SslBumped CONNECT-to-IP tunnels are essentially intercepted connections >> as well, even if they are using forwarding (not intercepting) http_ports. > the "admin permission" is the key qestion here. Agreed. And understanding of what giving that permission implies! > There's possible problem > where the malicious client can connect to malicious server, ask for any > server name and the malicious content could get cached by squid as a proper > response. Very true, provided that Squid trusts the unverified domain name to do caching. Squid does not have to do that. As Amos have noted, there are smart ways to minimize most of these problems, but they require more development work. IMHO, it is important to establish the "do no harm" principle first and then use that to guide our development efforts. Unfortunately, some of the validation code was introduced under different principles, and we may still be debating what "harm" really means in this context while adjusting that code to meet varying admin needs. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
