openvpn-devel Mailing List for OpenVPN

Hi, The patch below is extracted from Andris Kalnozols' version 2 patch in trac ticket #402, annotated with some comments from me. The functionality this patch provides makes sense to me, and fixes faulty behaviour in both the release/2.3 and master branches. I think a final version of this patch should be applied to both branches. The options parsing code contains some magic, so I guessed it would be the easiest for everyone if I just proposed a new version myself that takes care of my comments. You'll find that attached. That version skips the string copy at the expense of the reported error, which now only reports the upcased x509-username-field, instead of both the original and upcased value. Andris, could you maybe test this patch and reports whether it indeed works as expected for you? On 28-06-14 21:19, Andris Kalnozols wrote: > From: Andris Kalnozols <an...@hp...> > > I revisited options.c to refine its brute-force upcasing behavior. Now, the > upcasing is done only if the option argument is all lowercase. Mixed-case > arguments and those with the "ext:" prefix are left unchanged. This > preserves the original intent of the "helpful" upcasing feature for > backwards compatibility while limiting its scope in a straightforward way. > > Signed-off-by: Andris Kalnozols <an...@hp...> > --- > doc/openvpn.8 | 44 ++++++++++++++++++++++++++++++++++++++------ > src/openvpn/options.c | 29 +++++++++++++++++++++++++---- > 2 files changed, 63 insertions(+), 10 deletions(-) > > diff --git a/doc/openvpn.8 b/doc/openvpn.8 > index 14f3129..64247a4 100644 > --- a/doc/openvpn.8 > +++ b/doc/openvpn.8 > @@ -4745,12 +4745,44 @@ the tls-verify script returns. The file name used for the certificate > is available via the peer_cert environment variable. > .\"********************************************************* > .TP > -.B \-\-x509-username-field fieldname > -Field in x509 certificate subject to be used as username (default=CN). > -.B Fieldname > -will be uppercased before matching. When this option is used, the > -.B \-\-verify-x509-username > -option will match against the chosen fieldname instead of the CN. > +.B \-\-x509-username-field [ext:\]fieldname > +Field in the X.509 certificate subject to be used as the username (default=CN). > +Typically, this option is specified with > +.B fieldname > +as either of the following: > + > +.B \-\-x509-username-field > +emailAddress > +.br > +.B \-\-x509-username-field ext:\fRsubjectAltName > + > +The first example uses the value of the "emailAddress" attribute in the > +certificate's Subject field as the username. The second example uses > +the > +.B ext: > +prefix to signify that the X.509 extension > +.B fieldname > +"subjectAltName" be searched for an rfc822Name (email) field to be used > +as the username. In cases where there are multiple email addresses > +in > +.B ext:fieldname\fR, > +the last occurrence is chosen. > + > +When this option is used, the > +.B \-\-verify-x509-name > +option will match against the chosen > +.B fieldname > +instead of the Common Name. > + > +.B Please note: > +This option has a feature which will convert an all-lowercase > +.B fieldname > +to uppercase characters, e.g., ou -> OU. A mixed-case > +.B fieldname > +or one having the > +.B ext: > +prefix will be left as-is. This automatic upcasing feature > +is deprecated and will be removed in a future release. > .\"********************************************************* > .TP > .B \-\-tls-remote name (DEPRECATED) > diff --git a/src/openvpn/options.c b/src/openvpn/options.c > index 035d3aa..10a8e7f 100644 > --- a/src/openvpn/options.c > +++ b/src/openvpn/options.c > @@ -577,8 +577,8 @@ static const char usage_message[] = > " and optionally the root CA certificate.\n" > #endif > #ifdef ENABLE_X509ALTUSERNAME > - "--x509-username-field : Field used in x509 certificate to be username.\n" > - " Default is CN.\n" > + "--x509-username-field : Field in x509 certificate containing the username.\n" > + " Default is CN in the Subject field.\n" > #endif > "--verify-hash : Specify SHA1 fingerprint for level-1 cert.\n" > #ifdef WIN32 > @@ -6875,10 +6875,31 @@ add_option (struct options *options, > #ifdef ENABLE_X509ALTUSERNAME > else if (streq (p[0], "x509-username-field") && p[1]) > { > + /* This option also introduced a feature to automatically upcase the > + * fieldname passed as the option argument, e.g., "ou" became "OU". > + * Fine-tune this "helpfulness" by only upcasing Subject field > + * attribute names which consist of all lower-case characters. > + * Mixed-case attributes such as "emailAddress" are left as-is. > + * An option parameter having the "ext:" prefix for matching > + * X.509v3 extended fields will also remain unchanged. > + */ > char *s = p[1]; > + char *l; > + char lowercase_name[OPTION_PARM_SIZE] = { 0 }; Although this seems reasonable, OPTION_PARM_SIZE actually isn't the maximum length of p[1]; parameters supplied on the command line can be larger then this. > + > VERIFY_PERMISSION (OPT_P_GENERAL); > - if( strncmp ("ext:",s,4) != 0 ) > - while ((*s = toupper(*s)) != '\0') s++; /* Uppercase if necessary */ > + if (strncmp("ext:", s, 4) != 0) > +	{ > + strncpy(lowercase_name, s, strlen(s)); This actually is a strcpy(lowercase_name, s) that doesn't copy the trailing '\0'. In combination with a p[1] that is larger than OPTION_PARM_SIZE, this will still happily do an out-of-bounds write. > + l = lowercase_name; > + while ((*l = tolower(*l)) != '\0') l++; > + if (strncmp(s, lowercase_name, strlen(s)) == 0) > + { > + while ((*s = toupper(*s)) != '\0') s++; > + msg(M_WARN, "DEPRECATED FEATURE: automatically upcased the --x509-username-field parameter from '%s' to '%s'; please update your configuration", > + lowercase_name, p[1]); > + } > +	} > options->x509_username_field = p[1]; > } > #endif /* ENABLE_X509ALTUSERNAME */ > 

