Here's the summary of the IRC meeting.


Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 4th Apr 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex, plaisthos and tincantech participated in
this meeting.


Noted that ticket "--preresolve is undocumented" belongs to plaisthos:



Discussed upcoming OpenVPN 2.4.6 release. There are two things that need
to be included:

- The security fix to tap-windows6
- The security fix to Windows service

Agreed that the tap-windows6 driver should only have a SHA2 signature.
The current released version has SHA1 signature as well, but that is
only needed on Windows Vista (which we don't support) and some outdated
and unpatched Windows 7 instances (which we don't want to support).
Decided to document this fact instead of catering for users of such old

Agreed to attempt a release in two weeks. This may be realistic,
expecially if the cross-signing the tap-windows6 still works and we
don't have to go through the Windows Hardware Developer Center Dashboard


Discussed "​PATCH: Rework OpenVPN auth-token support":


Plaisthos will rework the patch. Dazo will improve auth token
documentation on the man-page.


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(12:30:13) cron2: meow
(12:30:25) ***dazo barks
(12:30:45) ***cron2 pokes dazo wrt CVE :)
(12:31:18) ***dazo writes it down this time :-)
(12:33:06) mattock: guten tag
(12:33:24) ordex: aloha
(12:33:28) mattock: four people so far
(12:33:32) dazo: dobrý den ;-)
(12:33:33) mattock: anyone else reporting in?
(12:33:49) dazo: Is plaisthos around?
(12:34:13) cron2: haven't seen him, which is a shame (because I just found a 
bug for him)
(12:34:23) mattock: bug you want to bug him about
(12:34:32) dazo: Well, I chatted with him yesterday, so he's around :)
(12:34:40) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-04-04
(12:34:42) vpnHelper: Title: Topics-2018-04-04 – OpenVPN Community (at 
(12:34:48) mattock: any changes/amendments to the topic list?
(12:34:50) cron2: mattock: yes, trac #1049
(12:35:16) mattock: adding
(12:35:38) cron2: nah, that was in reply to "11:34 < mattock> bug you want to 
bug him about"
(12:35:41) cron2: not for the agenda
(12:35:43) cron2: sorry
(12:36:28) mattock: done
(12:36:30) mattock: oh
(12:36:34) mattock: well it is there anyways :D
(12:36:48) dazo: plaisthos should be on his way
(12:36:59) mattock: 2.4.6 first?
(12:37:01) plaisthos: yes here I am am ;)
(12:37:20) cron2: plaisthos: #1049 is yours :)  (and now I won't speak about it 
(12:37:56) mattock: hi!
(12:39:35) dazo: so 2.4.6
(12:39:41) cron2: es
(12:40:00) plaisthos: oh okay
(12:40:02) plaisthos: will do later
(12:40:39) cron2: we have two things that need to go into 2.4.6 - the tap-fix 
and the service fix.  All windows, but since the "service" is part of openvpn 
proper, it has to be a new openvpn release
(12:41:02) cron2: I would suggest a timeline of "now + 2 weeks" - mattock, 
how's your availability?  and how's your signing machine?
(12:42:18) mattock: I should now have access to the signing machine
(12:42:27) mattock: in two weeks is definitely doable
(12:42:38) mattock: question:
(12:42:40) mattock: or two
(12:43:08) mattock: the current tap-windows6 driver has dual signatures (SHA1 
and SHA2)
(12:43:28) mattock: the former is required for Windows Vista and some very 
obsolete Windows 7 versions
(12:43:32) mattock: I believe pre-SP1
(12:44:23) mattock: should we just drop the SHA1 signatures and tell those 
users to install some MS updates?
(12:44:26) cron2: We do no longer support Vista, and I can test on a 
fully-patched Win7 - this is what we support, unpatched and old versions not
(12:44:32) cron2: "yes"
(12:44:43) mattock: I would prefer that, as dual signatures are a true pain to 
do right
(12:44:46) cron2: (unless it is trivial to do both, but since you are asking I 
guess it's annoying)
(12:44:48) cron2: right
(12:45:39) mattock: the signatures need to be in the right order, and there has 
to be a planetary conjunction at the same time
(12:45:53) dazo: agreed .... we generally limit our OpenVPN support on any OS 
supported by the OS provider .... so unpatched/out-of-date Windows versions 
does not require us to support un-updated Win7
(12:46:18) mattock: also, if we don't drop SHA1 support we can't really tell if 
people really need it
(12:46:35) mattock: be can always backpedal if SHA2-only becomes a real issue 
(12:46:39) dazo: and then we can't tell them to upgrade their Windows ;-)
(12:46:59) mattock: we can try telling the to upgrade their Windows first
(12:47:16) mattock: then, when they send ten bullet points explaining why they 
can't and why that is perfectly fine, we can backpedal :)
(12:47:44) mattock: anyways, let's try SHA2-only
(12:47:57) dazo: yeah ... running an OS not updated can even put the OpenVPN 
usage on risk ... if they're willing to run out-of-date Windows, they can 
handle out-of-date OpeNVPN
(12:47:58) mattock: cron2: did you have time to build tap-windows6 and test the 
(12:48:06) mattock: dazo: agreed
(12:51:49) cron2: mattock: as I can't sign, I was hoping for yours...  (and I 
got distracted by holidays and kids and stuff)
(12:54:19) cron2: so... we need a CVE to go ahead, I'll do patches and do 
proper "send-email" and PR'ing...
(12:54:40) cron2: do we want to include the patch from viscosity(?) about the 
bandwidth change?  It seems reasonable to do...
(12:55:25) mattock: I have a nagging suspicion that we may have to sign the 
tap-windows6 driver using the horrible MS portal thingy
(12:55:31) mattock: which probably means delays
(12:55:43) mattock: the cross-certificate used for signing may have expired, 
have to check
(12:55:48) cron2: speaking of "hours", or "days"?
(12:56:09) mattock: well we can test the patch with an unsigned driver in test 
(12:56:28) mattock: but as for signing: depends on people at the office and 
(12:56:52) mattock: the original deadline (two weeks) _may_ be doable, if 
things go fast 
(12:57:04) cron2: let's aim for that, and recalibrate next week if needed
(12:57:06) mattock: I will send internal email about this today
(12:57:10) dazo: agreed
(12:57:38) cron2: maybe someone inside is also interested in this, given that 
tap-windows6 is part of the connect client for windows :-)
(12:57:44) cron2: (and can help review and maybe even test)
(12:59:00) mattock: lol there is nobody else foolish enough to play with driver 
signing in WindowS :D
(12:59:13) cron2: more along the lines of "review and test"
(12:59:14) mattock: they always ask me to build the drivers
(12:59:28) mattock: I can definitely send the signed driver for internal testing
(12:59:35) mattock: that they've done in the past with good success
(13:00:21) mattock: anything else on 2.4.6?
(13:02:21) dazo: nah, I think that's fine .... 2.4.6 will be a small and cute 
update compared to other releases, but still important
(13:02:41) ordex: very cute :P
(13:02:50) cron2: maybe we can include https://patchwork.openvpn.net/patch/276/ 
(13:02:52) vpnHelper: Title: [Openvpn-devel] Depreciate IPv4-related options. - 
Patchwork (at patchwork.openvpn.net)
(13:02:55) ordex: :D
(13:04:23) plaisthos: lol :)
(13:04:29) dazo: :-D
(13:04:33) plaisthos: you need someone to review and ack
(13:04:58) dazo: cron2: lets co-ordinate such stunts better next year, so we 
can have the ACK and "applied" mails rolling as well ;-)
(13:05:14) cron2: dazo: coordination is hard when everybody goes hiding :)
(13:05:20) cron2: but that would have been fun indeed
(13:05:46) cron2: topic #2 -> plaisthos/dazo
(13:05:50) dazo: mattock: ^^^^those lines above should be removed from the 
chatlog and not be mentioned in the minutes! :-P
(13:06:08) james [ca99d44e@gateway/web/freenode/session] è entrato nella stanza.
(13:06:12) mattock: wrong day, otherwise I would agree :)
(13:06:23) mattock: we need to coordinate better next year
(13:06:31) james è ora conosciuto come Guest91582
(13:07:19) dazo: about #2 ... yeah, we need to get this fixed ... but I'm not 
happy about the the new pushable option "forget-token" .... especially when we 
have a possibility in the AUTH_FAILED message to provide a reason
(13:07:30) dazo: openvpn2 just needs to get more clever about that
(13:08:25) dazo: but getting the authentication code paths to submit the 
reason, is a harder task ... as the AUTH_FAILED message is sent outside of that 
(13:08:54) dazo: and send_control_message() (or what it is called, too lazy to 
check) requires quite some more global scope structs currently
(13:09:59) plaisthos: dazo: I am also okay to have a pushable option for the 
other way round, that says "keep auth-token" after reconnect
(13:10:06) dazo: I tried a refactoring a long time ago, providing those structs 
into the places where we would send AUTH_FAILED for the auth-token failures ... 
but syzzer disagreed to that approach, and his reasoning is fair and accepted
(13:10:28) plaisthos: I was just a bit more worried about breaking existing 
(13:10:39) dazo: plaisthos: remember that we need to consider this also for AS 
servers with OpenVPN Connect clients
(13:11:05) dazo: and then we have community servers using OpenVPN Connect 
clients ..... which requires adding similar features to OpenVPN 3
(13:11:31) plaisthos: dazo: I don't see your point
(13:11:45) cthuluh_ [~j...@chomsky.autogeree.net] è entrato nella stanza.
(13:11:46) dazo: adding new options should be the absolute last solution .... 
as OpenVPN 3 clients can handle the AUTH_FAILED reason messages
(13:12:04) dazo: and that works with AS servers today
(13:12:18) ordex: how is that "reason" sent back in the ovpn3 context?
(13:12:26) plaisthos: it is not 
(13:12:37) plaisthos: openvpn3 just *always* forgets auth-token on reconnect
(13:12:50) plaisthos: openvpn2 currently *never* forgets auth-token
(13:12:53) dazo: it's just openvpn2 client side and community servers doing 
auth outside of the management interface (the majority I'd say) which fails to 
handle this
(13:13:26) dazo: so, then we should consider to make openvpn2 behave similarly
(13:14:19) dazo: ordex: AUTH_FAILED is sent as a push message .... with reason 
it is something like:  AUTH_FAILED,SESSION: Authentication expired, please 
(13:14:33) ordex: oh ok
(13:14:45) plaisthos: but current behaviour of openvpn2 is desirable if you 
have users if OTP and don't want them not to reauthenticate on every network 
(13:14:58) plaisthos: (if you have the right server side script)
(13:15:24) dazo: that's true
(13:15:58) cthuluh ha abbandonato la stanza (quit: *.net *.split).
(13:16:33) dazo: Actually, what I'm saying is that we shouldn't invent 
something unique to OpenVPN 2 ... we need to consider OpenVPN 3's behaviour as 
well and ensure the user experience is equally good - regardless of the server 
or client being used
(13:17:26) ordex: maybe I lack some background on this, but why are we mixing 
"Sending back a reason for auth-failed" and the token being forgotten 
behaviour? are they both trying to address the same bad user experience?
(13:17:54) plaisthos: Yeah, but aligning openvpn2 completely with openvpn3 
removes that features from openvpn2
(13:18:10) plaisthos: implementing the auth-failed support in openvpn2 is not a 
(13:18:22) dazo: so we need to find a path forward which covers both versions
(13:18:31) plaisthos: (for client side at least)
(13:19:00) plaisthos: lets concentrate on client side for now 
(13:21:50) plaisthos: first we have to decide if we want to keep this feature 
of openvpn2 or not
(13:22:29) plaisthos: then we have to decide if want it default on 
(=forget-auth-token) or default off (align with openvpn3, add pushable 
keep-auth-token option)
(13:23:56) plaisthos: In the past we always erred on keeping compatibility, so 
that was the approach I have chosen for my initial patch
(13:25:41) dazo: I'm more concerned about user experience than features on the 
client side.  And that whatever feature we have on the client side does not 
make things worse - regardless of the server being used (openvpn community, AS, 
PrivateTunnel).  And vice versa, servers should not behave worse than today, 
regardless of client being used
(13:26:29) dazo: Perhaps we need to get James into this discussion ... as he 
can see things from a broader perspective more easily
(13:27:56) plaisthos: any solution has a better user experience on 2.x than we 
what we have today
(13:28:19) Guest91582 ha abbandonato la stanza (quit: Changing host).
(13:28:20) Guest91582 [ca99d44e@gateway/web/freenode/ip.] è 
entrato nella stanza.
(13:29:11) plaisthos: atm: auth-token on server => 2.x client disconnected => 
client never reconnects
(13:29:45) ordex: it depends on the logic implemented on the server side, no? 
or are you talking about auth-gen-token?
(13:29:49) dazo: you mean with auth-gen-token servers?  or any auth 
script/module on 2.x server which pushes auth-token?
(13:30:42) plaisthos: anything that pushes auth-token that does not keep them 
valid forever
(13:31:35) dazo: I do see that the current implementation of --auth-gen-token 
is not ideal ... it deletes the token in reconnect situations where it should 
(13:32:02) dazo: but it should be possible to expire tokens, in which the 
client side needs to get a reason why re-auth is needed
(13:32:04) cron2: from what I understand from plaisthos' description, it seems 
to *not* delete the token on reconnect, so it loops on "AUTH FAILED" (or just 
gives up)
(13:32:17) cron2: so, as soon as the token expired, the client is dead
(13:32:20) cron2: right?
(13:32:21) dazo: it does not delete it on the client isde
(13:32:27) dazo: yeah
(13:32:36) plaisthos: right
(13:33:16) dazo: and that's why we need to have a reason to the client ... 
"AUTH_FAILED,SESSION: Authentication expired, please reauthenticate" in these 
cases .... expired tokens is not necessarily a wrong state
(13:33:37) dazo: and then we need to fix auth-gen-token to not invalidate valid 
tokens on normal reconnects (changing networks, whatever)
(13:34:11) plaisthos: but your second statement would only help old openvpn2 
(13:34:31) plaisthos: since openvpn3 will never try to use the token on normal 
(13:34:39) dazo: we need to fix both
(13:34:46) plaisthos: okay
(13:34:47) dazo: and I'm not saying openvpn3 isn't bug free :)
(13:34:58) plaisthos: okay :)
(13:35:30) dazo: and whatever external auth scripts/plug-ins does ... that's up 
to them ... but it should also be possible for them to provide a reason as well 
.... re-using the "please reauthenticate" should then query the user for 
credentials again
(13:35:50) plaisthos: Would a minimal patch version for openvpn2 be an option 
for now until we figure out what we really?
(13:36:10) dazo: depends on the patch ;-)
(13:36:34) plaisthos: the "if are holding a token and get an AUTH_FAILED, 
forget auth-token and continue as normal"
(13:36:36) dazo: but, yeah, we can have a patch which makes things behave 
somewhat better on the client side ... then fix server side
(13:36:41) cron2: ok, I need to go and find food now (next meeting starts in a 
bit over an hour)... I leave you to that discussion and then go merge the 
resulting patch :)
(13:36:56) dazo: :)
(13:37:42) dazo: yeah, if auth-token has been received, server sends 
AUTH_FAILED and then query the user again for credentials, that is fine
(13:37:55) mattock: I need to split for some minutes
(13:38:28) plaisthos: okay then I will split that out of the patch and send 
that as improvment on auth-token handling
(13:38:41) dazo: I'm open to discuss if user credentials can be cached ... 
unless --auth-nocache has been used
(13:39:07) dazo: as the core concept of auth-tokens is to not cache user 
(13:39:27) dazo: and caching credentials will definitely fail with OTP in the 
(13:41:04) plaisthos: the patch just keeps the normal openvpn2 stuff for that
(13:41:58) plaisthos: i.e. the no-cache-credentials or whatever the option is 
(13:42:20) dazo: --auth-nocache
(13:42:45) dazo: Is auth-nocache pushable?
(13:44:57) plaisthos: no but I don't understand the implications to auth-token
(13:45:23) plaisthos: if you have an otp setup you probably configured your 
client already not to cache password regardless if you use auth-token or not
(13:46:10) plaisthos: w/o auth-token you just have to reenter it every 
(13:47:01) dazo: well ... without auth-token + auth-nocache, then you'll need 
to re-enter creds
(13:47:38) dazo: with auth-token should not require re-entering creds unless 
the auth-token has been expired
(13:47:51) plaisthos: yes
(13:48:17) plaisthos: but you still need auth-nocache so it does not try the 
otp password again after the auth-token has expired
(13:48:20) dazo: without auth-token and without auth-nocache .... no 
re-entering is needed either  (but will fail with OTP on reconn/reneg)
(13:48:28) dazo: right
(13:48:44) dazo: so if auth-token implies auth-nocache, I'm fine with that
(13:48:55) plaisthos: why should it?
(13:49:35) plaisthos: I am confused here
(13:49:40) dazo: why should what?  auth-token imply auth-nocache?
(13:49:46) plaisthos: yes
(13:50:31) plaisthos: we also told users to use auth-token (auth-gen-token) to 
avoid costly authentication costs for SWEET32 mitigation
(13:50:32) dazo: because you generally want to use auth-token to not save 
passwords locally .... either due to OTP usage or not wanting to have the users 
password cached for renegotiations
(13:51:20) dazo: okay ... auth-nocache should be strictly seen in relation to 
the creds provided/typed by the end-user
(13:52:14) dazo: so when the server pushes an auth-token ... the creds provided 
by the user on the client side is no longer relevant
(13:52:44) dazo: the auth-token supersedes the user provided creds
(13:53:19) plaisthos: sure
(13:53:32) plaisthos: until it expires. 
(13:53:57) dazo: right ... and when it expires, the user needs to provide 
credentials again
(13:53:59) plaisthos: then is the quesiton, fall back to saved creditials or 
require user interaction (not always possible, e.g. headless setups)
(13:56:07) dazo: I'd be willing to claim a headless setup using auth-tokens is 
an invalid setup  (and --auth-gen-token is the wrong feature to use, you need 
to use a auth script/plug-in) .. then you would have username/passwords stored 
on file regardless, so auth-token doesn't "save" you anyhow and you can't use 
(13:57:12) dazo: if you want a combo of end-users and headless setups ... you 
need a auth script/plug-in which can differentiate between users and headless 
clients and only push auth-token to users
(13:59:17) dazo: But I see we can improve the --auth-gen-token man entry .... 
to more explicitly say that this is more or less a workaround for 
authentication modules not providing proper auth-token support.  
--auth-gen-token has some backsides, as it makes connection accounting 
(14:04:16) plaisthos: yeah
(14:04:28) ***dazo prepares a man page update patch
(14:06:06) plaisthos: dazo: look into my original patch 
(14:06:26) plaisthos: and copy the warning about old clients not being able to 
reconnect :)
(14:06:52) plaisthos: I will prepare the minimal version of my patch
(14:06:57) dazo: good point!
(14:06:58) dazo: thx!
(14:20:48) dazo: plaisthos: http://termbin.com/r7p0q ... what do you think?
(14:30:26) cron2: re
(14:30:29) cron2: *burp*
(14:33:09) ordex: agreed!
(14:33:23) dazo: the patch was _that_ bad?!? :-P
(14:33:25) ordex: (the sound took some time to get over here)
(14:35:20) cron2: nah, the lunch was that good (but a bit... much)
(14:35:27) dazo: :)
(14:36:25) plaisthos: You might to spell out that this means no reconnect 
(14:37:13) plaisthos: s/implement support for generating and sending/implement 
support for generating, sending and verifying
(14:41:39) tincantech [~slypknot@unaffiliated/kettlecalling] è entrato nella 
(14:41:45) dazo: plaisthos: thx!  good points!
(14:44:38) dazo: updated patch .... http://termbin.com/4ma4z
(14:53:11) plaisthos: looks good
(14:54:45) tincantech: I know I missed the discussion but "considered to be a 
work around" is that really what you mean ? 
(14:55:11) tincantech: I have been trying to support the auth-token machinery
(14:59:40) mattock: um well that was more than a few minutes, but anyways
(15:00:15) mattock: the meeting has probably ended, if that was not officially 
announced :)
(15:00:21) dazo: tincantech: yes, --auth-gen-token is a workaround for auth 
plug-ins/scripts not providing the auth-token support natively
(15:04:17) tincantech: dazo: for my sanity here .. I was not aware of any 
auth-token's until you created --auth-(gen)-token .. do you have an example of 
one that does ?
(15:05:05) tincantech: ie a plugin that does not need to use --auth-token but 
still has that functionality 
(15:06:31) tincantech: sorry for my lateness .. you can always come back to me 
when you have more timwe
(15:07:56) dazo: not a good concrete example I remember right now ... but it's 
all about exploiting the dynamic ccd feature ... so a --auth-user-pass-verify 
script would save a state on a successful, which --client-connect would pick 
up, generate token and put 'push "auth-token $TOKEN"' in the dynamic ccd file 
... on re-neg/re-conn the --auth-user-pass-verify script would see the state 
for that user and authenticate against the token generated by 
(15:07:56) dazo: --client-connect
(15:08:08) dazo: that's essentially the script hook concept
(15:08:45) dazo: that concept is similar for plug-ins as well, just need to 
hook into the right plug-in hooks instead
(15:10:26) dazo: I would need to use openvpn_plugin_func_v2() or 
openvpn_plugin_v3(), which provides a possibility to pass a buffer containing 
the ccd contents ("push" statement)
(15:11:12) tincantech: I think i get it .. you mean "push auth-token x" is a 
mechanism which scripts can do themselves but they don't so you provide the 
entire mechanism within openvpn just by --auth-gen-token .. so they don't have 
to worry about it .. sound about right ?
(15:11:55) tincantech: i don't know much about actual plugins btw
(15:12:03) dazo: correct ... but auth-gen-token will not pass the 
authentication to the plug-ins/scripts on re-neg/re-conn at all ... so if it 
fails, then it fails and client disconnects
(15:12:27) tincantech: ok .. i get it :)
(15:12:45) tincantech: thanks
(15:12:52) dazo: and this also means, you can't use any type of connection 
accounting based on the authentication ... the plug-ins/scripts won't know 
about re-con/re-neg at all
(15:13:19) dazo: hence, it's a workaround :)
(15:13:27) tincantech: ok
(15:13:39) tincantech: thanks :)
(15:13:42) dazo: yw!
(15:18:15) tincantech: I am ghoing to have to try to write a script to simulate 
the auth-token business now/soon ;)
(15:24:54) dazo: :)
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to