[squid-users] https proxy authentication

[Amos Jeffries]

On 11/04/18 02:07, Adam Weremczuk wrote:
> Hi Amos,
> 
> 
> On 30/03/18 02:44, Amos Jeffries wrote:
>> So, the big question is why you have this setup of Apache being a
>> reverse-proxy for a Squid forward-proxy?
>>
>> Forward-proxy are supposed to be between clients and reverse-proxies or
>> origins. Not the other way around.
> This is a set up I inherited with not much being documented.
> I think the purpose was to split the functionality as below:
> - direct unauthenticated proxy for every day usage ("proxy")
> - hopping through Apache which provides http authentication for sporadic
> testing use only ("aproxy")

You may want to double-check that and redesign how the proxy is used.
Squid can easily do things like receive traffic on multiple IP:port and
selectively perform authentication only for traffic arriving in one.


>> What are you actually trying to achieve here?
> The big picture is we need to test some code against various proxy
> scenarios (http, https, authenticated, unauthenticated).
> ATM we only have http authentication.
> I would imagine real live proxy setups use encrypted https for
> authentication more often than plain text http.
> Am I correct with my assumption?

No. Actually the preferred HTTP authentication schemes do not send any
confidential things in-channel over the network, so do not require HTTPS
protections.

The Basic and Digest auth schemes which could have benefited normally
have to be sent unprotected over TCP instead.


( Ironically that sad situation is due to the Browser developers behind
a certain "TLS/HTTPS everywhere" campaign refusing for _decades_ to
implement TLS to proxies. Directly counter to our campaign to get them
to use TLS where it is actually most needed. )


> 
> If that's the case then my goal is to get https authentication working
> as well.
> If there is no way I can easily get it to work with the existing config
> I guess I can set up a new Apache hop.
> Authenticating over https only and called e.g. "bproxy".
> Would that make most sense?
> 
> Thanks
> Adam


I think what you are wanting is something like below. Then you just need
your testing to send traffic to the right port:

 # reverse-proxy HTTP
 http_port 80 accel
 acl port80 myportname 80

 # forward-proxy HTTP
 http_port 3128
 acl port3128 myportname 3128

 # reverse-proxy HTTPS
 https_port 443 accel cert=...
 acl port443 myportname 443

 # forward-proxy TLS-explicit
 https_port 8443
 acl port8443 myportname 8443

 auth_param ... your auth setup
 acl auth proxy_auth REQUIRED

 acl noauth ... something to determine non-auth testing.

 # ... http_access rules testing things that do not require auth

 # emulate the "deny all" ending the non-auth checks
 http_access deny noauth

 # requires auth ...
 http_access deny !auth

 # ... rules testing things that require auth credentials.


Depending on what you want your test proxy behaviour to be you can
wrangle up some very cool behaviours with the any-of and all-of ACL
types in recent versions, or various lists of ACLs following one of the
port name ones.

Amos