Thanks. Patch has been applied to the master and release/2.3 branches. commit 37170767a221a4847416fc339083704ae1b4c001 (master) commit 066202de18a13d67664534d10698eda1fdeab381 (release/2.3) Author: James Bekkema Date: Thu Jun 26 21:40:39 2014 +1000 Fix socket-flag/TCP_NODELAY on Mac OS X Acked-by: Arne Schwabe <ar...@rf...> Message-Id: <A10...@sp...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8809 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Hi, On 29-06-14 18:09, Jonathan K. Bullard wrote: > A recent _"Lab Mouse Security research blog" entry_ > <http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html> claimed > that a bug exists in several implementations of the LZO algorithm > commonly used by OpenVPN and that the bug causes a security vulnerability. > > A rebuttal on the "RealTime Data Compression" blog > <http://fastcompression.blogspot.co.uk/2014/06/lets-move-on.html> points > out that the circumstances required to exploit the vulnerability make > exploitation unlikely. Among other requirements, the rebuttal says that > a problem only happens with block sizes larger than 8MB. > > Am I correct to assume that OpenVPN's use of LZO is restricted to much > smaller block sizes? I assume the block sizes that OpenVPN uses LZO for > are limited to the maximum packet size, which would be on the order of > 1500 bytes or so (because of MTU size limits). > > Or does OpenVPN ever use LZO on larger amounts of data? Is there any > possibility of OpenVPN using LZO on 8MB? You are partly correct; OpenVPN parses UDP or TCP packets, which due to fragmentation can become as large as ~65KB. However, this is still within comfortable distance from the 'critical' 8MB boundary for LZ4, and 16MB for lzo. So OpenVPN is not vulnerable. Regards, -Steffan 

