[squid-users] Configuration assistance

[Amos Jeffries]

On 15/04/2015 4:25 a.m., HiP-HiPpO wrote:
> Hello-
> 
>   I'm using squid version 3.5.3 and I could use some help with
> configuration.

First up, lets be clear: This is going to be difficult.

The Apache setup you had appears to have been severely violating the
HTTP *and* HTTPS protocols security requirements.

You *will* have different behaviour from one endpoint or the other just
by not using Apache.


> 
>   Squid will be installed at AWS, most clients will be within a corporate
> network and will not be able to access the service by configuring proxy
> settings in a browser.

NOTE: That logic is false.

 Corporate networks / LAN are *the* use-case which is best suited to
explicit browser configuration. You have AD policy, WPAD DHCP, WPAD DNS,
user login scripts ror batch jobs, etc available to push out the
settings. Other use-cases do not have some of those options, or they do
not work as well as in a LAN environment.


>  Instead DNS will be used to resolve to the Squid
> service.  The Squid service will authenticate users via SLDAP.  The
> service will need to be able to intercept both clear and TLS HTTP traffic
> in order to insert an Authorization header.

At first reading this makes no sense. But what you go on to describe is
in fact a reverse-proxy.

SO.. forget the word "intercept", it has nothing to do with what you
have set up.

> 
>   The request flow would be something like;
> 
> Client browser requests http(s)://proxy-hostX.test.com
> (where 0 < X < 50)
> 
> Squid will need to intercept the request and add an Authorization header.

Okay, ignoring the word "intercept", what you have here is just a proxy
that performs login to some backend service(s).

Fairly standard, though you have not said what authentication scheme the
backend is using. That is an important detail.


> Squid will need to rewrite the request to the origin server.  In this
> case, the origin server name is hostX.test.com
> 
> Squid will then intercept the server response and direct that response to
> an ICAP server to modify all embedded links to be the same as the
> request.  All links in the response will need to be rewritten to
> http(s)://proxy-hostX.test.com


This is where you start to have problems. Still ignoring the word
"intercept", you have a proxy that uses ICAP adaptation to re-write both
requests and response, mapping public URI resources to some essentially
completely different private/intenral resoruce URIs.

This ICAP part is very difficult, complex, and has nothing to do with
Squid. So what it (ICAP) actually does to the traffic is not relevant
here. In squid.conf you just need both a REQMOD and RESPMOD service
configured. ICAP service does all the complex bits.

NOTE: be aware that mapping between http:// and https:// scheme is
expressly forbidden by both HTTP and HTTPS specifications. The security
vulnerabilities introduced by doing so are extremely dangerous and have
many unknowable side-effects. You need to be careful that ICAP service
used does not cause it to happen.

> 
> I have official wildcard certificates for the domain.  i.e. *.test.com
> 


> Squid will also need to retrieve group memberships from SLDAP and authorize
> user access to hostX based on group memberships.  If the user is in the
> groups host30 and host43, then access is allowed to only host30.test.com
> and host43.test.com

The SLDAP part for finding group details and adding auth to the backend
is pretty standard. Some limits apply, but pretty easy to do.

BUT ... How do you determine which user made which request?

The usual way is for clients to perform HTTP login to Squid. Anything
else gets much harder, particularly for reverse-proxy.


So, taking note of the fixed terminology I supplied above the wiki
config examples should now be more useful to you:

You have a reverse-proxy doing virtual hosting
(<http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting>)
also in HTTPS with wildcard certificate
(<http://wiki.squid-cache.org/ConfigExamples/Reverse/SslWithWildcardCertifiate>)
to multiple backend servers
(<http://wiki.squid-cache.org/ConfigExamples/Reverse/MultipleWebservers>).

You have ICAP services performing REQMOD and RESPMOD traffic adaptation:
 <wiki.squid-cache.org/Features/ICAP>

You are performing some form of user identification, with group access
controls
(<http://wiki.squid-cache.org/ConfigExamples/Authenticate/Groups>),
followed by authentication to the backend servers
(<http://www.squid-cache.org/Doc/config/cache_peer/> see login=
authentication options).


HTH
Amos