https proxy authentication

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

https proxy authentication

Adam Weremczuk

Hi all,

I have a solution in place with a dedicated squid LXC container (v 3.1.20-2.2).
Both http and https proxy run on default port 3128.
Https in tunneled in http using CONNECT.
There is no authentication in place and both are working fine.

For testing purposes we also use an Apache (v 2.2.22-13) proxy forwarder running on a different machine on port 80 as "aproxy".

Config below:

# Authenticated proxy for testing purposes
# We forward http/s requests to the local proxy server
ProxyRequests On
ProxyVia On
ProxyRemote http http://proxy.example.internal:3128
ProxyRemote https http://proxy.example.internal:3128
ProxyDomain .example.internal
NoProxy .example.internal 192.168.x.x/22
<Proxy *>
   Order Deny,Allow
   Deny from all
   Allow from 192.168.x.x/22
   AuthType Basic
   AuthName ProxyAuth
   AuthUserFile /etc/apache2/proxypasswd
   Require valid-user
</Proxy>

This is working as expected for http requests:

1. Unauthenticated (failure):

$ http_proxy=http://aproxy:80
$ wget http://example.com 2>&1 | grep response
Proxy request sent, awaiting response... 407 Proxy Authentication Required

2. Username with password (success):

$ http_proxy=http://username1:password@aproxy:80
$ wget http://example.com 2>&1 | grep response
Proxy request sent, awaiting response... 200 OK

3. Username without password (success):

$ http_proxy=http://username2:@aproxy:80
$ wget http://example.com 2>&1 | grep response
Proxy request sent, awaiting response... 200 OK

My PROBLEM is I can't find a way to use authentication for proxied https requests.

From a LAN client trying to establish connection:

$ echo $http_proxy
http://username1:password@aproxy:80

$ echo $https_proxy
http://username1:password@aproxy:80

$ wget --server-response https://example.com 2>&1
--2018-03-29 15:20:44--  https://example.com/
Resolving aproxy (aproxy)... 192.168.x.x
Connecting to aproxy (aproxy)|192.168.x.x|:80... connected.
Proxy tunneling failed: Service Temporarily UnavailableUnable to establish SSL connection.

On "aproxy" only one line in apache error log (even in debug mode):

[Thu Mar 29 15:21:59 2018] [error] (111)Connection refused: proxy: CONNECT: attempt to connect to 93.184.216.34:443 (example.com) failed

Nothing is logged on squid "proxy" which is the next hop.

What's the easiest way to enable authenticated https proxying?
I don't want to enable it for our main production proxy:3128
Or maybe it's already supposed to work but I'm missing something?

Please advise.

Thanks
Adam


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: https proxy authentication

Amos Jeffries
Administrator
On 30/03/18 04:24, Adam Weremczuk wrote:
> Hi all,
>
> I have a solution in place with a dedicated squid LXC container (v
> 3.1.20-2.2).
> Both http and https proxy run on default port 3128.
> Https in tunneled in http using CONNECT.

That tunnel existing means Squid has no part in any of the HTTPS
requests. It cannot perform authentication of them.

What it can do is request authentication of the CONNECT message, but
once that is accepted or rejected Squids part is over.


> There is no authentication in place and both are working fine.
>
> For testing purposes we also use an Apache (v 2.2.22-13) proxy forwarder
> running on a different machine on port 80 as "aproxy".
>

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.


What are you actually trying to achieve here?


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: https proxy authentication

Adam Weremczuk
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")
> 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?

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
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: https proxy authentication

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users