Hi, On Sun, Jun 29, 2014 at 12:09:01PM -0400, Jonathan K. Bullard wrote: > Am I correct to assume that OpenVPN's use of LZO is restricted to much > smaller block sizes? I assume the block sizes that OpenVPN uses LZO for are > limited to the maximum packet size, which would be on the order of 1500 > bytes or so (because of MTU size limits). OpenVPN does not use "cross block" decompression state, so yes, only a single packet at a time is decompressed. For UDP, this is obviously below 64kbyte. For TCP, the OpenVPN socket code imposes a maximum length which is based on MTU + overhead (if I understand the code right, it's a bit complicated) and if the TCP stream claims to contain an "OpenVPN packet" larger than that, the session is torn down. > Or does OpenVPN ever use LZO on larger amounts of data? Is there any > possibility of OpenVPN using LZO on 8MB? I do not see any such possibility. > * Also see the discussion on the LZ4 discussion board > <https://code.google.com/p/lz4/issues/detail?id=52>; the vulnerability was > actually discovered by Ludvig Strigeus > <https://en.wikipedia.org/wiki/Ludvig_Strigeus> eighteen months ago. "git master" contains a copy of lz4 in src/compat/, which I intend to update to their fixed-version - not because I think we're vulnerable, but because I want to avoid questions and user irritation ("they are still shipping the vulnerable version!!"). So it might be a good thing to release new bundles with lzo 2.07 anyway... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Am 27.03.14 09:57, schrieb Lev Stipakov: > Hi, > > Same patch with added NULL check in push.c:308. Turns out that > peer_info might be NULL. > I looked at the patched, a few minor nitpicks: - The test should be if the IV_PROTO is at least 2 and not if exactly 2 - use_session_id should be bool instead of int - If I understand the code in ssl.c tls_pre_decrypt corrrectly the ASSERT (buf_advance (buf, op == P_DATA_V1 ? 1 : 4)); will give an asserton if the other side just send a packet with only P_DATA_V2 as op code and no opcode. I have not checked if the addition three bytes cause any mtu related issues. Other than then that the patch looks good. Arne 

A recent *"Lab Mouse Security research blog" entry* <http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html> claimed that a bug exists in several implementations of the LZO algorithm commonly used by OpenVPN and that the bug causes a security vulnerability. A rebuttal on the "RealTime Data Compression" blog <http://fastcompression.blogspot.co.uk/2014/06/lets-move-on.html> points out that the circumstances required to exploit the vulnerability make exploitation unlikely. Among other requirements, the rebuttal says that a problem only happens with block sizes larger than 8MB. Am I correct to assume that OpenVPN's use of LZO is restricted to much smaller block sizes? I assume the block sizes that OpenVPN uses LZO for are limited to the maximum packet size, which would be on the order of 1500 bytes or so (because of MTU size limits). Or does OpenVPN ever use LZO on larger amounts of data? Is there any possibility of OpenVPN using LZO on 8MB? * Also see the discussion on the LZ4 discussion board <https://code.google.com/p/lz4/issues/detail?id=52>; the vulnerability was actually discovered by Ludvig Strigeus <https://en.wikipedia.org/wiki/Ludvig_Strigeus> eighteen months ago. 

Am 26.06.14 13:40, schrieb James Bekkema: > Hi All, > > OpenVPN 2.3.4 will currently throw a warning of "NOTE: setsockopt TCP_NODELAY=1 failed (No kernel support)” when attempting to use the TCP_NODELAY socket option on Mac OS X/Darwin. Kernel support is there, however the required header file where TCP_NODELAY is defined is not being included. This patch simply alters syshead.h to include <netinet/tcp.h> on Darwin platforms. > > > --- src/openvpn/syshead.h.orig	2014-05-01 21:12:22.000000000 +1000 > +++ src/openvpn/syshead.h	2014-06-26 17:43:30.000000000 +1000 > @@ -349,6 +349,14 @@ > > #endif /* TARGET_DRAGONFLY */ > > +#ifdef TARGET_DARWIN > + > +#ifdef HAVE_NETINET_TCP_H > +#include <netinet/tcp.h> > +#endif > + > +#endif /* TARGET_DARWIN */ > + > #ifdef WIN32 > #include <iphlpapi.h> > #include <ntddndis.h> > > > Tested under 10.7 to 10.10dp2. "Socket flags: TCP_NODELAY=1 succeeded” when running with debug enabled. In addition the latest beta version of Viscosity is using a copy of OpenVPN with this patch applied: no issues have been reported from testers thus far. > Ack. Arne 

