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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
