e2guardian + CNTLM 0.92.3 issue

[puppetmaster]

Using e2guardian 3.0.4 and cntlm 0.92.3 authentification don't work. Using the same version of e2guardian with an older version of cntlm (0.35) works fine.

I'm debugging and looking for more informations if somebody have any idea please let me know.

(PS: Same problem with dansguardian)

[fredbcode]

I don't know cntlm, you speak about this http://cntlm.sourceforge.net/ ?
E2 works good with ntlm_auth in Squid ?

[puppetmaster]

Yes I speak about http://cntlm.sourceforge.net.
I will try with Squid

[fredbcode]

Thank, it's just to know if there is a problem about NTLM authplugin in E2.
Auth plugin are basic and just catches the HTTP header (at least for Auth Digest which I worked on, perhaps it's more subtle with NTLM)

[puppetmaster]

CNTLM works fine with direct connection to Squid

[fredbcode]

Ok, please can you get the HTTP header ? For example with http://livehttpheaders.mozdev.org/ (for firefox)
With and without E2

[puppetmaster]

The output of livehttpheaders with CNTLM using Squid : http://cadol.es/paste/2944/

When I setup CNTLM to use e2guardian I don't have any output in livehttpheaders

[puppetmaster]

The ouput of e2guardian (debug mode) : http://cadol.es/paste/2945/

[fredbcode]

Good choices of websites.
There is something that I misunderstand in your configuration:
Proxy-Authorization: Basic c2NyaWJlcGVkYWdvXGFkbWluOmVvbGU=
So a basic auth and his password Hash (don't forget to change your password later ...)

To the best of my knowledge this should be something like:
Proxy-Authorization: NTLM tESsBmE/yNY3lb6a0L6vVQEZNqwQn0s8Unew

Maybe I missed something, but the account (and password) seems good to me and if you activate basic plugin E2 should works.

FYI squid/3.1.20 is deprecead

[puppetmaster]

Our distribution is based on Ubuntu 12.04 (maybe we have a lot of deprecated software, but ubuntu don't care :)

Witch log talks about "Basic c2NyaWJlcGVkYWdvXGFkbWluOmVvbGU="

For the passwords it's an testing virtual machine with a never used in production password :)

[fredbcode]

http://cadol.es/paste/2944/ I saw only basic auth
I'm reading the plugin code, the tag NTLMSSP seems missing, http://cadol.es/paste/2945/
NTLM - step 2 was not part of an auth handshake -> I'm seeing in code this mean NTLMSSP is not present.

So we need to compare with a NTLM connection who works (I mean compare HTTP header) to see if there is NTLMSSP somewhere, but your trace is only about BASIC Auth

[puppetmaster]

With CNTLM the browser allways do a "Basic Auth" CNTLM deals with the NTLM authentification.
So In our case the browser allways run a Basic Auth.

[nerijus]

Is "Basic Auth" enabled in e2guardian?

[fredbcode]

So the browser should receive a Basic auth, no ?

[puppetmaster]

nerijus yes
fredbcode yes

[puppetmaster]

In HTTPHeader.cpp This method HTTPHeader::authRequired waits a code 407 in my case it receives a 200

[fredbcode]

That's mean that the identification was not made by the browser.
Yes at first Squid return a 407 for user banner it's the usual case, so if I understand right CNTLM respond for the browser ?

You can easily check

1. Open a browser without any website (or close the ident pop-up)
2. Open livehttpheaders
3. Try google.com with identification

The first packet returns should be a 407 (RFC compliant) and the browser pop-up appears
After that the page appears with code 200

So CNTLM is a kind of "linker" to windows active directory ? I think the interest is very limited if the password is converted to basic, you have an encrypted password broken before it goes to the lan, without any security. But maybe I miss something, if not, my advice is to using the standard Squid helper to update your lan security.

If the 407 is "removed" by CNTLM there are nothing we can do, please open a bug at CNTLM project.

[fredbcode]

In HTTPHeader.cpp This method HTTPHeader::authRequired waits a code 407 in my case it receives a 200

Change this part of code could break ident or creates unexpected behavior.

[GnunuX]

fredbcode: So CNTLM is a kind of "linker" to windows active directory ?

No, we use cNTLM for browser that didn't support natively NTLM. cNTLM generate NTLM authentification but force basic authentification in the browser.

[fredbcode]

Upon consideration of this issue, there is something strange in your comment
How your pop-up can be appear if you don't receive a 407 ?

[puppetmaster]

The popup is allready passed when I have this 200.

[fredbcode]

FYI: You can use two simultaneous methods in Squid, for example I'm using Digest and Basic, the browser negotiates. (For example wget can't works with digest and "deal" with squid in Basic)

So ok, it's not a problem with NTLM but basic authentication, it's more simple.
cNTLM generate NTLM authentification

Between Squid and cNTLM only, if I understand right

but force basic authentification in the browser

That's the point, the basic authentication seems strange but maybe there is a mistake in the comment before because 407 is needed.

[puppetmaster]

cNTLM don't interact with Squid but with e2guardian and e2guardian talks to squid.

[fredbcode]

Hum I don't know scribe, but e2guardian doesn't makes any identification
It just "sniff" the headers packets that's all. At least that you are using a "special" version

If you speak about this http://fr.wikipedia.org/wiki/Scribe_%28serveur%29 I guess this is an openldap and E2 can't "talks" to him.

To be clear E2/DG can just check if the user is identified to a proxy (no matter the kind of proxy squid, bluecoat, etc) and for this it just reads the headers

From DG documentation:

In some (but not all) cases DansGuardian subcontracts fetching the authentication information to the local proxy (probably Squid). DansGuardian ultimately cares only about the username, even when it subcontracts fetching the authentication to the local proxy which then goes much further. DansGuardian never knows or cares anything about the password (not even whether or not the password is correct). This does not lead to any problem because Squid won't return web content that DansGuardian can filter until after the password has proved correct. So DansGuardian can simply assume if it's here, it must be okay

[puppetmaster]

e2guardian is "placed" before the Proxy ? So the "client" connect to e2guardian and not directly to the Squid, am I right ?

In this case the "Client" connects to CNTLM, and CNTLM deals with "is proxy" e2guardian witch deals with Squid.
So the NTLM "demand" is sended to e2guardian to be forwarded to Squid (I think)

[fredbcode]

e2guardian is "placed" before the Proxy ? So the "client" connect to e2guardian and not directly to the Squid, am I right ?

Yes

In this case the "Client" connects to CNTLM with "is proxy" e2guardian witch deals with Squid.
So the NTLM "demand" is sended to e2guardian to be forwarded to Squid (I think)

In your case where is CNTLM before or after Squid ? but I guess no matter

Here an example
https://adolfomaltez.wordpress.com/2013/02/22/dansguardian-squid-cntlm-proxy-parent-internet-access/

As you can see CNTLM return the 407 through the squid and DG to browser, after that DG just read the result (ok or ko)
The only thing it must know is the format (digest, ntlm, basic) to takes the good value at the right place. It's what the documentation mean by DansGuardian never knows or cares anything about the password, this is just a stream through him.

DansGuardian doesn't makes any identification, just check if there is a problem.

After that e2guardianf1.conf should be used with groupmode = 1 (or all groups are denied)

[fredbcode]

We can reduce the problem like this, the basic credential through DG is RFC compliant ?
Because we know that Dansguardian works perfectly with basic identification.

[fredbcode]

In this case the "Client" connects to CNTLM with "is proxy" e2guardian witch deals with Squid.
So the NTLM "demand" is sended to e2guardian to be forwarded to Squid (I think)"

It's not like this, the credential method goes from the proxy to browser.
If I understand, you have

browser -> CNTLM -> e2guardian -> squid -> net ?

In this case there is NTLM between CNTLM and squid, so E2 should be configured to read NTLM

If browser -> e2guardian -> CNTLM -> squid -> net

In this case it's a basic identification

Perhaps switch your config could resolve your problem ?

[puppetmaster]

In this case it's :

browser -> CNTLM -> e2guardian -> squid -> net

[fredbcode]

Ok it's more clear, who check the Ldap ? I guess Squid ? In this case we deal with NTLM between squid and CNTLM

[puppetmaster]

I try more debug and the result is :

With CNTLM 0.35 it works, the debug : http://cadol.es/paste/2963/
With CNTLM 0.92 don't works; the debug : http://cadol.es/paste/2962/

Some capture on network :

CNTLM 35 : http://cadol.es/paste/2960/
CNTLM 92 : http://cadol.es/paste/2961/

We continue to debug.

[puppetmaster]

With CNTLM 35 after the first request, I don't see anymore the ProxyAuth NTLM XXXX in the logs
but with CNTLM 92 it cames with any request.

[fredbcode]

Yes normal, here a complete handshake: http://msdn.microsoft.com/en-us/library/dd925287%28v=office.12%29.aspx and http://squid.sourceforge.net/ntlm/client_proxy_protocol.html
Also see the difference between:
proxy-Authorization: NTLM and proxy-Authenticate: NTLM

I think for a good debug we need a complete wireshark trace between the proxies without e2guardian to compare if there is a difference in HTTP Header with 0.35 and 0.92 (of course I'm speaking about a capture at first cnx with the 407 and the Handshake after)

Proxy-Authorization: NTLM TlRMTVNTUAABAAAABrIAAAwADAAkAAAABAAEACAAAABBTU9OU0NSSUJFUEVEQUdP

TlRMTVNTUA is constant in both version ? I saw something about in NTLM documentation but not in proxy mode, are you seeing exactly the same line with both ?

[puppetmaster]

yes same TlRMTVNTUA in both logs

[fredbcode]

Ok, make a complete network trace with header, there must be a difference somewhere.

[fredbcode]

This should help you: (port and eth depend of your config)
tcpdump -i eth1 -n -A 'tcp port 3128 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | egrep --line-buffered "^........(GET |HTTP\/|POST |HEAD )|^[A-Za-z0-9-]+: " | sed -r 's/^........(GET |HTTP\/|POST |HEAD )/\n\1/g'

[puppetmaster]

We run this to get the headers with cntlm/e2guardian/squid.

tshark -ni any -d tcp.port==3127,http -d tcp.port==3128,http -d tcp.port==8080,http -R "http.response or http.request" -T fields -e frame.time_epoch -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e http.request.version -e http.request.method -e http.host -e http.request.uri -e http.user_agent -e http.response.code -e http.content_type -e http.content_length -e http.location -e http.referer

[puppetmaster]

I have found something in HTTPHeader.cpp.

With the "working" cntlm version e2guardian opens a tunnel for POST Data :

Opening tunnel for POST data
TUNNEL DEBUG : 115
All expected data tunnelled. (expected 115; tunnelled 115)
44738 -2tunnel activated
All expected data tunnelled. (expected 1365; tunnelled 1365)

With the "non-working" cntlm version e2guardian never opens the tunnel :

Opening tunnel for POST data
TUNNEL DEBUG : 0
No data expected, tunnelling aborted.

[fredbcode]

Yes, the documentation say it's the good end - open tunnel - after the identification was checked
http://msdn.microsoft.com/en-us/library/dd925287%28v=office.12%29.aspx .
We saw before that the response from browser request: (Fake browser because it's CNTLM)
Proxy-Authorization: NTLM TlRMTVNTUAABAAAABrIAAAwADAAkAAAABAAEACAAAABBTU9OU0NSSUJFUEVEQUdP
Should be HTTP/1.1 200 Connection established and the creation of a tunnel from proxy.

What's the trace says ? http://cadol.es/paste/2961/ is not enough detailed
Without traces to show the differences (without DG between proxy and CNTLM) we can't easily progress.

There is something missing (or added) at the answer of request from CNTLM 92

[puppetmaster]

I'm reading CNTLM 92 code to see if something is wrong.

For now I just saw to much HTTP/1.1 does e2guardian support HTTP/1.1 ?

[fredbcode]

Yes,
This seem close to your problem http://sourceforge.net/p/cntlm/bugs/48/ but only a trace can answer ...

[puppetmaster]

No more time to find out, I open a Bug on CNTLM to : https://sourceforge.net/p/cntlm/bugs/69/

[fredbcode]

Ok, so I close now, please feel free to reopen it.
Unfortunately seems a stalled/dead project, according to David Kubicek comments here http://sourceforge.net/p/cntlm/bugs/48/

[puppetmaster]

We have more informations about this, can we re-open this issue ?

[fredbcode]

Of course yes

[GnunuX]

We have some informations about this bug.
The problem is that CNTLM force authentification even if destination web site didn't need authentification.

For example, home page of the browser is an internal website, CNTLM force NTLM authentification, e2guardian manage the authentification session but squid allow access without authentification.

If the homepage need authentification in squid, all works fine.

I think e2guardian should access non authentificate connexion even if an NTLM authentification is started and not terminated.

[fredbcode]

Maybe I'm misunderstanding, but:

The problem is that CNTLM force authentification even if destination web site didn't need authentification.

There is a big difference between this two headers

Proxy-Authorization: NTLM :
Only between CNTLM -> e2guardian -> squid
It's needed with CNTLM through E2, this is proxy authorisation and should be permanently.
And
Authorization: NTLM : Website with and NTLM authentication:
browser -> CNTLM -> e2guardian -> squid -> website (NTLM ident only for a specific website)

As you can see this not the same HTTP header

CNTLM should reads NTLM Proxy-Authorization: NTLM authentication because this is his job.

I think e2guardian should access non authenticate connexion even if an NTLM authentification is started and not terminated.

E2guardian takes care only about proxy authentication, a complete and permanent NTLM proxy identification is needed otherwise this is a security breach, sorry but we can't allow that.

Your config above-mentioned:
browser -> CNTLM -> e2guardian -> squid -> net

In your case E2 takes only care about the identification (Proxy-Authorization:) configured in Squid
So NTLM, after that CNTLM transform that to BASIC proxy and send

Proxy-Authorization: BASIC for each requests

FYI: Website with NTLM identification should doesn't works through web proxy - in usual case - because NTLM mean NT LAN Manager, however Squid can uses ConnPin for this http://wiki.squid-cache.org/Features/ConnPin this could be useful in local network.

And I don't know if NTLM website can pass through E2, but Microsoft no longer support NTLM in applications.

[GnunuX]

Maybe it will be more clear with PCAP file (I send it with png extension because pcap file are not allowed).

Here is 2 PCAP file with this architecture: cntlm (port 3127) > e2guardian (port 3128) > squid (port 8080)

My wgetrc file:

---

http_proxy = http://10.2.3.1:3127/
proxy_user = admin
proxy_password = eole

use_proxy = on

wget command: wget http://www.monip.org -O /dev/null -t 1

My default squid configuration:

---

auth_param ntlm program /usr/lib/squid3/ntlm_smb_lm_auth -a rah/pouet
auth_param ntlm children 20
auth_param basic children 20
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl password proxy_auth REQUIRED

http_access allow noauth

All work fine without CNTLM.

In first case, www.monip.org is not in noauth ACL ():

Frame 1 to 5: basic authentification to CNTLM
Frame 6 to 19: NTLM challenge from CNTLM to squid (via e2guardian)
Frame 20 to 24: authentif OK, squid download web page
Frame 25 to 30: squid send page to e2guardian
Frame 31 to 35: page send to CNTLM

If I add www.monip.org to my noauth ACL in squid (:

Frame 1 to 5: basic authentification to CNTLM
Frame 6 to 10: cntlm start challenge from CNTLM to squid (via e2guardian)
Frame 11 to 17: not authenfication needed for squid, download web page
Frame 18: e2guardian recieve webpage but are not unable to send it to cntlm

e2guardian is not unable to send my webpage.

[fredbcode]

Ah, c'est beaucoup plus clair maintenant :)

I will take a look next week, where I can see the pcap file ?
What do you think about switch e2 with CNTLM, like this:

browser -> e2guardian -> cntlm -> squid -> net

browser -> e2guardian -> cntlm = BASIC
CNTLM -> Squid = NTLM

I guess this should also reduce the load for e2 because BASIC ident code is more simpler

[GnunuX]

First one: https://cloud.githubusercontent.com/assets/150240/5681840/28771ab0-981c-11e4-9e90-ad5716ed0daf.png
Second one: https://cloud.githubusercontent.com/assets/150240/5681843/2e423d76-981c-11e4-9263-9d782069f38b.png
(those files arn't png file)

What do you think about switch e2 with CNTLM

No, because CNTLM is use only for a set of computer (mainly mobile workstation integrated to an other windows domain).

[fredbcode]

I watched quickly (sorry very quickly)

If I understand right the packet 18 is a FIN, ACK from e2 to CNTLM, so where is the communication between Squid and e2 ? We don't know why E2 close this cnx

Same thing to the other trace packet 24,25,25 are answer from port 3128 to randomly source port (42952 in this case) so I guess the answer from e2 to CNTLM , but nothing for squid to e2

Maybe I missed something, in this case tell me, I will take a look later

[fredbcode]

Oh I forgot, in trace - normally - without identification, why there is a NTLM negotiation (packet 9) ?
As I said e2guardian can't do that because it just relay packet without any change at all.

But in this case there is a NTLM negociation:
Proxy-Authorization: NTLM TlRMTVNTUAABAAAABrIAAAMAAwAkAAAABAAEACAAAABBTU9OUkFI\r\n

If the problem is CNTLM is buggy and force NTLM identification, unfortunately we can't change that with e2. This is too dangerous for security

The squid answer should be very interesting ... And a comparison between the both CNTLM version too.
I can suppose that there is a second negotiation without identification for each packet, this is also a performance issue ...
And E2/DG breaks this weird dialog

[GnunuX]

Sorry, i forgot port 8080 in my tshark filter. Here are new captures:

https://cloud.githubusercontent.com/assets/150240/5701900/99e065b6-9a52-11e4-8bd2-9a678fe72b23.png
https://cloud.githubusercontent.com/assets/150240/5701901/9d96201a-9a52-11e4-8d15-5cb1278f5fc2.png

[fredbcode]

Ok the problem is that CNTLM try to negotiate with Squid a NTLM when this is not needed

Proxy identification works like this:

1. The user makes a request
2. Squid returns a 407 status code, along with an header: Proxy-Authenticate: NTLM
3. The client connects and issues a GET-request, this time with an accompanying
   Proxy-Authorization: NTLM
4. The server once again replies with a 407 ("proxy auth required") status code, along with an header:Proxy-Authenticate: NTLM still_some_more_stuff
5. The client sends a new GET-request, along with an header: Proxy-Authenticate: NTLM cmon_we_are_almost_done
6. Either the server denies the authentication via a 407 return code, and we're back to square one, or it returns the requested resource.
   From now on, until the TCP connection will be kept alive, no further credentials will be sent from the client to the proxy . The TCP connection is marked as "OK", and the client expects that it can pump whatever it wants..

Your problem is that the "client" uses a NTLM secure identification.

E2 waits the NTLM Message Type: NTLMSSP_CHALLENGE but it never come.
I also guess the packet 13 should be not returned by squid (bug ?) because it answer without identification HEADER at a request who needs an identification (from CNTLM point of view of course)

Can you make a trace with CNTLM 0.35 to see the difference ? Just with noauth acl

Also can you try this, in authplugins/proxy-digest.conf add noauthdomains = '/yourpath/test/' and add your domain in test file

[GnunuX]

Can you make a trace with CNTLM 0.35 to see the difference ? Just with noauth acl

In fact, we have quite same problem with cNTLM 0.35. In this version, ntlm authentification are only tried one time. Se we have an error, we just have to refresh page to access to the website.

Also can you try this, in authplugins/proxy-digest.conf add noauthdomains = '/yourpath/test/' and add your domain in test file

No difference with this configuration.

[fredbcode]

OK, unfortunately I see no answer with e2 for this problem.
Change the CNTLM code or your architecture seems the only way. At worst maybe you can also change the E2 code but it's should be hard to maintain after (3.3.0 is in approach)

Personally, I'm using simultaneous auth methods (ACL) with squid, for example wget negotiates BASIC identification automatically (transparent for user), recent browser DIGEST, and for some others no AUTH at all.

[GnunuX]

I understand, thanks for your help.