[squid-users] Non intrusive sslbump for whitelisting (asked many times but..)

[Amos Jeffries]

On 11/11/17 01:05, A. Benz wrote:
> Hi Amos,
> 
> Thanks for your continued support.
> 
> 1.
> 
>> Do you mean the VPN exit point has that 10/8 IP address? or that the 
>> traffic from the client is altered to be going to that IP before it 
>> reaches Squid?
>>
>> The latter is broken because it destroys the original dst-IP values on 
>> the TCP connection. Which Squid needs to setup the server connection. 
> 
> Let me put it as an example:
> 
>  From the normal internet: mail.amosprivateserver.org > publicly 
> accessible IP.
> 
>  From my place: mail.amosprivateserver.org > 10.x.x.x (corporate 
> network, accessible only from within the place).
> 
> Anyways no worries about this! I decided to make an exception in the 
> redirect rule, so that if the outgoing traffic matches the IP 10.x.x.x 
> then the firewall will not redirect the traffic to squid and instead 
> establish a connection directly.
> 
> This is not ideal, but it works.
> 

Or have Squid relay everything through the same server(s) and
the server do the distinguishing between traffic and just relay 
everythign to the same


> 
> 2.
> 
>> If for any reason those firewall rules change in unexpected ways or 
>> don't block something you expect to be blocked this may leave a 
>> security hole open. It does not seem to be necessary really, so best 
>> to close. 
> 
> But if I put the lines you told me:
> 
> # http_access allow SSL_ports (commented out as you advised)
> http_access deny !localnet
> 
> Then I can't get any https work per my whitelist (google for example 
> complains of HSTS..etc) There must be another thing messed up in my 
> config then?
> 

Seems so.

> 
> 3.
> 
>> The point I was trying to emphasize is that your Squid is accepting 
>> *anything* in those port 443 connections. 
>>
>> HSTS requires a header "Strict-Transport-Security" to be delivered 
>> from servers before it takes effect. You can erase that header from 
>> replies going through Squid with the reply_header_access directive. 
>> Current Squid should be doing it automatically.
>> There may be issues with HSTS if the header is received before the 
>> device connects to your network, or if it arrives over an uncontrolled 
>> CONNECT tunnel. But there is not much to be done about those cases. 
> I'm not sure I follow (please bare with me!), see I'm simply trying to 
> prevent abuse by only allowing connections to whats in whitelist, is my 
> approach in my current config doing that? If there's a better way please 
> tell me. This is going over a satellite connection with extremely poor 
> latency and bandwidth, so Squid's job is to stop the connections from 
> reaching out, and only allowing whats in whitelist.
> 

HSTS is enabled on if the client receives a header called 
"Strict-Transport-Security". And only for a time indicated by the header 
itself.

So removing that header prevents HSTS being turned on in the client.

However the client can receive that header via any one of several 
different protocols (eg. HTTP/2, SPDY, QUIC, and HTTPS if you are 
splicing any of it). So preventing HSTS breaking things randomly 
requires they be blocked and only the filtered traffic allowed.

> 
> 4.
> 
>> That means the server that HTTPS connection is attempting to reach is 
>> not on your whitelist. It is therefore one of the things you wanted to 
>> be blocked according to your stated policy.
>>
>>  - as I mentioned earlier, if that causes any issues your whitelist is 
>> incomplete. 
> But it is, eg whitelist.txt has .google.com, shouldn't google.com be 
> accessible then (without complaining about HSTS, since I'm splicing?). 


Splicing allows traffic to go through without the HSTS header removal. 
So the above (3) issues from HSTS maybe still happening.


As a general rule of thumb, if you are splicing a domain never bump it 
and if you are wanting to bump it never splice it nor allow any other 
ways to reach it except through the bumping proxy.

It is technically possible to transition a domain from being 
spliced/relayed to bumped, but it can be a painful process involving a 
lot of unavoidable TLS related "errors" for clients during the 
transition timeout dictated by the HSTS header and/or similar things.


As to the whitelist 'not working'. Earlier you posted a access.log entry 
that contained:

  1510180110.096      0 192.168.1.178 TCP_DENIED/200 0 CONNECT
    108.177.14.103:443 - HIER_NONE/- -

Note how that IP address is *not* a domain in *.google.com.
Even its reverse-DNS does not match *.google.com.

Googles rDNS server names are in *.1e100.net domain, not *.google.com. 
They also have a lot of other service name crossovers like "YouTube" 
actually being *.googlevideos.com, and gmail actually being 
docs.google.com sometimes (heh!).


To access any service with SSL-Bump your whitelist needs to allow its 
public domain name(s), reverse-DNS server name(s), and maybe also raw-IP 
address(s). That goes for any service, not just Google's.


And ... that rule of thumb I mention above applies to the entire bunch 
as a collective service. That is where major corps like Google cause 
headaches simply by having so many inter-related pieces with crossover 
like gmail and youtube domains vs the 1e100.net reverse-DNS.


Amos