Thanks for the perspective on this, folks. Going back to the technical stuff—and this isn’t really a squid thing—but is there any way I can minimise this using my DNS server? Can I force my local DNS to only ever return 1 address from the pool on a hostname I’m having trouble with? > On 30 Oct 2015, at 4:50 AM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