Thanks. Your patch has been applied to the master and release/2.3 branches. commit b443772bb6fa9177ab015e8b69fbd804cfffee6b (master) commit ce884e284dfa7c4bbdc998391b489d37b5e79e9b (release/2.3) Author: Andris Kalnozols Date: Sat Jun 28 19:45:48 2014 +0200 Fix some typos in the man page. Signed-off-by: Andris Kalnozols <an...@hp...> Acked-by: Steffan Karger <ste...@fo...> Message-Id: <53A...@ka...> Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

ACK to the attached patch, extracted from the 'version 2' patch supplied by Andris Kalnozols in trac ticket #402. Applies to both release/2.3 and master. -Steffan 

Hi All, OpenVPN 2.3.4 will currently throw a warning of "NOTE: setsockopt TCP_NODELAY=1 failed (No kernel support)” when attempting to use the TCP_NODELAY socket option on Mac OS X/Darwin. Kernel support is there, however the required header file where TCP_NODELAY is defined is not being included. This patch simply alters syshead.h to include <netinet/tcp.h> on Darwin platforms. --- src/openvpn/syshead.h.orig	2014-05-01 21:12:22.000000000 +1000 +++ src/openvpn/syshead.h	2014-06-26 17:43:30.000000000 +1000 @@ -349,6 +349,14 @@ #endif /* TARGET_DRAGONFLY */ +#ifdef TARGET_DARWIN + +#ifdef HAVE_NETINET_TCP_H +#include <netinet/tcp.h> +#endif + +#endif /* TARGET_DARWIN */ + #ifdef WIN32 #include <iphlpapi.h> #include <ntddndis.h> Tested under 10.7 to 10.10dp2. "Socket flags: TCP_NODELAY=1 succeeded” when running with debug enabled. In addition the latest beta version of Viscosity is using a copy of OpenVPN with this patch applied: no issues have been reported from testers thus far. Regards, James -- James Bekkema SparkLabs Developer http://www.sparklabs.com http://www.twitter.com/sparklabs su...@sp... 

Hi, On Tue, Jun 24, 2014 at 06:15:20PM +0200, Holger Kummert wrote: > So the vote goes clearly to #defines, right? Yes, please. Not because it's necessarily "better", but because it's what the rest of the code currently uses. (As with all styleguides, personal taste will differ in places... I wouldn't *ever* use this particular indentation style, for example, but "as the code is what it is", we all stick to it... hard enough to maintain, even so). > I'm going to change the code and test it. If it works, the change will > be included in the next patch. Thanks. And I like the way this has become an actual discussion among people that understand NTLM auth :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

ACK. Patch has been applied to the release/2.3 branch. commit f7048855c0f4d1045181cfbc24381c786a9ace31 Author: Steffan Karger Date: Tue Jun 24 22:03:25 2014 +0200 Update README.polarssl Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <140...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8804 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

ACK. Patch has been applied to the master branch. commit 96b9538711789355472607922ab1a0ac6d151367 Author: Steffan Karger Date: Tue Jun 24 22:03:26 2014 +0200 Update README.polarssl Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <140...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8803 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Your patch has been applied to the master and release/2.3 branches. commit e238b806f5f3843b80d5b1b2b269679210faa7f6 (master) commit 991e3574dd9d11dac61b302377b29d24a46b89b1 (release/2.3) Author: Steffan Karger Date: Fri Apr 25 10:41:17 2014 +0200 Fix bug that incorrectly refuses oid representation eku's in polar builds Signed-off-by: Steffan Karger <ste...@fo...> Acked-by: David Sommerseth <da...@us...> Message-Id: <139...@fo...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8627 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

