Send modauthtkt-users mailing list submissions to
modauthtkt-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of modauthtkt-users digest..."
Today's Topics:
1. Re: [Patch] Allow use behind mod_proxy (Gavin Carr)
2. Re: [Patch] Allow use behind mod_proxy (Michael Peters)
3. Re: [Patch] Allow use behind mod_proxy (Charlie Brady)
4. Re: [Patch] Allow use behind mod_proxy (Gavin Carr)
5. Re: [Patch] Allow use behind mod_proxy (Charlie Brady)
6. Re: [Patch] Allow use behind mod_proxy (Gavin Carr)
7. Migrating to Apache 2.2? Include mod_authz_user! (Joost Cassee)
8. Re: [Patch] Allow use behind mod_proxy
(Garrett, Philip (MAN-Corporate))
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Nov 2006 09:16:49 +1100
From: Gavin Carr <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Mon, Nov 06, 2006 at 10:14:35AM -0500, Charlie Brady wrote:
>
> On Mon, 6 Nov 2006, Gavin Carr wrote:
>
> >On Fri, Nov 03, 2006 at 12:11:37PM -0500, Charlie Brady wrote:
> >>Use X-Forwarded-Host header in preference to Host header, if available.
> ...
> >No, mod_auth_tkt shouldn't need to know about being proxied. The
> >redirect should get rewritten by a ProxyPassReverse on the way back
> >through. Is that not working for you?
>
> No - the redirect URL is OK but the back URL isn't rewritten:
Ah okay. To rewrite this dynamically you want mod_proxy_html:
http://apache.webthing.com/mod_proxy_html/
Cheers,
Gavin
------------------------------
Message: 2
Date: Mon, 06 Nov 2006 17:20:44 -0500
From: Michael Peters <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Gavin Carr wrote:
> Ah okay. To rewrite this dynamically you want mod_proxy_html:
>
> http://apache.webthing.com/mod_proxy_html/
Wow, that's a serious hit (parsing every outgoing HTML response) and would need
to be used by anyone using mod_auth_tkt behind mod_proxy. And what if they're
not using mod_proxy but some other proxy mechanism (squid, lighttpd)? Also, what
happens if the request isn't for an HTML resource (an image or PDF document,
etc)? Also, does mod_proxy_html handle URL encoded values (like a back url in a
link)?
I'd actually be in favor of this small change to mod_auth_tkt to make it proxy
aware.
--
Michael Peters
Developer
Plus Three, LP
------------------------------
Message: 3
Date: Mon, 6 Nov 2006 17:41:13 -0500 (EST)
From: Charlie Brady <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 6 Nov 2006, Michael Peters wrote:
> Gavin Carr wrote:
>
>> Ah okay. To rewrite this dynamically you want mod_proxy_html:
>>
>> http://apache.webthing.com/mod_proxy_html/
>
> Wow, that's a serious hit ...
My thought entirely.
> I'd actually be in favor of this small change to mod_auth_tkt to make it proxy
> aware.
Unless there really is a security risk. Gavin?
------------------------------
Message: 4
Date: Tue, 7 Nov 2006 10:56:52 +1100
From: Gavin Carr <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Mon, Nov 06, 2006 at 05:41:13PM -0500, Charlie Brady wrote:
> On Mon, 6 Nov 2006, Michael Peters wrote:
> > Gavin Carr wrote:
> >
> >> Ah okay. To rewrite this dynamically you want mod_proxy_html:
> >>
> >> http://apache.webthing.com/mod_proxy_html/
> >
> > Wow, that's a serious hit ...
>
> My thought entirely.
>
> > I'd actually be in favor of this small change to mod_auth_tkt to make it
> > proxy
> > aware.
>
> Unless there really is a security risk. Gavin?
Hmmm, black hat on.
Trusting HTTP headers clearly is a security risk, since they're under the
control
of a potentially malevolent user. So it's bad practice if we can avoid it. (In
the
real world, of course, we might not be able to, or the gain might be worth the
additional risk.)
Having said that, I can't come up with attack vectors for either item under
discussion. Can you check my thinking here:
1. Defaulting TKTAuthDomain - Charlie's patch essentially just defaults
TKTAuthDomain
if unset, which is used when refreshing tickets or issuing timeout cookies.
We
don't and can't authenticate the ticket domain anyway, because it's a
client-side
thing - we never actually see it. So there's nothing to stop a user
repurposing a
ticket for another domain anyway. All the checks on the mod_auth_tkt side
rely on
you having separate secrets for domains you want to keep logically distinct.
So
using X-Forwarded-For or Host headers here actually doesn't add anything the
user
can't already do anyway.
2. Creating back links - we build a back URL when we redirect so that
authentication
pages can optionally redirect back to the initially requested page. At the
end of
the day the back link is just another URL, with no special trust status - the
request still has to go through the standard authentication process i.e.
spoofing
the domain here is no different to typing the url in directly, and gains you
nothing.
Does that all look sane? Have I missed anything here?
If not, I think I've convinced myself neither actually constitute a risk at all.
So barring objections, I think I'll apply them.
Cheers,
Gavin
------------------------------
Message: 5
Date: Mon, 6 Nov 2006 23:15:12 -0500 (EST)
From: Charlie Brady <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 7 Nov 2006, Gavin Carr wrote:
> 1. Defaulting TKTAuthDomain - Charlie's patch essentially just defaults
> TKTAuthDomain
> if unset, which is used when refreshing tickets or issuing timeout cookies.
> We
> don't and can't authenticate the ticket domain anyway, because it's a
> client-side
> thing - we never actually see it. So there's nothing to stop a user
> repurposing a
> ticket for another domain anyway. All the checks on the mod_auth_tkt side
> rely on
> you having separate secrets for domains you want to keep logically distinct.
That brings me to my other question - is there any reason that AuthSecret
couldn't be per-directory?
> Does that all look sane? Have I missed anything here?
>
> If not, I think I've convinced myself neither actually constitute a risk at
> all.
> So barring objections, I think I'll apply them.
I haven't thought of anything yet.
In many cases where a proxy is used, all queries will come via the proxy
(and can be constrained as such by access lists). So we should be able to
trust the most recently added X-Forwarded-Host header. Is there defined
behaviour if there is already such a header in the request?
I've also just discovered the ProxyPreserveHost directive in apache
documentation. "ProxyPreserveHost on" with mod_proxy would have solved
part of the problem, but I think we are better off with the patches.
---
Charlie
------------------------------
Message: 6
Date: Tue, 7 Nov 2006 15:39:23 +1100
From: Gavin Carr <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Mon, Nov 06, 2006 at 11:15:12PM -0500, Charlie Brady wrote:
>
> On Tue, 7 Nov 2006, Gavin Carr wrote:
>
> > 1. Defaulting TKTAuthDomain - Charlie's patch essentially just defaults
> > TKTAuthDomain
> > if unset, which is used when refreshing tickets or issuing timeout
> > cookies. We
> > don't and can't authenticate the ticket domain anyway, because it's a
> > client-side
> > thing - we never actually see it. So there's nothing to stop a user
> > repurposing a
> > ticket for another domain anyway. All the checks on the mod_auth_tkt side
> > rely on
> > you having separate secrets for domains you want to keep logically
> > distinct.
>
> That brings me to my other question - is there any reason that AuthSecret
> couldn't be per-directory?
No, there isn't. It's primarily a legacy thing, though it seems to be the
way most people use it. It will probably stay per-host for backwards
compatibility reasons, but we've talked about adding a TKTAuthDirSecret
directive that would take precedence. No one's done implemented it yet
though.
> > Does that all look sane? Have I missed anything here?
> >
> > If not, I think I've convinced myself neither actually constitute a risk at
> > all.
> > So barring objections, I think I'll apply them.
>
> I haven't thought of anything yet.
>
> In many cases where a proxy is used, all queries will come via the proxy
> (and can be constrained as such by access lists). So we should be able to
> trust the most recently added X-Forwarded-Host header. Is there defined
> behaviour if there is already such a header in the request?
Yes, they're cumulative, and ordering must be retained. They may be
represented either as a single header containing a comma-separated
list, or as multiple headers (per RFC 2616 s4.2).
> I've also just discovered the ProxyPreserveHost directive in apache
> documentation. "ProxyPreserveHost on" with mod_proxy would have solved
> part of the problem, but I think we are better off with the patches.
I didn't know about that one either. So that would address the
X-Forwarded-For part, but you'd still need to accept Host headers.
As you say, not that much of a gain.
Cheers,
Gavin
------------------------------
Message: 7
Date: Tue, 07 Nov 2006 10:50:59 +0100
From: Joost Cassee <[EMAIL PROTECTED]>
Subject: [modauthtkt-users] Migrating to Apache 2.2? Include
mod_authz_user!
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Just a warning to those who want to migrate to Apache 2.2. Do not forget
to include mod_authz_user, or you will not be able to use Require
valid-user!
I hope this will save you a few ours debugging... :-(
- Joost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 542 bytes
Desc: OpenPGP digital signature
Url :
http://sourceforge.net/mailarchive/forum.php?forum=modauthtkt-users/attachments/20061107/3bb54189/attachment.bin
------------------------------
Message: 8
Date: Tue, 7 Nov 2006 09:22:50 -0500
From: "Garrett, Philip \(MAN-Corporate\)" <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] [Patch] Allow use behind mod_proxy
To: "Gavin Carr" <[EMAIL PROTECTED]>,
<modauthtkt-users@lists.sourceforge.net>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Gavin Carr wrote:
[snip]
>>
>> That brings me to my other question - is there any reason that
>> AuthSecret couldn't be per-directory?
>
> No, there isn't. It's primarily a legacy thing, though it seems to be
> the way most people use it. It will probably stay per-host for
> backwards compatibility reasons, but we've talked about adding a
> TKTAuthDirSecret directive that would take precedence. No one's done
> implemented it yet though.
Would it break backwards compatibility to accept the secret at multiple
levels with the same AuthSecret param?
Regards,
Philip
------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------
_______________________________________________
modauthtkt-users mailing list
modauthtkt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
End of modauthtkt-users Digest, Vol 6, Issue 6
**********************************************
