See comments below. Thanks, Henrich
Oleg Kalnichevski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
