RE: custom authentication with slide and httpclient
Hello Aaron, Lately I have been very upset by that 'expect: continue' handshake. I'll just link you with my results in this urls: http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.dotnet .framework&mid=a515168f-df63-4ff3-8e2b-ec7f6fb76c0a http://issues.apache.org/bugzilla/show_bug.cgi?id=31567 In short, there seems to be an exploit Micro$oft found about to make their http 1.1 implementation incompatible with tomcat 5.0.28 (at least this version it's true). Seems like M$ uses the 'expect: continue' header for authentication handshake but instead of waiting for the response, from the remote server, before starting to send the body content, it starts to send the body content anyway. That is bad because tomcat replies with an obvious 401 Unauthorized, and for the following HTTP request it uses the data from the body content from the previous request as the start of the following request. That results in another error response 505 HTTP Version Not Supported. In those links I complained to M$ and they just told me to disable the 'expect' headers (LOL), and to Tomcat, Remy just wasn't very reasonable to make an enhancement (discard the data of the invalid content body) witch I though it was the right thing to do... It was just a warning about the expect headers. Best regards, Miguel Figueiredo Hi Aaron, See my comments in-line On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote: > Hi folks, sorry for the cross posting but I think this issue is relevant > to both projects. > > There are two problems I have found, one in http client, one in Slide. > First, it seems that CredentialsProvider ONLY is called upon a challenge > from the server (HttpMethodDirector, 'promptForCredentials'), and never > pre-emptively, even if I setAuthenticationPreemptive(true). My > expectation would be that if I set preemptive authentication than my > registered CredentialsProvider should be called prior to the request > being made. Our custom auth doesn't use an HTTP challenge, so the creds > are required to be there to begin with. I can explain this. The problem is that only Basic authentication can be used preemptively and required by HTTP spec for compatibility reasons. All other schemes either cannot be used preemptively (NTLM) or should not be used preemptively (Digest to some extent). Firstly, challenge-less authentication schemes are inherently insecure, because they allow the authentication credentials to be sent to an unknown party. Even if the credentials are encrypted using a predefined encryption algorithm, one can still easily pull off a 'man in the middle' type of exploit. Secondly, the so called 'expect: continue' handshake renders the preemptive authentication virtually superfluous. For a fairly small price one gains a lot in terms of security. Bottom line, if your web server supports HTTP/1.1, which is a commonplace these days, disable the preemptive authentication, enable the 'expect: continue' handshake and live happily ever after. > > In addition, it seems that the HTTP Method implementations of Slide use > a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth > as the default scheme, and does not pick up the global defaults (I tried > registering my parameters on the DefaultParams* singleton after > discovering this, to see if they would be picked up, but they are not). > I do not know much about Slide's inner working, but I'll be willing to take a look at the Slide source code, should this be required. > I think the first quick fix is to update HttpMethodDirector so it uses > CredentialsProvider preemptively (if one is defined, and > setAuthenticationPreemptive is set). > See above. > I'm not sure how to handle the second problem because I am not > thoroughly familiar with the design decisions and abstractions behind > HttpClient and expected usage. I would think either the Slide > WebdavResource should expose the HttpClient with the real AuthState it > will use (I know I can get HttpClient through > WebdavSession.getSessionInstance... but it appears the default AuthState > in the Method "overrides" anything I set), or have the default authstate > inherit global defaults (perhaps lazily). > See above. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom authentication with slide and httpclient
Hi Aaron, See my comments in-line On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote: > Hi folks, sorry for the cross posting but I think this issue is relevant > to both projects. > > There are two problems I have found, one in http client, one in Slide. > First, it seems that CredentialsProvider ONLY is called upon a challenge > from the server (HttpMethodDirector, 'promptForCredentials'), and never > pre-emptively, even if I setAuthenticationPreemptive(true). My > expectation would be that if I set preemptive authentication than my > registered CredentialsProvider should be called prior to the request > being made. Our custom auth doesn't use an HTTP challenge, so the creds > are required to be there to begin with. I can explain this. The problem is that only Basic authentication can be used preemptively and required by HTTP spec for compatibility reasons. All other schemes either cannot be used preemptively (NTLM) or should not be used preemptively (Digest to some extent). Firstly, challenge-less authentication schemes are inherently insecure, because they allow the authentication credentials to be sent to an unknown party. Even if the credentials are encrypted using a predefined encryption algorithm, one can still easily pull off a 'man in the middle' type of exploit. Secondly, the so called 'expect: continue' handshake renders the preemptive authentication virtually superfluous. For a fairly small price one gains a lot in terms of security. Bottom line, if your web server supports HTTP/1.1, which is a commonplace these days, disable the preemptive authentication, enable the 'expect: continue' handshake and live happily ever after. > > In addition, it seems that the HTTP Method implementations of Slide use > a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth > as the default scheme, and does not pick up the global defaults (I tried > registering my parameters on the DefaultParams* singleton after > discovering this, to see if they would be picked up, but they are not). > I do not know much about Slide's inner working, but I'll be willing to take a look at the Slide source code, should this be required. > I think the first quick fix is to update HttpMethodDirector so it uses > CredentialsProvider preemptively (if one is defined, and > setAuthenticationPreemptive is set). > See above. > I'm not sure how to handle the second problem because I am not > thoroughly familiar with the design decisions and abstractions behind > HttpClient and expected usage. I would think either the Slide > WebdavResource should expose the HttpClient with the real AuthState it > will use (I know I can get HttpClient through > WebdavSession.getSessionInstance... but it appears the default AuthState > in the Method "overrides" anything I set), or have the default authstate > inherit global defaults (perhaps lazily). > See above. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom authentication with slide and httpclient
On Mon, 2005-02-07 at 15:25 -0500, Aaron Hamid wrote:
> Hi Oleg,
>
> The type of authentication I am implementing is in fact Kerberos.
OK, I see. The trouble is that currently Basic authentication scheme is
hardwired. It cannot be substituted with any other scheme
http://jakarta.apache.org/commons/httpclient/3.0/xref/org/apache/commons/httpclient/auth/AuthState.html#111
Please file a bug / feature request in Bugzilla and I'll provide a fix
as soon as I can. Luckily (as far as I can tell at this point) the fix
should be pretty straightforward and should not require any API changes
Cheers,
Oleg
>
> There is no secret key sent, etc. Kerberos has it's own
> replay/man-in-the-middle protections. I agree in principal that it is
> best to operate in accordance with existing standards and behavior (even
> if they do not match perfectly what oine requires), however I did not
> design this protocol, it has been in production successfully for years,
> and it is being used in multi-tier (i.e. no human involved) web
> services, so I doubt I have much ground to lobby for a
> challenge/response scheme (that would make things much more complicated
> with regard to stateless services that authenticate
> per-request...everything would have to be rechallenged every request,
> it's just not plausible). I can understand why something like this
> would not be specifically condoned ("only use if you know what you are
> doing") but does it actually have to be prohibited? Can I
> setAuthenticationPreemptive, and then explicitly set Credentials,
> without using CredentialsProvider? I think I tried this, but it may not
> have worked for the second reason I cited.
>
> Thanks for the feedback,
> Aaron
>
> Oleg Kalnichevski wrote:
>
> >Hi Aaron,
> >
> >See my comments in-line
> >
> >On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote:
> >
> >
> >>Hi folks, sorry for the cross posting but I think this issue is relevant
> >>to both projects.
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >>There are two problems I have found, one in http client, one in Slide.
> >>First, it seems that CredentialsProvider ONLY is called upon a challenge
> >>from the server (HttpMethodDirector, 'promptForCredentials'), and never
> >>pre-emptively, even if I setAuthenticationPreemptive(true). My
> >>expectation would be that if I set preemptive authentication than my
> >>registered CredentialsProvider should be called prior to the request
> >>being made. Our custom auth doesn't use an HTTP challenge, so the creds
> >>are required to be there to begin with.
> >>
> >>
> >
> >I can explain this. The problem is that only Basic authentication can be
> >used preemptively and required by HTTP spec for compatibility reasons.
> >All other schemes either cannot be used preemptively (NTLM) or should
> >not be used preemptively (Digest to some extent).
> >
> >Firstly, challenge-less authentication schemes are inherently insecure,
> >because they allow the authentication credentials to be sent to an
> >unknown party. Even if the credentials are encrypted using a predefined
> >encryption algorithm, one can still easily pull off a 'man in the
> >middle' type of exploit.
> >
> >Secondly, the so called 'expect: continue' handshake renders the
> >preemptive authentication virtually superfluous. For a fairly small
> >price one gains a lot in terms of security.
> >
> >Bottom line, if your web server supports HTTP/1.1, which is a
> >commonplace these days, disable the preemptive authentication, enable
> >the 'expect: continue' handshake and live happily ever after.
> >
> >
> >
> >>In addition, it seems that the HTTP Method implementations of Slide use
> >>a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth
> >>as the default scheme, and does not pick up the global defaults (I tried
> >>registering my parameters on the DefaultParams* singleton after
> >>discovering this, to see if they would be picked up, but they are not).
> >>
> >>
> >>
> >
> >I do not know much about Slide's inner working, but I'll be willing to
> >take a look at the Slide source code, should this be required.
> >
> >
> >
> >
> >>I think the first quick fix is to update HttpMethodDirector so it uses
> >>CredentialsProvider preemptively (if one is defined, and
> >>setAuthenticationPreemptive is set).
> >>
> >>
> >>
> >
> >See above.
> >
> >
> >
> >>I'm not sure how to handle the second problem because I am not
> >>thoroughly familiar with the design decisions and abstractions behind
> >>HttpClient and expected usage. I would think either the Slide
> >>WebdavResource should expose the HttpClient with the real AuthState it
> >>will use (I know I can get HttpClient through
> >>WebdavSession.getSessionInstance... but it appears the default AuthState
> >>in the Method "overrides" anything I set), or have the default authstate
> >>inherit global defaults (perhaps lazily).
> >>
> >>
> >>
> >
> >See above.
> >
> >Cheers
Re: custom authentication with slide and httpclient
Hi Oleg,
The type of authentication I am implementing is in fact Kerberos.
There is no secret key sent, etc. Kerberos has it's own
replay/man-in-the-middle protections. I agree in principal that it is
best to operate in accordance with existing standards and behavior (even
if they do not match perfectly what oine requires), however I did not
design this protocol, it has been in production successfully for years,
and it is being used in multi-tier (i.e. no human involved) web
services, so I doubt I have much ground to lobby for a
challenge/response scheme (that would make things much more complicated
with regard to stateless services that authenticate
per-request...everything would have to be rechallenged every request,
it's just not plausible). I can understand why something like this
would not be specifically condoned ("only use if you know what you are
doing") but does it actually have to be prohibited? Can I
setAuthenticationPreemptive, and then explicitly set Credentials,
without using CredentialsProvider? I think I tried this, but it may not
have worked for the second reason I cited.
Thanks for the feedback,
Aaron
Oleg Kalnichevski wrote:
Hi Aaron,
See my comments in-line
On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote:
Hi folks, sorry for the cross posting but I think this issue is relevant
to both projects.
There are two problems I have found, one in http client, one in Slide.
First, it seems that CredentialsProvider ONLY is called upon a challenge
from the server (HttpMethodDirector, 'promptForCredentials'), and never
pre-emptively, even if I setAuthenticationPreemptive(true). My
expectation would be that if I set preemptive authentication than my
registered CredentialsProvider should be called prior to the request
being made. Our custom auth doesn't use an HTTP challenge, so the creds
are required to be there to begin with.
I can explain this. The problem is that only Basic authentication can be
used preemptively and required by HTTP spec for compatibility reasons.
All other schemes either cannot be used preemptively (NTLM) or should
not be used preemptively (Digest to some extent).
Firstly, challenge-less authentication schemes are inherently insecure,
because they allow the authentication credentials to be sent to an
unknown party. Even if the credentials are encrypted using a predefined
encryption algorithm, one can still easily pull off a 'man in the
middle' type of exploit.
Secondly, the so called 'expect: continue' handshake renders the
preemptive authentication virtually superfluous. For a fairly small
price one gains a lot in terms of security.
Bottom line, if your web server supports HTTP/1.1, which is a
commonplace these days, disable the preemptive authentication, enable
the 'expect: continue' handshake and live happily ever after.
In addition, it seems that the HTTP Method implementations of Slide use
a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth
as the default scheme, and does not pick up the global defaults (I tried
registering my parameters on the DefaultParams* singleton after
discovering this, to see if they would be picked up, but they are not).
I do not know much about Slide's inner working, but I'll be willing to
take a look at the Slide source code, should this be required.
I think the first quick fix is to update HttpMethodDirector so it uses
CredentialsProvider preemptively (if one is defined, and
setAuthenticationPreemptive is set).
See above.
I'm not sure how to handle the second problem because I am not
thoroughly familiar with the design decisions and abstractions behind
HttpClient and expected usage. I would think either the Slide
WebdavResource should expose the HttpClient with the real AuthState it
will use (I know I can get HttpClient through
WebdavSession.getSessionInstance... but it appears the default AuthState
in the Method "overrides" anything I set), or have the default authstate
inherit global defaults (perhaps lazily).
See above.
Cheers,
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
