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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
