hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Preemptive authentication throws IllegalStateException using ISA proxy server
Date Wed, 12 Nov 2008 10:14:33 GMT
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?

> 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.

Oleg 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message