On 28/05/2015 5:51 a.m., Michael Monette wrote: > Thanks for the reply. I am compiling the latest squid now and going to give that a shot using ssl::server_name. The precompiled binary for CentOS was only at 3.5.04 and didn't have ssl::server_name support I guess. > > While I have you here, I was thinking of something else I could do. Tell me if you think it would work. You seem like an expert. > I'm the Squid maintainer. On this feature I'm just an interested party, the real expert is Christos Tsantilas who authored it. > Can I not make it so www.gmail.com resolves to (for example) 1.2.3.4 using DNS or a hosts file, then setup an acl like this: > > acl gml dst 1.2.3.4 > # Redirect request for 1.2.3.4 to https://mail.google.com > deny_info https://mail.google.com gml > # Not even sure what this does, found it on a website, didn't really question it since things were working as they were supposed to. > http_reply_access deny bl1 This acts on the HTTP messages inside the TLS wrapper after SSL-Bump has decrypted the connection and the request has been sent through to the server. By replacing whatever reply the server actually sent with a 302 status diverting the client to that URL. It has no effect on the bumping process itself or any of the TLS layer details. It may have an effect on HSTS since any headers the server might send are dropped by the 302 replacement. > > This way it doesn't have to monitor for a dstdomain, it watches for an IP. It wastes bandwidth sending a request to the server and fetching the reply. Given that the dst-IP address is what you have from the very first TCP packet onwards. About the only utility it has over http_access is that its positioning naturally restricts it to the decrypted traffic where the 302 will always work. But by that time you have the domain name from the encrypted HTTP message anyway. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
