hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrich Kraemer <henrich.krae...@us.ibm.com>
Subject Re: Preemptive authentication throws IllegalStateException using ISA proxy server
Date Mon, 17 Nov 2008 18:48:54 GMT
See comments below.

Thanks,
Henrich


Oleg Kalnichevski <olegk@apache.org> wrote on 11/12/2008 02:14:33 AM:

> On Tue, 2008-11-11 at 10:32 -0800, Henrich Kraemer wrote:
> > > What for? As long as the connection is reused the overhead of an
extra
> > > request/response round trip is negligible (at least it does not
outweigh
> > > additional security risks)
> >
> > I disagree. Extra roundtrips are worth avoiding for high latency
> > connections.
> >
>
> You are very welcome to disagree.
>
>
> > It is unclear to me how much risk is added by this.
> > I am not a security expert, so these statements should be
> > taken with caution.
>
> I am no security expert either, but to me the whole idea of sending user
> credentials to an unknown host, especially in clear text, sounds like a
> complete lunacy.
>
> > - BASIC is not secure unless done over SSL. So I think one can assume
> >   that it is only offered over SSL when security matters.
> > - DIGEST is also relatively unsecure. It is not clear to me that
> >   preemptive authentication increases the risk very much. Compared
> >   to cases where each request causes a unauthorized response it
> >   might even improve security as the matching unauthorized response
> >   does not precede immediately the response.
>
> The longer nonce is reused the more vulnerable DIGEST authentication
> becomes. I do not see how this could possibly improve security.
>
> > One added risk is that the client may send Authorization headers
> > to the wrong protection space (defined in RFC 2617) and thus leaks
> > information.
> > However this risk can be eliminated if the notion of the
> > protection space is properly implemented.
> >
>
> How exactly are you suggesting this should be done?
>
>
> > >
> > > > Our app does not know ahead of time what kind of authentication is
> > > > needed for the encountered targets and proxy (if any) as these are
> > > > user configurable.
> > > >
> > >
> > > The thing is _only_ BASIC authentication scheme lends itself to
> > > preemptive authentication. Unless you are sure the target server
accepts
> > > BASIC, preemptive authentication is pretty much pointless.
> > >
> > > > With preemptive authentication enabled the extra request/response
pair
> > > > is only needed for the first request. Once the user provided
> > > > credentials HttpClient keeps the credentials in the HttpClients'
state
> > > > field. HttpClient uses these from then on as long as the same
> > > > HttpClient instance is used.
> > > > This works as described as long as:
> > > > 1. Not both the target and the proxy require authentication and
> > > > 2. The proxy is not an ISA proxy using NTLM authentication. A proxy
> > > > with digest or basic authentication does work.
> > >
> > > (Some soft of) preemptive DIGEST authentication works with HttpClient
> > > 4.0 only.
> > >
> > > > In my mind an HttpClient should understand cases when preemptive
> > > > authentication cannot be used and then ignore preemptive
> > > > authentication mode.
> > > >
> > > > Does this scenario make sense?
> > >
> > > Can it be you are confusing credentials caching and preemptive
> > > authentication?
> >
> > With preemptive authentication I mean:
> > 1. Setting the Authorization header.
> > 2. Enabling an http client application to do this when it makes sense
> > given the rules of RFC 2617.
> >
> > For DIGEST authentication this involves:
> > a. Providing the protection space for which credentials are requested.
> > b. In addition to the credentials and their protection space, the
> > app needs to know the nonce, nonce count and opaque values in order
> > to form the authorization header.
> > An authentication session is initiated by an unauthorized response
> > and updated by a subsequent Authentication-Info header received or
> > another unauthorized response with stale=TRUE.
> > Each request send increases the nonce count, which must be tracked
> > as well.
> >
> > For BASIC authentication the authentication session does not
> > carry information needed to form a preemptive authorization
> > header beyond the associated realm.
> >
> > HttpClient could choose to support both 1 and
> > 2 such that an application would only have to enable
> > preemptive authentication and the library would do all needed
> > tracking of authentication sessions.
> > I was under the impression that HttpClient 3's
> > preemptive mode does just this -- at least for BASIC
> > authentication.
> >
> > The examples given for preemptive authentication
> > for HttpClient 3 require the preemptive credentials are known in
> > advance.
>
> I do not understand. How exactly do you intend to authenticate
> preemptively without knowing credentials in advance?

One can observe this in a single firefox 3 window. Firefox asks
on the (first?) unauthorized response possibly filling in the
fields with persisted credentials for and then sends preemptive
authorization headers for requests compatible with the
protection domain.

>
> > I find this too limiting as it does not allow to implement
> > apps that implement preemptive authentication in the sense
> > mentioned as web browsers do.
> >
> > Is this a limitation of HttpClient 3?
> >
> > >
> > > > Are there better ways to avoid the extra request/response?
> > >
> > > This extra request/response pair usually has a clear purpose:
> > > transmitting an authentication challenge, which is necessary to
provide
> > > some degree of security.
> > >
> > > > I believe the challenge every request was seen using a vanilla
apache
> > > > httpd 2.x. server. Perhaps some simple server side configuration
> > > > should be suggested?
> > > > Is using preemptive authentication mode for this purpose outside of
> > > > what it was designed for?
> > > >
> > >
> > > Please consider moving to HttpClient 4.0 if you need a more flexible
> > > authentication framework. HttpClient 4.0 can be tweaked to perform
> > > preemptive authentication using BASIC and partially DIGEST scheme as
> > > described below:
> > >
> >
> > I will look into this more when I get a chance.
> >
> > Two things I noticed on a quick scan:
> > AuthScope which is used in CredentialsProvider's
> > getCredentials(AuthScope authScope) captures the realm.
> > However for DIGEST authentication the protection
> > space also involves the domain challenge parameter (See RFC 2617,
> > section 3.2.1). I am not quite sure what consequences this has if
> > any.
> >
>
> As far as I understand domain attribute can useful when re-using
> authentication challenge details for subsequent requests.
>
> > Also it seems that Authentication-Info headers are not looked
> > at by the HttpClient 4. Presumably this would have to be done by
> > the application in some way. Will this cause problems?
> >
> >
>
> One cannot completely rule out the possibility of this provoking a
> full-scale Martian invasion or accelerating the global warming.
> Otherwise
>
> We _happily_ take patches. You are _very_ welcome to submit a better
> implementation of DIGEST authentication. The existing code has not been
> worked on since 2003 and could certainly be improved in many ways.

Thanks, I will keep this in mind.
I do not have a coded patch -- at this point its mind vaporware.
I am also not in a position to contribute at this time but that
may change, for example if one cannot implement this at all which
at this point I do not assume.

>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message