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