Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 19th May 2021
Time: 14:00 CET (12:00 UTC)

Planned meeting topics for this meeting were here:

<https://community.openvpn.net/openvpn/wiki/Topics-2021-05-19>

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

<http://www.timeanddate.com/worldclock>

SUMMARY

cron2, dazo, d12fk, lev, mattock, ordex, plaisthos and syzzer participated in this meeting.

---

Noted that native OpenVPN 2.5 on ARM64 (OpenVPN build, MSI, dependencies, etc) is progressing very nicely. We could build an ARM64-compatible 2.5.2 installer with fairly small amount of manual tinkering now. Only Wintun support would be missing. The msibuilder VM in openvpn-vagrant may need to be upgraded to install WiX 3.14 (that has ARM64 support).

---

Noted that openvpn.net domain is still missing IPv6. No changes since last week as far as we know.

---

Talked about removing --no-replay option. Noted that it was to be removed in 2.5, but we backpedaled on that decision and forgot to change our documentation. It was also noted that that option changes the wire format.

Noted that --cipher none --auth none and --no-replay are quite intertwined. Getting rid of these options would be good from security perspective, but it was also noted that plain-text OpenVPN tunnels do have some advantages over the alternatives like GRE tunnels.

Summarizing the discussion:

1) OpenVPN 2.6: reject configs where --no-replay is used without --auth none.
2) OpenVPN 2.7: remove --no-replay
3) Add clear warnings to 2.5 and 2.6 about 1) and 2)

---

Noted that mattock buildbot setup is shaping up nicely. There are a ton of workers and code and data are quite well separated. Mattock is now working on limiting concurrent builds on the docker host, then moving on to t_client tests.

---

Full chatlog attached

