On Tue, 2014-06-24 at 18:46 +0200, Holger Kummert wrote: > Hello David, > > thanks for taking time and reviewing and testing the code. > > Am 23.06.2014 16:23, schrieb David Woodhouse: > > 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?) > > Are you sure that a server will never ask to use the OEM charset? > If yes, the OEM code could of course be elimintated. > Or is this more a kind of assumption?
My understanding is that the phase 1 packet should indicate which of
{OEM, Unicode} you support, and the server shouldn't ask for something
that you said you didn't support.
So if you don't set the OEM bit in your phase 1 packet, no server should
ask you to do OEM mode.
> >
> > 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...
>
> Yes, probably ...
> But as I've written to Gert 3 weeks ago, this group has decided
> to presume UTF-8-encoding _internally_. If an environment doesn't
> support it, or is misconfigured, the "outer interfaces" of Openvpn
> should take care of this (Manager, config file, etc.).
Makes sense.
> >
> > 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...
>
> Well the Windows 2008 server I'm testing against actually sends
> Target-Info. It seems that this server ignores what options are set in the
> initial phase-1-packet and has a somehow preconfigured phase-2-answer.
> That stiffness makes me a bit cautious in trusting the negotiation
> parameters like UTF (s.above).
Hm, fair enough. For OEM/Unicode other implementations certainly do seem
to get away with simply specifying which mode they want in the phase 1
packet, then expecting the server to respond in kind. Other
implementations have tended to start supporting Unicode over the years
just by making the change in both places unconditionally. Like this:
https://git.gnome.org/browse/libsoup/commit/?id=67824e62
> > 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.
>
> This is just backward compatibility: 'ntlm' refers to NTLMv1, and the
> new 'ntlm2' to NTLMv2.
Ok. But don't we want to discourage the use of NTLMv1 wherever possible?
> > 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
>
> This looks a bit weird. Are you sure you applied both patches?
> Maybe the logging level should be raised.
> At least some parts of the http handshake should be seen.
Oh, it was trying Digest auth. The username/password I gave it doesn't
work with Digest auth; only NTLM or Basic. Perhaps that's just a weird
setup on the part of my squid server, since I couldn't make Digest auth
work against the Active Directory domain so it has a separate passwd
file.
Either way, it ought to clearly state what happened, not just report
SIGTERM after asking for the password. I shouldn't need to ask for
debugging information to make it report an authentication failure.
> > 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.
>
> Or what about if you try to include this feature in OpenVpn?
> You know for sure much more about that code than me ...
Heh. Even implementing it in OpenConnect was something I was doing
*instead* of my day job... :)
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
