On Mon, 2014-06-02 at 18:28 +0200, Holger Kummert wrote: > > Hi, > > due to the lack of a testing environment for the main developers we are > looking for someone who is willing to test the two patches which make > the NTLMv1 and v2-code running (again?) and offer a clearer user > interface for the configuration of http proxy authentication. > > The developer of the patches already tested them, but a second proof > that they really work would be very helpful. > > The patches, based on the master branch, can be found at: > > http://thread.gmane.org/gmane.network.openvpn.devel/8531
As it happens, I've just added proxy auth support to the OpenConnect VPN client, and have a local squid instance set up to accept all of GSSAPI, NTLM, Digest and Basic auth. Looking over the patches first... they make the client work in OEM or Unicode mode according to what the server asks for... but then only ever admit to supporting Unicode mode in the 'phase 1' packet anyway. So a sane server is *never* going to ask you to do OEM, and you might as well ditch all the conditional code for supporting that. (Quite frankly, even if you add the OEM flag to your phase 1 packet, a sane server in 2014 is *still* never going to ask you to do OEM mode anyway, is it?) Also, it is strictly correct to assume that the input strings are utf-8? It certainly *ought* to be — again, it's 2014 so who in their right mind would be using non-UTF8 locales? But some nutters insist on remaining stuck in the 20th century... You also don't seem to include the NTLM_NEGOTIATE_TARGET_INFO flag in your phase 1 packet, which means I'd be surprised if you ever actually get the target info back from a server in its challenge... which in turn means I'd be surprised if you'd actually exercised that part of the NTLMv2 code path. Or do some servers send it 'unsolicited'? Samba apparently doesn't send it even if I do set the TARGET_INFO flag in the phase_1 packet... Yours is actually the first implementation of NTLMv2 auth that I've seen — other implementations seem to have a combination of NTLMv1 and 'NTLMv2 session' authentication — see http://curl.cofman.dk/rfc/ntlm.html#theNtlm2SessionResponse and http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/fe5cf5fd67 for example. We send just the single phase1 packet, and the server either takes us up on the offer of NTLMv2 session auth, or not. All that said, these patches do seem to work for NTLMv1 and NTLMv2 authentication to my test server. Although I need to explicitly *ask* for NTLMv2; if I just say 'ntlm' then it uses NTLMv1. That isn't what I expected after reading the commit message on the second patch. And if I say '--http-proxy localhost 3128 auto', it doesn't work at all. And doesn't really tell me why, which is naughty of it: Enter HTTP Proxy Username:dwoodhou Enter HTTP Proxy Password: Mon Jun 23 14:36:03 2014 SIGTERM[soft,init_instance] received, process exiting However, one of the things that NTLM is supposed to offer me is single-sign-on. If I've logged in to my workstation using my domain password (and I have), then single-sign-on ought to work by using Samba's /usr/bin/ntlm_auth helper tool. That works for other things like Firefox and the Evolution mail client... and for proxy auth with OpenConnect too, of course. There's a simple implementation at http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/583ee4b6c3 which you are welcome to copy into OpenVPN under GPLv2. Of course, GSSAPI support would also give me single-sign-on. But you don't support that either. Again, you're welcome to use my code from OpenConnect if it's useful. RFC1928 says that SOCKS implementations MUST support GSSAPI auth too, FWIW :) -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