(14:57:15) ordex: heya
(14:59:19) plaisthos: hey
(14:59:25) dazo: hey!
(14:59:33) d12fk: hi
(15:00:25) mattock: hi
(15:01:12) lev__: Hi
(15:03:25) cron2: ohaiu
(15:03:43) ordex ha scelto come argomento: 
https://community.openvpn.net/openvpn/wiki/Topics-2021-05-19
(15:04:07) ordex: added point 3
(15:05:37) mattock: all ready?
(15:05:42) cron2: this cloudflare shitshow with the URL massacring is annoying
(15:05:43) plaisthos: yeah
(15:05:46) dazo: yeah
(15:06:40) cron2: booting FreeBSD/Arm64 right now... $something is insanely 
slow...
(15:06:57) mattock: ah, I got the topic page now :)
(15:07:00) mattock: sync up
(15:07:21) plaisthos: cron2: on your m1 mac?
(15:07:23) cron2: yep
(15:07:29) cron2: (in parallels)
(15:08:02) cron2: might just be the virtual CD rom, will see after installation
(15:08:10) cron2: win10 sort of felt normal
(15:10:21) cron2: so, meeting? :)
(15:10:55) ***dazo is ready
(15:11:07) mattock: yes, sync up
(15:11:45) cron2: I have not much to report... I broke one of the patches, and 
the other did not apply anymore (*selfslap*), but a v3 is there which I haven't 
looked at yet...
(15:12:34) cron2: today and tomorrow is RIPE meeting, so busy.  Friday+weekend 
looking good.
(15:14:06) cron2: lev__, d12fk and selva seem to do a great job on the ARM64 
installer
(15:14:29) ordex: plaisthos you should be sending rebased patches soon, right? 
(for the x/7 patchset)
(15:14:40) d12fk: mostly the other two
(15:14:47) plaisthos: yeah
(15:14:57) lev__: yeah after openvpn-build PR is merged, arm64 should be done 
(except wintun)
(15:14:58) plaisthos: I need to fixup the connect patch to work with p2p first 
:/
(15:15:03) syzzer: hi :)
(15:15:16) d12fk: hi syzzer
(15:15:24) lev__: hi syzzer!
(15:15:24) mattock: hi!
(15:15:44) ordex: !
(15:15:52) ordex: plaisthos: ah right
(15:17:45) plaisthos: I am probably opting for a hacky solution as the whole 
code block gets removed eventually by the p2p ncp and S_GENERATED_KEY anyway
(15:17:53) cron2: syzzer! welcome back :-)
(15:18:38) ordex: plaisthos: if that code gets removed, might it make sense to 
merge the two patches back2back ?
(15:18:55) ordex: rather than fixing a case that is broken for one commit only?
(15:18:57) cron2: that was my idea as well
(15:19:20) ordex: it feels like "it's a needed step towards salvation", so 
probably acceptable
(15:19:26) cron2: if we have two ACKed and "together everything passes" 
patches, we could do that
(15:19:33) plaisthos: if that is okay I can do that too
(15:19:36) cron2: (if the patch in between only breaks a corner case)
(15:19:42) ordex: yeah
(15:20:07) ordex: implementing "a hacky transient solution" doesn't sound any 
better after all, something might still be broken
(15:20:41) plaisthos: basically non-ncp code paths are broken in the patch
(15:20:49) plaisthos: cron2: did you have tests with ncp-disable?
(15:20:56) plaisthos: they *might* be broken too
(15:20:58) ordex: the patch breaking tls/p2p is 1788 ?
(15:21:00) cron2: wait
(15:21:21) cron2: plaisthos: not on the server
(15:21:37) cron2: there are a few client instances that do ncp-disable, and 
these pass
(15:22:18) cron2: both "ncp-disabled client -> server+1788" and also 
"client+1788 +ncp-disable -> older server"
(15:22:34) cron2: but no "server+1788 + ncp-disable"
(15:22:45) plaisthos: yeah client has the read/write key2 methods in the 
different order andere therefore doesn't break
(15:23:47) ***cron2 notes "add server instance with ncp-disable"
(15:23:59) plaisthos: cron2: maybe not
(15:23:59) plaisthos: :)
(15:24:10) plaisthos: 5 patches later we remove ncp-disable
(15:24:20) cron2: that would break my server config!
(15:24:24) ***ordex swims in the patches
(15:24:59) ***cron2 waits until ordex resurfaces and will then ask for guidance 
:)
(15:25:10) ordex: :D
(15:25:28) ordex: how can I help?
(15:28:34) mattock: cron2 dove into patches? :)
(15:28:45) ***cron2 waits for IPv6 on community
(15:28:48) ordex: he went deep I think
(15:29:04) ***ordex bets on Italy reaching 90% coverage before ipv6 can hit 
community
(15:29:14) mattock: what is the coverage now?
(15:29:20) ordex: 5% ?
(15:29:30) cron2: nah, this patchset is definitely above what I can manage to 
understand in between a RIPE meeting :-) - so I wait for ordex and plaisthos to 
tell me "this + that, back2back" :-)
(15:29:31) mattock: I might have IPv6 now, not sure, changed to 5G connection
(15:29:38) d12fk: coverage is the future, just like ipv6
(15:29:40) ordex: cron2: oky
(15:29:55) mattock: anything more on 2.5 / 2.6?
(15:30:44) cron2: hailstorm
(15:32:00) ordex: patchstorm you mean ?
(15:32:02) ordex: so #2 ?
(15:32:12) cron2: nah, weather outside
(15:32:21) mattock: nothing new on #2 afaik
(15:32:29) mattock: the famous .com migration is ongoing
(15:32:35) mattock: whatever that means exactl
(15:32:36) mattock: y
(15:32:38) cron2: but anyway, 2.5 - not much has happened.  We could release a 
test installer of 2.5.2 with arm64 eventually...
(15:32:46) cron2: openvpn.com has IPv6 address 2606:4700::6812:1069
(15:32:56) cron2: *that* sounds quite good
(15:33:39) mattock: what is the level of buildsystem kludginess required by 
arm64 msi now, lev?
(15:33:41) cron2: ordex might reach this over v6 now!
(15:34:03) ordex: /o/
(15:35:16) ordex: I can, with 10ms latency
(15:35:19) ***ordex drinks
(15:35:24) ordex: now, #3?
(15:35:39) cron2: mattock: selva and d12fk fixed stuff yesterday
(15:35:47) mattock: good!
(15:35:54) plaisthos: does anyone know if no-replay changes wire format or not?
(15:36:10) cron2: yes
(15:36:30) cron2: oh
(15:36:31) cron2: maybe not
(15:36:38) ***cron2 confuses with --no-iv
(15:37:06) ordex: maybe syzzer knows
(15:37:11) ordex: I thought it would not affect the wire format
(15:37:16) plaisthos: hm
(15:37:20) plaisthos: looks like it does
(15:37:26) ordex: omg
(15:37:36) dazo: I also did not expect wire format change
(15:37:39) ordex: why would it ?
(15:37:45) plaisthos: it seems to toggle inclusion of packet id in the wire 
format
(15:37:46) ordex: isn't it just a check on the packet # ?
(15:38:01) ordex: so --no-reply will remove the packet id ?
(15:38:27) ordex: *replay
(15:38:48) ordex: it is also part of the OCC
(15:38:49) ordex: string
(15:38:53) dazo: Perhaps we should just write a new OpenVPN protocol and fix 
all these ambiguities ..........
(15:39:09) dazo: (and leave the current one as is)
(15:39:15) cron2: one should write an RFC to document what we have, so we can 
look up the wire format in the standard...
(15:39:37) mattock: I recall dazo was at some point writing an RFC
(15:39:45) dazo: well, that too ... but then we need to understand the code 
deeply to understand it
(15:39:51) plaisthos: for aead/ofb/cfb packetid is the same IV
(15:39:58) plaisthos: for cbc iv and packet id are distinct
(15:40:22) dazo: I do have a skeleton ready, which covers most of the control 
channel ... but the protocol is highly adoptable according to enabled features
(15:40:30) dazo: many not pushable
(15:41:01) ordex: btw you can check the function 
crypto_adjust_frame_parameters() to see how the packet ID affects the frame siz 
calculation (hence the wire format)
(15:41:07) ordex: we even have two packet ID formats
(15:41:12) ordex: affecting the size differently
(15:41:13) dazo: yes
(15:41:28) plaisthos: openvpn_encrypt_v1 also has code that only writes packet 
id when it is enabled
(15:41:40) plaisthos: so yes no-replay is part of the wire protocol
(15:41:57) ordex: FWIW an alternative could be to just go with "remove the knob 
and assume always enabled, without changing the logic"
(15:42:14) ordex: just to avoid people from activating --no-reply
(15:42:25) cron2: replay
(15:42:26) cron2: :)
(15:42:49) ordex: in any case, the setups we would break are those with 
auth/cipher none and no-replay enabled - they would need to deactivate it on 
the other side
(15:42:52) dazo: well, that's they suggestion from syzzer .... but that will 
break configs explicitly using --no-replay today
(15:42:53) ordex: yeah, thanks :D replay
(15:43:33) plaisthos: Yeah not sure syzzer was aware of the wirelevel change 
when he made his suggestion
(15:43:41) dazo: but I'm not sure I care enough for --no-replay users at all 
.... it feels more like a debug/testing feature than something you really want 
in production
(15:43:49) ordex: dazo: yes, but I'd argue it is meaningful for these people to 
realize they are doing something wrong (i.e. using md5 for a certificate hash)
(15:43:57) ordex: dazo: exactly
(15:44:40) plaisthos: the whole discussion basically boils down to one thing: 
how important is cipher none and compatibility with setups using it
(15:44:49) dazo: This option definitely falls into the "security related" 
category
(15:45:37) ordex: plaisthos: I think for security sake, we can break those 
setups and tell people that no-reply has to be set for none
(15:45:58) dazo: "cipher none" is also something which should only be used for 
testing/debugging in my view.  If you really want to have authenticated 
packets, the crypto overhead the last 10 years should be fairly negligible
(15:46:13) ordex: yap yap
(15:46:14) plaisthos: we also don't win much in that case since we still carry 
around the code for both scenarios
(15:46:28) dazo: If you expliclty want to use a clear-text tunnel, a GRE tunnel 
is most likely more useful
(15:46:29) ordex: imho it's a marginal number of users who get affected and 
those can deal with the understanding the setting they have to use moving 
forward
(15:46:51) plaisthos: which would imply, deprecating it in 2.6 and remove it in 
2.7?
(15:47:02) ordex: plaisthos: I'd say so
(15:47:09) plaisthos: and also get a ton of complains of users that are angry 
about removing cipher none
(15:47:27) ordex: well, we are not removing it, no?
(15:47:32) ordex: or are we already?
(15:47:36) cron2: DCO+AEAD should be faster than userspace+none
(15:48:00) dazo: plaisthos: deprecating 2.6 and removing 2.7 .... --no-replay 
or --cipher none?
(15:48:08) ordex: AEAD == AES-GCM ?
(15:48:14) dazo: yes
(15:48:22) ordex: yeah, likely
(15:48:30) plaisthos: replay protection enabled with --auth none makes little 
sense.
(15:49:03) ordex: right. ideally syzzer's last suggestion would be what we want 
to implement in 2.7
(15:49:33) plaisthos: So either we keep the ability to disable it at least on 
auth none or we honestely drop cipher none as well as properly supported cipher
(15:49:58) dazo: I'd say drop auth none and cipher none
(15:50:11) plaisthos: ordex: all aead ciphers, aes-gcm, aria-gcm, 
chacha20-poly1305, aes-ccm
(15:50:39) plaisthos: dazo: gre doesn't do the dynamic setup for you like 
openvpn does
(15:50:44) ordex: the idea is to also remove none from dco once we get to a 
further stage
(15:50:51) ordex: (this was planned already)
(15:50:53) cron2: openvpn + cipher none still has benefits over GRE (namely, 
client authentication, changing source address, and HMAC auth)
(15:51:13) cron2: so the argument "use GRE instead" does make little sense
(15:51:27) plaisthos: yeah, nowadays full aes-gcm encryption is faster than 
just auth sha1 but yes :D
(15:51:27) cron2: "DCO is faster than userland + none" is something I find more 
compelling :)
(15:51:56) ordex: we could start by dropping 'auth none'
(15:52:03) dazo: fair enough .... but from an OpenVPN security perspective 
still supporting these "none" options also makes little sense
(15:52:07) ordex: and the pair 'auth none, cipher none'
(15:52:23) ordex: those two really make no sense, I think
(15:52:28) dazo: +1
(15:52:36) cron2: dazo: it does.  If you want authenticity, but do not care 
about encryption.
(15:52:46) plaisthos: oh well, trhe newest intel generation has SHA_NI, so this 
might not be true anymore %)
(15:53:28) cron2: I'm not actually insisting on keeping cipher none, just 
pointing out that there is something I consider a valid use case
(15:53:29) lev__: mattock: depends how installers are built for releases
(15:53:46) mattock: ok
(15:53:53) plaisthos: okay nevermind, my small intel nuc still manages to have 
5,7GB/s with aes-gcm and "only" 1,7 GB/s with SHA1
(15:53:54) lev__: one needs to run mbuild <magic> and copy output to image-arm64
(15:53:55) mattock: that's a vague answer but I accept it for now :)
(15:54:05) lev__: that should be enough
(15:54:11) lev__: *msbuild
(15:54:50) dazo: cron2: But is the use cases used widely enough to be worth 
maintaining the additional code and protocol complexities this flexibility 
gives?
(15:55:21) cron2: as far as I understand, as long as we support non-AEAD 
ciphers, "none" is not actually that hard
(15:55:22) syzzer: woops - got distracted by $dayjob. Reading the backlog now.
(15:55:23) dazo: as the --cipher none --auth none and --no-replay are quite 
intertwined
(15:55:23) lev__: that requires cloning openvpn repo to windows builder, I 
don't think we currently do it? we build binaries on linux machine are copy via 
samba to windows, where we have openvpn-build cloned
(15:55:35) cron2: getting rid of all non-AEAD ciphers would simplify the code 
quite a bit
(15:55:54) cron2: but syzzer is more qualified to comment on complexity
(15:55:55) ordex: right cron2, but that probably is a bigger fish to catch
(15:56:04) dazo: that's essentially where we're headed with DCO though
(15:56:05) lev__: so, 1) clone openvpn repo 2) run msbuild 3) copy output to 
image-arm64
(15:56:12) ordex: to sum it up the proposal is: 1) we deprecate no-replay in 
2.6 2) we deprecate 'auth none' in 2.6 3) we deprecate 'auth none + cipher 
none' in 2.6 ?
(15:56:18) syzzer: cron2: yes, but I think plaisthos is right that this will 
hurt, so rather long-term
(15:56:49) cron2: ordex: 3) is covered by 2) already :)
(15:57:33) ordex: h riiight
(15:57:37) ordex: my brain got stuck :)
(15:57:47) dazo: I wonder if --auth none and --no-reply should be coupled in 
regards to deprecation/removal
(15:58:03) ordex: well, 1) and 2) imply that
(15:58:09) ordex: we deprecate both and remove both opions in 2.7
(15:58:14) ordex: *options
(15:58:25) ordex: we deprecate both in 2.6 and remove both opions in 2.7
(15:58:29) ordex: *options
(15:58:30) cron2: ordex: none-brain stuckee :-)
(15:58:44) mattock: lev: msbuild needs to run on Windows arm64, it's not 
cross-compilation is it?
(15:58:59) dazo: and since 3) is part of 2), and that 1) and 2) are implicit 
..... we end up tying them all up together :-P
(15:59:08) ordex: right
(15:59:13) ordex: couldn't be a better summary
(15:59:14) ordex: :D
(15:59:18) lev__: mattock: no I doesn't
(15:59:31) lev__: I mean it runs on x64
(15:59:34) mattock: ok
(15:59:35) plaisthos: I think getting rid of all non-AEAD cipher would be nice 
but basically break the compability with anything before 2.4
(15:59:41) plaisthos: so I don't think we are ready for that
(15:59:43) ordex: we are hitting the 1h mark - do we feel this is a reasonable 
plan forward?
(16:00:30) lev__: mattock: you might need to upgrade vagrant windows image to 
install wix 3.14
(16:00:35) dazo: plaisthos: I would say OpenVPN *community* is ready for it; 
but it depends if those packaging it is ready for it.  And that will keep some 
users on 2.5 and older for a bit longer.
(16:00:51) dazo: but once 2.6 is out ... 2.5 has at least 18 months of support 
from us.
(16:00:55) mattock: lev: at some point I'd like to add a real msvc buildbot 
worker that uses msbuild
(16:01:19) dazo: and we can decide to have a bit longer 2.4 support cycle if 
2.5 vs 2.4 is an issue.
(16:02:01) lev__: mattock: with recent patch, msbuild buildsystem is 
self-contained, you dont need openvpn-build/msvc anymore
(16:02:07) dazo: (2.4 will need to be supported until Debian 9/10, most Ubuntu 
releases as well as RHEL/CentOS 8 goes EOL)
(16:02:18) lev__: someone needs to review/ack it
(16:02:25) ***lev__ looks at cron2
(16:02:30) ***cron2 looks at mattock
(16:02:30) dazo: RHEL/CentOS 7+8 actually
(16:02:37) plaisthos: dazo: I honestely do not think that complexity currently 
for this support those ciphers is big enough to drop support
(16:02:48) mattock: for the record: my buildbot setup in vagrant is pretty good 
shape now, tons of workers, code and data separated (simplified the former a 
lot) - working on limiting concurrent builds on the docker host, then moving on 
to t_client
(16:02:54) plaisthos: we can certainly add warning messages to point users to 
switch to better ciphers
(16:02:58) mattock: lev: yep, that was my hope
(16:03:05) ***ordex looks at the sky
(16:03:24) cron2: .oO(ordex sounded bored recently)
(16:03:29) dazo: it's not just about code complexity ... but having a code base 
with lesser ties to old features which we have deemed insecure
(16:03:36) syzzer: just finished reading backlog. what plaisthos says. the code 
complexity isn't much. we'll likely not toch the old (non-AEAD) modes again.
(16:04:21) ordex: basically it sounds like keeping it around some more is not 
that problematic...later on we can still push it away, once it is safer from a 
compatibility perspective
(16:04:50) plaisthos: it is basically only the openvpn_encrypt_v1 and 
openvpn_decrypt_v1 methods that need to be kept
(16:04:53) syzzer: the thing with --auth none en --no-replay is that user often 
don't understand the security implications
(16:05:05) ordex: yap
(16:05:28) ordex: "I see this replay error...I add --no-replay to fix it!"
(16:05:31) syzzer: which is basically what dazo said :)
(16:06:55) syzzer: remove the footguns :)
(16:06:57) dazo: but that won't work if you only do it on one side; as the wire 
format changes ..... or?
(16:07:26) syzzer: correct
(16:07:33) dazo: at which this becomes a security related issue.
(16:07:37) dazo: Btw .... 
https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits#OVPN-03-3:Insecureconfigurationoptions:--no-replay
(16:08:21) dazo: "luckily" we have not committed publicly to removing it in a 
specific version in relation to a security audit (like --no-iv)
(16:08:27) ordex: :D
(16:08:56) plaisthos: Going forward, we can deprecate or refused no-replay 
without auth none
(16:09:14) ordex: wouldn't be better toalso deprecate auth none ?
(16:09:21) syzzer: --no-replay has been deprecated for years, right?
(16:09:31) dazo: 
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--no-replay
(16:09:36) ordex: syzzer: I don't think we print anything
(16:09:47) plaisthos: we do but only in openvpn --help
(16:09:47) syzzer: man openvpn says "       --no-replay
(16:09:48) syzzer:               DEPRECATED This option will be removed in 
OpenVPN 2.5.
(16:09:50) dazo: it should have been removed already, just "missed the bus" due 
to these implications
(16:09:51) ordex: OH
(16:09:55) plaisthos: that nobody reads :D
(16:10:02) ordex: so we are discussing something that was already decided and 
we are late !!
(16:10:10) mattock: :)
(16:10:18) ordex: I think it's ok to remove it in master then ?
(16:10:19) mattock: we should read our own man pages? :P
(16:10:27) ordex: (will be 2.6, but feels "more polite")
(16:10:33) dazo: well, if these implications hadn't been discovered ... it 
would have been gone in 2.5, I believe
(16:10:57) dazo: we just forgot to update the man and wiki page when we decided 
to postpone it
(16:11:06) ordex: yap
(16:11:09) syzzer: yeah, I wrote a patch a while ago. realized the subtleties, 
then deferred. "Will do a write-up with proposal some time"
(16:11:10) mattock: I'll start writing the summary...
(16:12:49) ordex: thanks
(16:13:52) syzzer: Do we have a conclusion on --no-replay?
(16:14:28) dazo: "We're running and circles and are totally confused by 
--no-replay"
(16:14:40) syzzer: haha
(16:14:41) dazo: s/ and / in /
(16:17:57) syzzer: If I understand correctly, there's two options left for 2.5: 
1) remove --no-replay or 2) reject configs where --no-replay is used without 
--auth none.
(16:18:00) syzzer: Uh, 2.6
(16:18:22) plaisthos: I would go with 2) for now
(16:18:30) syzzer: 2) resolves the footgun, but does not reduce code complexity.
(16:18:45) plaisthos: it actually reduces some of it
(16:18:47) dazo: yeah, 2) is a good start
(16:18:57) plaisthos: but it is a step in a right direction
(16:18:58) ordex: then 1 in 2.7 ?
(16:19:18) syzzer: yeah, and add clear warnings about the removal in 2.5 and 2.6
(16:19:20) dazo: and then --no-replay with --auth none and --cipher none in 2.7?
(16:19:23) plaisthos: 1) basically depends on if we want to support --auth none 
(and --cipehr none) or not
(16:20:58) dazo: while there might be use-cases for --cipher none ... I'm not 
convinced we as a VPN project need it, from a security perspective (--cipher 
none is essentially just a Virtual Network; not a Virtual Private Network)
(16:21:17) dazo: but we can take that discussion another time
(16:21:47) syzzer: that's what I was going to suggest. we're well past the 1h 
mark.
(16:22:46) syzzer: oh, I didn't state explicitly: I too think that 2) is the 
right first step.
(16:23:46) dazo: \o/ ... we've reached a conclusion, where this annoying 
bastard (me!) even agrees!  :-P   "reject configs where --no-replay is used 
without --auth none"
(16:24:51) dazo: who picks up the task to rework the current --no-reply patch?
(16:27:25) mattock: replay
(16:27:26) mattock: :D
(16:27:35) dazo: hahaha yeah!
(16:27:39) mattock: typo of the day
(16:27:44) mattock: from multiple people
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to