PolarSSL support has been extended and adjusted, but README.polarssl was not accordingly adjusted. This updates README.polarssl to the current state of affairs for the master branch. Signed-off-by: Steffan Karger <st...@ka...> --- README.polarssl | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.polarssl b/README.polarssl index ab7c2d7..6f1fa51 100644 --- a/README.polarssl +++ b/README.polarssl @@ -7,7 +7,7 @@ To Build and Install,	make	make install -This version depends on at least PolarSSL v1.1. +This version depends on PolarSSL 1.3 (and requires at least 1.3.3). ************************************************************************* @@ -17,12 +17,10 @@ in the PolarSSL version of OpenVPN: * PKCS#12 file support * --capath support - Loading certificate authorities from a directory * Windows CryptoAPI support - * Management external key support * X.509 alternative username fields (must be "CN") Plugin/Script features: - * X.509 Serial number is in hex, not decimal as with OpenSSL * X.509 subject line has a different format than the OpenSSL subject line * X.509 certificate export does not work * X.509 certificate tracking -- 1.9.1 

PolarSSL support has been extended and adjusted, but README.polarssl was not accordingly adjusted. This updates README.polarssl to the current state of affairs for OpenVPN 2.3. Signed-off-by: Steffan Karger <st...@ka...> --- README.polarssl | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.polarssl b/README.polarssl index ab7c2d7..06f30bf 100644 --- a/README.polarssl +++ b/README.polarssl @@ -7,7 +7,7 @@ To Build and Install,	make	make install -This version depends on at least PolarSSL v1.1. +This version depends on PolarSSL 1.2 (and requires at least 1.2.10). ************************************************************************* @@ -17,12 +17,10 @@ in the PolarSSL version of OpenVPN: * PKCS#12 file support * --capath support - Loading certificate authorities from a directory * Windows CryptoAPI support - * Management external key support * X.509 alternative username fields (must be "CN") Plugin/Script features: - * X.509 Serial number is in hex, not decimal as with OpenSSL * X.509 subject line has a different format than the OpenSSL subject line * X.509 certificate export does not work * X.509 certificate tracking -- 1.9.1 

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 

 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? > > 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.). > > 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). > > 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. > > 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. > > > 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 ... > > 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 :) > Best regards, Holger 

 So the vote goes clearly to #defines, right? I'm going to change the code and test it. If it works, the change will be included in the next patch. Best regards, Holger Am 18.06.2014 23:07, schrieb David Sommerseth: > I see and understands the arguments for using static const, and it > surely have it's advantages. However, the OpenVPN code base, which > dates back over a decade, has used the #define approach. This is > probably one of the really few things where the code base is quite > consistent. I prefer that we try to be somewhat consistent with what > most of the already existing code uses. > > Even though the coding style can be quite inconsistent in parts of the > code base, I prefer that we don't add more inconsistency. > > If we at some point find the advantages with static const to really be > superior to #define, then we should switch most of the code base to that > style. But that's a different discussion, as this just as well requires > compatibility testing with preprocessors and compilers across several > platforms. > > 

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 Dav...@in... Intel Corporation 

