[Edbrowse-dev] NTLM in edbrowse

[Edbrowse-dev] NTLM in edbrowse

[Karl Dahlke]

I'm pretty sure realm was a parameter from the beginning,
long before curl was ever used.
It was going to perhaps control the type of authentication.
Since we are using curl I don't think it has any meaning.
If you'd like to get rid of it that's fine;
or I can do it next time I have my hands in the code.

Karl Dahlke

Re: [Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Wed, Aug 13, 2014 at 09:47:48AM +0100, Adam Thompson wrote:
> On Mon, Aug 11, 2014 at 03:25:08PM -0700, Chris Brannon wrote:
> > Adam Thompson <arthompson1990@gmail.com> writes:
> > The realm field from auth.c doesn't seem to be used after we switched
> > over to letting libcurl handle authentication.
> 
> Ok, I'll remove it tonight or tomorrow in that case.

Ok, I've done it and pushed the commit.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Mon, Aug 11, 2014 at 03:25:08PM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Thanks, commit pushed.
> 
> Sounds good.  I'd still love to know why the auth negotiation is broken.
> Is it something that needs to be reported upstream to the curl people?

I'm not sure tbh. Looking on the internet suggests they've been told,
but it may be worth looking through their bug tracker to check.
The basic problem is that, when you don't have Kerberos credentials set up,
the Negotiate auth fails and libcurl then errors out as it happens after the
authentication check round-trip (i.e.
libcurl has already decided which auth method it's going to use and doesn't fall
back on an auth failure). In most cases this behavior of not falling back on
auth failures is perfectly sane (and
probably desirable) since it prevents doing something unfortunate like falling
back from digest to basic auth because the user wasn't authorized to view
particular content. The problem is that microsoft IIS seems to like sending
Negotiate auth headers with NTLM ones (not sure if it's an implementation, protocol or configuration thing
or what, I'd need to check the NTLM and IIS docs).

> The realm field from auth.c doesn't seem to be used after we switched
> over to letting libcurl handle authentication.

Ok, I'll remove it tonight or tomorrow in that case.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] NTLM in edbrowse

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Thanks, commit pushed.

Sounds good.  I'd still love to know why the auth negotiation is broken.
Is it something that needs to be reported upstream to the curl people?

The realm field from auth.c doesn't seem to be used after we switched
over to letting libcurl handle authentication.

-- Chris

Re: [Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Mon, Aug 11, 2014 at 05:46:16PM -0400, Karl Dahlke wrote:
> Go ahead and push; it makes sense to me.

Thanks, commit pushed.

Also, whilst tracking this down I noticed that the realm in auth.c is never used.  Is there any point in it still being there, particularly as in the code it's hard-coded to 1 (basic) and seems to have no effect on what auth method is used as far as http goes?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] NTLM in edbrowse

[Karl Dahlke]

Go ahead and push; it makes sense to me.

Re: [Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Mon, Aug 11, 2014 at 04:24:20PM +0100, Adam Thompson wrote:
> On Mon, Aug 11, 2014 at 07:09:26AM -0700, Chris Brannon wrote:
> > Adam Thompson <arthompson1990@gmail.com> writes:
> > 
> > > I also see no evidence of any kind of auth header during the requests.
> > 
> > That's strange.  No authentication header?  Can you try using another
> > browser that is known to work and comparing the headers that it receives
> > and sends with the ones you are getting when trying to access the
> > service with edbrowse?
> > The lack of a WWW-Authenticate header makes me wonder if there could be
> > some JS magic going on here as well.
> 
> Ok, so it looks like (from running a couple of curl commands)
> the problem is a libcurl one. Basically
> when I use --ntlm the request with curl succeeds, however when I use --anyauth,
> libcurl tries Negotiate which obviously fails since I haven't got it set up.
> Since I suspect this is probably the case for almost everyone,
> I'm tempted to make edbrowse tell libcurl only to do basic,
> Digest and NTLM by default (testing with curl --basic --digest --ntlm works
> against the service concerned).

I made this change to my local version (replace CURLAUTH_ANY with
CURLAUTH_BASIC | CURLAUTH_DIGEST | CURLAUTH_NTLM) and all seems to work now.
If you want I'll push this change unless anyone really wants Negotiate auth.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Mon, Aug 11, 2014 at 07:09:26AM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > I also see no evidence of any kind of auth header during the requests.
> 
> That's strange.  No authentication header?  Can you try using another
> browser that is known to work and comparing the headers that it receives
> and sends with the ones you are getting when trying to access the
> service with edbrowse?
> The lack of a WWW-Authenticate header makes me wonder if there could be
> some JS magic going on here as well.

Ok, so it looks like (from running a couple of curl commands)
the problem is a libcurl one. Basically
when I use --ntlm the request with curl succeeds, however when I use --anyauth,
libcurl tries Negotiate which obviously fails since I haven't got it set up.
Since I suspect this is probably the case for almost everyone,
I'm tempted to make edbrowse tell libcurl only to do basic,
Digest and NTLM by default (testing with curl --basic --digest --ntlm works
against the service concerned).
We could then allow other auth methods in the config file. Any thoughts?

Cheers,
adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] NTLM in edbrowse

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> I also see no evidence of any kind of auth header during the requests.

That's strange.  No authentication header?  Can you try using another
browser that is known to work and comparing the headers that it receives
and sends with the ones you are getting when trying to access the
service with edbrowse?
The lack of a WWW-Authenticate header makes me wonder if there could be
some JS magic going on here as well.

I honestly don't know anything about NTLM, except that it should be
supported in libcurl.  Lots of libcurl features are optional, and they
can be disabled at the distro level.  But NTLM support does not appear
to be one of them.

-- Chris

[Edbrowse-dev] NTLM in edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

Hi,

At the company where I work, we use a *lot* of NTLM authenticated services.
Attempting to use these with edbrowse I noticed none of them appear to authenticate at all.
With db7 switched on, I can see no round-trip,
dispite the fact that apparently ntlm requires an auth handshake,
and we're using HTTPAUTH_ANY which should mean that libcurl checks what the web
server will do before sending the auth credentials.
I also see no evidence of any kind of auth header during the requests.

As these are internal servers, I'm not entirely sure if I can post a transcript unfortunately.

Any ideas what's going on? Having looked through the code I can't spot why this
isn't working as it looks like we do everything as per the curl docs,
unless there's some form of extra step we need to perform to get the round trip to work?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]