Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Wed, 2017-07-26 at 11:16 +0200, David Sommerseth wrote: > On 26/07/17 10:02, David Woodhouse wrote: > [...snip...] > > > > > > Well yes, that's true. But it's more likely that I'll finally get round > > to porting OpenVPN to something oth

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Tue, 2017-07-25 at 23:56 +0200, Emmanuel Deloget wrote: > A single patch would not a a problem for distro maintainers, but > subsequent/future changes in the forked repository might introduce > other, less compatible changes in the library, leading to two versions > of the same library, with may

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Tue, 2017-07-25 at 19:53 +0300, Samuli Seppänen wrote: > > I released the new Windows installer but without this patch. That said, > the patch/PR you linked to makes sense. Does the patch have an active > maintainer? That would be me, I suppose. Until/unless the upstream maintainer applies th

Re: [Openvpn-devel] iOS key decrypts

On Wed, 2017-07-19 at 12:46 +0200, Steffan Karger wrote: > Hi, > > On 18-07-17 17:46, Gregory Sloop wrote: > > > > Does anyone know definitively what key encryptions/decryptions the iOS > > client will properly handle? [And if there's any difference using unfied > > vs non-unified setups.] > The

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Fri, 2017-07-14 at 17:07 +0300, Samuli Seppänen wrote: > Hi all, > > Those of you who use pkcs11 on Windows: could you please test this new > Windows installer: > > > > The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so > some regression testing would be good to have. P

Re: [Openvpn-devel] [PATCH 0/2] LZ4 updates

On Thu, 2016-12-15 at 21:20 +0100, David Sommerseth wrote: > > There is also another potential issue with the current approach, if we link > against r129 or older ... the code will be using > LZ4_compress_limitedOutput().  If the system library is upgraded to a newer > upstream version which final

Re: [Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

On Thu, 2016-12-15 at 14:26 +0100, Christian Hesse wrote: > -    zlen = LZ4_compress_limitedOutput((const char *)BPTR(buf), (char > *)BPTR(work), BLEN(buf), zlen_max ); > +    zlen = LZ4_compress_default((const char *)BPTR(buf), (char > *)BPTR(work), BLEN(buf), zlen_max ); You might want

Re: [Openvpn-devel] p2p topology on Windows

On Fri, 2016-09-30 at 10:11 +0200, Jan Just Keijser wrote: > > I'm still grappling for the "killer use case" for this - yes, it would be > nice to implement support on all platforms for all > modes, **BUT** I don't think anybody actually uses 'topology p2p' at this > moment (because Windows cli

Re: [Openvpn-devel] p2p topology on Windows

On Mon, 2016-09-26 at 13:34 +0200, Jan Just Keijser wrote: > > this sounds like a typical use case for "assign a public IP address". > This is already possible with topology subnet and some special config > stuff on the server side, e.g. > - give the openvpn server an IP range that overlaps with

Re: [Openvpn-devel] p2p topology on Windows

On Sun, 2016-09-25 at 16:40 +0200, Jan Just Keijser wrote: > > thanks for clarifying - but with OpenVPN 2.4 the default topology mode  > will be 'subnet topology', in which we also assign a single IP address  > to each client. Is there a (fundamental) difference between these two? Subnet topology

Re: [Openvpn-devel] p2p topology on Windows

On Sat, 2016-09-24 at 00:01 +0200, Jan Just Keijser wrote: > > sorry for asking, but what's the use case for this? The use case for point-to-point? It allows you to use a single IP address per client instead of having to set aside a whole /30 subnet per client as with the 'net30' mode. (And in m

[Openvpn-devel] p2p topology on Windows

I believe I have P2P working on a Windows (8.1) client (with OpenConnect, but I don't see why it can't work for OpenVPN). I configure the TAP device (with TAP_IOCTL_CONFIG_TUN) with the local IP address, and with network and netmask both of 0.0.0.0. (AIUI this network/mask has nothing to do with

Re: [Openvpn-devel] Fixing non-standard PKCS#11 serialization format using a patched pkcs11-helper?

On Tue, 2016-08-30 at 11:11 +0300, Samuli Seppänen wrote: > > >> With that in mind, if shipping a patched pkcs11-helper in Windows > >> makes your life easier I'd consider doing this.  But step carefully, > >> avoid getting in a situation where you suddenly have to maintain these > >> patches your

Re: [Openvpn-devel] Fixing non-standard PKCS#11 serialization format using a patched pkcs11-helper?

On Mon, 2016-08-29 at 21:55 +0200, David Sommerseth wrote: > There have been some proposals to ditch pkcs11-helper and rather use a > newer and more compliant library instead (p11-kit). I think this > makes more sense, to be honest. There are more issues with > pkcs11-helper which upstream seems

Re: [Openvpn-devel] [RFC] - Enable 2FA to be used with renegotiations

On Thu, 2016-08-25 at 15:45 +0200, David Sommerseth wrote: > > > I've been working a bit on a new patch-set which enables third-party > user/password authentication mechanisms using two factor > authentications [2FA] (such as OTP) and not needing to disable the > renegotiation features of OpenVPN

Re: [Openvpn-devel] [PATCH] Change timestamps to POSIX format.

On Fri, 2016-08-12 at 23:02 +0200, Gert Doering wrote: > This is a good argument.  Unfortunately, it's a surprisingly *hairy* one, > as there are time zones that do not have a full-hour offset - so ISO 8601 > (according to wikipedia) says you should do "±hh:mm" then - and for > most folks, ":mm" wo

Re: [Openvpn-devel] [PATCH] Change timestamps to POSIX format.

On Thu, 2016-08-11 at 21:23 +0200, Gert Doering wrote: > All our timestams used to be "what ctime()" produces, which is > >   "Thu Aug 11 21:15:27 2016" > > Changed to use POSIX standard format, which is > >   "2016-08-11 21:15:27" While you're at it, perhaps also add the timezone in numeric (±

Re: [Openvpn-devel] Windows installer with SHA-256 signatures ready for testing

On Mon, 2016-03-14 at 14:18 +0200, Samuli Seppänen wrote: > > >> > > > > Is there a link to the corresponding grub bug? In an ideal world, > > things like the above would never be posted *without* such a link. But > > I suppose we don't necessarily

Re: [Openvpn-devel] Windows installer with SHA-256 signatures ready for testing

On Thu, 2016-03-10 at 16:34 +0200, Samuli Seppänen wrote: > > A second problem should be limited to Windows 7 and Windows Server 2008  > R2 installations that are booted through a non-Windows bootloader (e.g.  > grub): > > Is there a link to the c

Re: [Openvpn-devel] Pushing multiple certificates from server

On Fri, 2016-03-04 at 15:37 +0300, ValdikSS wrote: > Thanks for the information. It definitely doesn't work for any > certificate, probably only for chained certificates. What you described *was* chained certificates, wasn't it? From the point of view of a client which only trusts the old CA, the

Re: [Openvpn-devel] Always including tap-windows6, openvpn-gui and easy-rsa in openvpn-build -generated Windows installers?

On Tue, 2016-02-16 at 15:12 +0200, Samuli Seppänen wrote: > Hi, > > Currently openvpn-build allows producing installers which do not  > _contain_ tap-windows6, openvpn-gui or easy-rsa at all. On top of this  > one can - at install time - select which of the contained components are  > intalled. >

Re: [Openvpn-devel] XP broken (wrt IPv6 in 2.3.9)

On Sat, 2015-12-26 at 10:35 +0100, Gert Doering wrote: > but, unfortunately, it is not available in MinGW. Point of order: this is the kind of statement which should normally never be seen without an explicit reference to a filed bug. In this case, however, I think it was fixed without a bug ev

Re: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

On Tue, 2015-11-17 at 22:55 -0500, Selva Nair wrote: > > The only complication is you need openssl built for the target > (windows) -- I have this cross-compiled from source and installed in > $HOME/windows/ There are some tutorials out there on how to cross- > compile openssl. If you're building

Re: [Openvpn-devel] [RFC] --passtos default on/off, and IPv6.

On Mon, 2015-10-26 at 00:15 +0100, Steffan Karger wrote: > On Mon, Oct 26, 2015 at 12:09 AM, Steffan Karger wrote: > > For > > covert channels, it means 23 possible values per 1500-byte packet, or > > ~5 bits for BF, and 12 possible values (~4 bits) for AES-CBC. That is > > still less than the 8 b

[Openvpn-devel] [RFC] --passtos default on/off, and IPv6.

Since I seem to have accidentally come out of lurk mode anyway... Someone has submitted a patch for OpenConnect¹ to implement something very much like OpenVPN's --passtos option. I prefer to remain consistent with OpenVPN and other tools where possible, so we've renamed the option to '--passtos'

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 16:17 +0200, Gert Doering wrote: > Hi, > > On Thu, Oct 22, 2015 at 03:09:57PM +0100, David Woodhouse wrote: > > So Olli and Lev would appear to be saying. For OpenConnect I > > haven't > > actually tested this hypothesis. Unfortunately I&#

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:59 +0200, Gert Doering wrote: > hi, > > On Thu, Oct 22, 2015 at 02:55:44PM +0100, David Woodhouse wrote: > > > So what is the underlying issue here? Non-ASCII characters in the > > > device name ("this *should* have been fixed a few rele

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:51 +0200, Gert Doering wrote: > Hi, > > On Thu, Oct 22, 2015 at 04:47:56PM +0300, Olli Männistö wrote: > > Many VPN providers like us experience these issues and have to give users > > workarounds to fix it. Here are couple of examples: > > https://community.f-secure.com/t

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:26 +0200, Gert Doering wrote: > > NAK on that - it's extra code, another "two branches that need testing" > addition, and I have not seen any mention of these "weird issues" yet - > so please explain the problem scenario better. > > (I might be happy to go for "use adapte

Re: [Openvpn-devel] Provide a socks5 server port for user apps to use

On Thu, 2015-07-09 at 19:05 -0400, grarpamp wrote: > Having not found this feature and being unfamiliar I'll post > it here simply as FYI for any interested parties. Thanks :) > https://community.openvpn.net/openvpn/ticket/577 http://permalink.gmane.org/gmane.network.openvpn.devel/8478 -- dwmw2

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 00:57 +0300, Alon Bar-Lev wrote: > http://lists.gnu.org/archive/html/gnutls-devel/2011-10/msg00058.html That thread is interesting; thanks for the reference. In it, Stef pointed out¹ that the behaviour of automatically calling C_Initialize() from the atfork child handler is

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 01:09 +0300, Alon Bar-Lev wrote: > > > If an application *knows* that it will never use PKCS#11 after a fork(), > > as in this case where we *know* that we're always just going to exec > > something else, it certainly doesn't *damage* the well-behaved providers > > if we simp

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 00:57 +0300, Alon Bar-Lev wrote: > Are you sure you want to introduce security issues resulting of > resource leak into the child process? Example: pcsc-lite socket that > is leaking or USB connection? In a way for the child process thus it > being able to access the card? Th

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sat, 2015-05-09 at 12:17 +0200, Gert Doering wrote: > Hi, > > On Sat, May 09, 2015 at 07:55:56AM -0000, David Woodhouse wrote: > > A better approach would probably be to disable the atfork handlers in > > OpenVPN entirely since I believe we don't need them. > &

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

> >> I've spent my evening reading more about vfork() and fork(). I've based >> my trust this time in two books [1] on Linux system programming. >> >> Both books are really clear that vfork() should be avoided, and even >> claiming it was a mistake by introducing that syscall in Linux. Its >> se

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

> I've spent my evening reading more about vfork() and fork(). I've based > my trust this time in two books [1] on Linux system programming. > > Both books are really clear that vfork() should be avoided, and even > claiming it was a mistake by introducing that syscall in Linux. Its > semantic c

Re: [Openvpn-devel] [PATCHv2 0/4] Reworking the interface for querying users

On Wed, 2015-05-06 at 22:06 +0200, David Sommerseth wrote: > > All patches has been tested locally with different configurations, > requiring username, password and passphrases to PKCS#12 files. The > challenge/response interface has not been tested, as well as PKCS#11. > All runs via valgrind sh

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sat, 2015-05-02 at 01:54 +0300, Alon Bar-Lev wrote: > what is specified explicitly in PKCS#11 spec must be applied by > providers, there is no room for interpretation in this specific case. > > > From the OpenVPN point of view, actually there's a cheap trick which > > can let us call it Someone

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

=0x0) at misc.c:1146 #9 0x7f26e8ffcfc8 in get_user_pass (flags=21, prefix=0x7ffdb20ca980 "PIV_II (PIV Card Holder pin) token", auth_file=0x0, up=0x7ffdb20c8970) at misc.h:272 #10 _pkcs11_openvpn_pin_prompt (global_data=, user_data=, token=, retry=, pin=0x7ffdb20cadf0 "@\

[Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

we're about to call execve() and it doesn't matter, and the atfork handlers don't get called for a vfork(). Signed-off-by: David Woodhouse Trac #538 diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c index 5627cb9..ec14fbc 100644 --- a/src/openvpn/misc.c +++ b/src/openvpn/misc.c

Re: [Openvpn-devel] [PATCH] Remove useless dash escapes from the man-page

On Wed, 2015-04-29 at 23:30 +0200, Gert Doering wrote: > Hi, > > On Wed, Apr 29, 2015 at 08:33:02PM -0000, David Woodhouse wrote: > > > That would mean we either go into autoconf territory to test for groff > > > run-time behaviour, or we use a particular unique sequenc

Re: [Openvpn-devel] [PATCH] Remove useless dash escapes from the man-page

> That would mean we either go into autoconf territory to test for groff > run-time behaviour, or we use a particular unique sequence and do our > own post-processing. The latter is baaically the approach I took in http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5f15c83f2 -- dwm

Re: [Openvpn-devel] [PATCH] Remove useless dash escapes from the man-page

On Tue, 2015-03-31 at 09:19 +0200, Matthias Andree wrote: > I am concerned this will cause misformattings and inability to search > for options with leading dashes on some systems - I don't recall > versions, but I do know that some systems used some sort of Unicode > (soft?) hyphen for a simple no

Re: [Openvpn-devel] Where to find tap-win32 documentation?

See http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob/HEAD:/vpnc-script-win.js#l166 Btw, Gert, your mailer managed to obliterate '成' (=?UTF-8?B?5oiQ?=) in the To: header of your reply and turn it into '???'. -- David WoodhouseOpen Source Te

Re: [Openvpn-devel] [PATCH v3] Mac OS X Keychain management client

On Mon, 2015-02-23 at 13:59 +0100, Arne Schwabe wrote: > > All fine. My rationale was like, if I want a certificate with a certain > SUBJECT (e.g. CN=schw...@mycoolca.com) etc. it should not matter for men > wether I get it from OS X, Windows or Android Certificate store. The canonical way of rep

Re: [Openvpn-devel] [PATCH v3] Mac OS X Keychain management client

chain :) It might also be worth looking to see if the URI format we're using for the macos-keychain: URIs could be made more similar to the PKCS#11 URI standard. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [Openvpn-devel] the XOR obfuscation

On Wed, 2015-02-04 at 04:41 +0800, 李夏润 wrote: > + size_t keylen = sizeof(key); Perhaps you meant that to be strlen(key), and the problem isn't really that one peer is big-endian, but that sizeof(char *) is different between the two. -- dwmw2 smime.p7s Description: S/MIME cryptographic signatu

Re: [Openvpn-devel] [PATCH] Add more dash escaping to the man page

On Mon, 2015-01-26 at 10:38 +0200, sam...@openvpn.net wrote: > From: Alberto Gonzalez Iniesta > > This patch continues the work started in commit 886593ac4ae ("The man page > needs > dash escaping in UTF-8 environments"). This patch is one of the patches > included > in Debian's OpenVPN package

Re: [Openvpn-devel] [PATCHv2] Mac OS X Keychain management client

On Mon, 2015-01-12 at 13:54 +0100, Arne Schwabe wrote: > I wonder why only certifcates and not ca certifcates. It would be > logical to get all certifcates from the keychain. Yes, that makes some sense. Although perhaps it should be the other way round — you present the peer's cert to the manageme

Re: [Openvpn-devel] [PATCHv2] Mac OS X Keychain management client

supporting key types other than RSA by now. But I appreciate that's not a new limitation and not your fault. It would be interesting to get feedback from those working on NetworkManager-openvpn, which may well want to use this API to allow key operations to happen in the user's session wh

Re: [Openvpn-devel] [PATCH] Add Mac OS X keychain support

On Mon, 2015-01-05 at 13:22 +0300, Vasily Kulikov wrote: > > I see 4 possible alternatives here: > 1) implement keychain rsa offloading in Tunnelblick > 2) make my patch use plugin interface > 3) implement external daemon that communicated with openvpn process via > management interface > 4) the s

[Openvpn-devel] [PATCH 2 v3] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Trac: 490 Signed-off-by: David Woodhouse --- v2: Nicer error message if no provider given when there's no default. v3: Get the usage messages the right way round (s/ifndef/ifdef). I did look at cleaning it up to stop looking at p[2] even when p[1] isn't set, but it makes it som

[Openvpn-devel] [PATCH 2 v2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Following on from the previous patch, this fixes --show-pkcs11-ids too. Trac: 490 Signed-off-by: David Woodhouse --- As I compose the email, I spot that we're actually now looking at the value of p[2] even when p[1] is NULL. So if the add_option() function is supposed to be treating p[]

Re: [Openvpn-devel] [PATCH 2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

On Tue, 2014-12-16 at 22:19 +0100, Steffan Karger wrote: > > Since this makes a '--show-pkcs11-ids' without the module argument > valid > for some openvpn builds, I think it is nicer to give a proper error > message to the user. E.g. something like: Like this? If this incremental patch is what yo

[Openvpn-devel] [PATCH 2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Following on from the previous patch, this fixes --show-pkcs11-ids too. Trac: 490 Signed-off-by: David Woodhouse --- doc/openvpn.8 | 8 +++- src/openvpn/options.c | 21 - 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn

[Openvpn-devel] [PATCH] pkcs11: Load p11-kit-proxy.so module by default

If the user specifies --pkcs11-id or --pkcs-id-management but neglects to explicitly provide a --pkcs11-provider argument, and if the system has p11-kit installed, then load the p11-kit proxy module so that the system-configured tokens are available. Trac: 490 Signed-off-by: David Woodhouse

[Openvpn-devel] TAP-Windows MTU issues

It looks like on Windows, OpenVPN ignores the MTU it's supposed to be using and just queries the TAP driver for its MTU. I suspect this was done in the past because there was no way to *set* the MTU that Windows was expected to use. That is no longer the case; recent versions of Windows let you d

Re: [Openvpn-devel] Any Windows-based OpenVPN servers available for fixing bug #432?

alk to a windows device driver" thing is magic for me. > > > > gert > > Apparently 2.x is not handling certain tap-windows6 return/error codes > correctly. According to Thomas that is causing several of the issues > we've experienced with tap-windows6. Do you h

Re: [Openvpn-devel] Tap-windows6 (NDIS 6) installer available for testing

On Tue, 2014-04-15 at 19:59 +0300, Samuli Seppänen wrote: > The driver has been tested on Windows 7 64-bit and it "seems to work > ok". If you test this driver please let me know if it works - or if it > does not. I've finally got round to testing this with OpenConnect, also under Windows 7 64-bit

[Openvpn-devel] MTU handling on Windows

On Windows 7 at least you can set the MTU with netsh: netsh interface $PROTO set subinterface $TUNDEV mtu=$MTU store=active Where PROTO is 'ipv4' or 'ipv6' and the others are even more obvious. OpenVPN doesn't appear to do this; it seems to leave the MTU untouched and instead query the TAP driv

Re: [Openvpn-devel] Wanted: NTLM-Testers

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 > > Uni

Re: [Openvpn-devel] Wanted: NTLM-Testers

elcome 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 :)

Re: [Openvpn-devel] [PATCH] cstp: Add workaround for 255.255.255.255 netmask on windows

(data[2] == 0x) + data[2] = htonl(0xfffe); data[1] = data[0] & data[2]; if (!DeviceIoControl(tun_fh, TAP_IOCTL_CONFIG_TUN, -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Int

Re: [Openvpn-devel] TAP adapter detection

On Thu, 2014-04-17 at 17:01 -0400, Greg Toombs wrote: > Found the problem. tun-win32.c:45 - > #define TAP_COMPONENT_ID "tap0901" > > This is only valid for the most recent version of the TAP adapter. For > other versions, this should actually be "tapoas". So openconnect > saying that there are no

Re: [Openvpn-devel] [PATCH 0/3] Support non-root operation using ocproxy

ernel's /dev/net/tun device, I don't see why we'd consider that a violation of the philosophy. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [Openvpn-devel] Failure to configure TAP device under Windows

On Wed, 2014-02-12 at 12:11 +0100, Gert Doering wrote: > > It actually *should* work just fine. Thanks for the response. > I've never used the control panel to set up IPv6 addresses, but using > netsh worked nicely for me (and OpenVPN) - look into the openvpn sources > to see the necessary invo

[Openvpn-devel] Failure to configure TAP device under Windows

I installed OpenVPN on Windows 7 64-bit using openvpn-install-2.3.2-I003-x86_64.exe and ported the OpenConnect VPN client¹ to use the TAP device. It created a TAP device as part of the installation, named 'Local Area Connection 3'. Attempting to configure IP addresses on this device fails thus: C