Hi, On Mon, Jun 23, 2014 at 12:12:38PM +0100, David Woodhouse wrote: > > Another side effect is that if the TAP Windows driver is being > > initialized with 255.255.255.255 netmask then there's no way > > to convince windows to route packets through that interface. > > If this isn't considered a bug in the Windows tap driver, (and I suspect > it isn't, because they're working around some true horridness in the > Windows network stack), Well, for Windows, a tap interface is an ethernet interface in good standing - and not a point-to-point thing like a tun on other platforms where there really is no "subnet" but "my IP, and what's on the other side". So, as you can't put 255.255.255.255 on normal ethernet interfaces, you can't do that on the tap driver either. I'm not sure whether .254 would work - which is why OpenVPN's net30 always wasted a /30 in the old days, or uses a larger subnet now. There is not very much we can do to "fix" that in the tap driver, especially as the ifconfig is done outside the driver in the generic IP part of the stack... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On Tue, 2014-05-27 at 09:44 +0200, Aleksandar Kanchev wrote: > inet_aton("255.255.255.255") would fail on windows which would > result of the script variable INTERNAL_IP4_NETMASK not being set. That should be fixed by http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/d8b7da1a What is the config you get from the server? You have a VPN address/netmask of a single Legacy IP address and 255.255.255.255, which would basically leave you routing *nothing* to the VPN, and then you have a set of routes to add to that? > Another side effect is that if the TAP Windows driver is being > initialized with 255.255.255.255 netmask then there's no way > to convince windows to route packets through that interface. If this isn't considered a bug in the Windows tap driver, (and I suspect it isn't, because they're working around some true horridness in the Windows network stack), then I think it's better to localise it to our tun-win32.c with something like the following: diff --git a/tun-win32.c b/tun-win32.c index 102a7d0..b9ac163 100644 --- a/tun-win32.c +++ b/tun-win32.c @@ -169,6 +169,10 @@ static intptr_t open_tun(struct openconnect_info *vpninfo, char *guid, char *nam	data[0] = inet_addr(vpninfo->ip_info.addr);	data[2] = inet_addr(vpninfo->ip_info.netmask); +	/* Ick. The Windows tap driver (or network stack) cannot cope with a netmask + of 255.255.255.255. */ +	if (data[2] == 0xffffffff) +	data[2] = htonl(0xfffffffe);	data[1] = data[0] & data[2];	if (!DeviceIoControl(tun_fh, TAP_IOCTL_CONFIG_TUN, -- David Woodhouse Open Source Technology Centre Dav...@in... Intel Corporation 

ACK. Your patch has been applied to the master branch. commit d0483476d047b4afc671e205bdfdb5b7f56ce48c (master) Author: Steffan Karger Date: Sun Jun 22 20:18:39 2014 +0200 configure.ac: fix SSL_OP_NO_TICKET check Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <140...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8795 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Only check for SSL_OP_NO_TICKET if building with --enable-ssl and using openssl. This fixes cross-compiling polarssl builds for Windows (where pkg-config would find the system openssl library, but the cross compiler would not have openssl for the target platform). Signed-off-by: Steffan Karger <st...@ka...> --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6f405ea..11b68c3 100644 --- a/configure.ac +++ b/configure.ac @@ -807,7 +807,8 @@ if test "${have_openssl_crypto}" = "yes"; then	LIBS="${saved_LIBS}" fi -if test "${have_openssl_ssl}" = "yes"; then +if test "${enable_ssl}" = "yes" && test "${with_crypto_library}" = "openssl"; +then saved_CPPFLAGS="${CPPFLAGS}" CPPFLAGS="${CPPFLAGS} ${OPENSSL_CRYPTO_CFLAGS}" AC_MSG_CHECKING([for SSL_OP_NO_TICKET flag in OpenSSL]) -- 1.9.1 

Your patch has been applied to the master and release/2.3 branches. commit 4978dadaed4ecf1b9dd256f57c6a5c895691580b (master) commit 488994b3f65242ec31b015f53e21d935f75b8bee (release/2.3) Author: David Sommerseth Date: Fri May 2 02:28:24 2014 +0200 Improve error reporting on file access to --client-config-dir and --ccd-exclusive Trac-URL: https://community.openvpn.net/openvpn/ticket/277 Signed-off-by: David Sommerseth <da...@us...> Acked-by: Steffan Karger <ste...@fo...> Message-Id: <139...@us...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8688 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering