[squid-users] Squid, Gmail.com and HSTS.

[Amos Jeffries]

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