Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY 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:
<https://community.openvpn.net/openvpn/wiki/Topics-2018-04-04>
The next meeting has not been scheduled yet.
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, mattock, ordex, plaisthos and tincantech participated in
this meeting.
--
Noted that ticket "--preresolve is undocumented" belongs to plaisthos:
https://community.openvpn.net/openvpn/ticket/1049
--
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
systems.
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
thingy.
--
Discussed "PATCH: Rework OpenVPN auth-token support":
<https://patchwork.openvpn.net/patch/263/>
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
community.openvpn.net)
(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
again)
(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
patch?
(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
mode
(12:56:28) mattock: but as for signing: depends on people at the office and
Microsoft
(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
scope
(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
setups
(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
re-authenticate
(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
switch
(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
problem
(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.202.153.212.78] è
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
not
(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
clients
(13:34:31) plaisthos: since openvpn3 will never try to use the token on normal
reconnect
(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
credentials
(13:39:27) dazo: and caching credentials will definitely fail with OTP in the
password
(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
called
(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
reconnect/renogiation
(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
OTP
(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
impossible
(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
stanza.
(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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
