Re: [SQU] Credentials forwarding?

From: Robert Collins <robert.collins@dont-contact.us>
Date: Mon, 18 Dec 2000 18:13:27 +1300

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
> Robert Collins wrote:
>
> > I think the configuration warning is needed. I can easily imagine a
naive
> > admin turning on upstream authentication and exposing all their OS
passwords
> > to their ISP :[
>
> There is a note that should make most people grip that:
>
<snip>>
> But sure, we can add a more explicit warning if you thing that is
> neccesary..

I think the explicit warning is needed. Sharing a user database != passing
clear text passwords around the net. The warning from my patch email (or in
the auth_rewrite branch cf.data.pre) was clear enough for me. The bit about
the shared user database is needed as well though.

>
> As I said authentication in accelerators is an unofficiall thing not
> really supported. There are too many alternatives on how one would like
> to have it function in an accelerator, and it too easily collides with
> transparent proxies which do look like accelerators to Squid.. So until
> a couple wanting the feature in accelerators comes up with good
> definitions of how they want things handled I opt to ignore the issue of
> authentication in accelerators.

k. I see the point. I expect we'll hear some screams though when the headers
go upstream with the response to squid generated challenges.

>
> However, the same basic problems does apply to proxy authentication, and
> is why a generic approach should be made to make Squid eat
> authentication headers that belongs to it's own challenge/response
> processing, and optionally add a custom connection header for passing on
> the (decoded) user information to the next hop (parent proxy or
> accelerated server, same thing actually).

I've been thinking about this for a while. I wrote a message in repsonse to
kinkie suggesting a new header (X-Squid-credentials or something). Have a
look in the squid-users mailing list. Does that line up with what you are
thinking?

There is another alternative, which is to NOT generate challenges if the
request is going to an upstream server we are sharing auth headers with. Let
them generate the challenge, (perhaps passing the challenge details to us on
a hopbyhop header), and then just check the credentials in the response.
Personally I like the signed header with the decoded username myself.

>
> Regarding acceleration.. I think the whole concept of how Squid is set
> up for accelerators needs to be reworked. There are way to many pitfalls
> and gotchas in the current way, and it collides to much with transparent
> proxying.

Sure. I'll skip thinking about this for a while yet. (not enough time).
Received on Sun Dec 17 2000 - 22:20:22 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:05 MST