On 22/06/2020 14:43, Steffan Karger wrote: > Hi, > > On 22-06-2020 14:29, David Sommerseth wrote: >> On 22/06/2020 14:21, Arne Schwabe wrote: >>> >>>> PrivateTmp=true >>>> WorkingDirectory=/etc/openvpn/server >>>> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>>> --status-version 2 --suppress-timestamps --config %i.conf >>>> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>>> --status-version 2 --suppress-timestamps --cipher AES-256-GCM >>>> --ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC >>>> --config %i.conf >>>> CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE >>>> CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE >>>> CAP_AUDIT_WRITE >>>> LimitNPROC=10 >>>> DeviceAllow=/dev/null rw >>>> >>> >>> NACK. >>> >>> Setting ncp-cipher to include BF-CBC by default allows BF-CBC in configs >>> that did not allow it before. Basically any config that had something >>> other than cipher BF-CBC and no ncp-ciphers in it will now allow clients >>> with BF-CBC to connect. I don't want force users to set ncp-cipher to a >>> sane value since the systemd unit file doesn't. >> >> That will break existing configs on the next upgrade. Do we want do do that? >> >> I'm fine with removing BF-CBC, but it is scheduled for removal in OpenVPN >> 2.6. > > I think Arne has a very good point that it's kinda weird to "degrade" > the NCP defaults. > > Making AES-256-GCM the default cipher for TLS-based connections (GCM > won't work with static key configs) does not imply *removing* BF-CBC > support. Maybe these should be the steps: > > 2.4: Use to AES-256-GCM when available (basically what NCP did) > 2.5: Switch to AES-256-GCM as the default cipher (but allow overriding) > 2.6: Remove support for small block ciphers all together > > Yes, this will probably break some (less secure) setups and make some > people angry. But at some point people need to move on. We've been > throwing warnings at them for a while now.
Yes, I agree that Arne got a point. But I'm not completely convinced breaking
configs in OpenVPN 2.5 without a prior note that it will stop working. Our
warning only screams "you shouldn't use ciphers with block sizes < 128 bits",
it doesn't say "this will stop working in a future release".
OpenVPN 2.4.9 gives this warning:
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This
allows attacks like SWEET32. Mitigate by using a --cipher with a larger
block size (e.g. AES-256-CBC).
The community has been informed it will stop working in 2.6, not before this
release.
This must be documented properly and log warnings updated to indicate
short-term workarounds.
I could be willing to consider breaking configs for ciphers in a later 2.5.x
release as long as users are properly warned *when* it will stop working - and
that users gets a real chance to fix configs before we do break their configs
- where a workaround approach could be considered and available from v2.5.0
(on the other hand, if they change their configs, they should swap ciphers
instead of applying a workaround for a dying cipher - but for some it might be
a bit more complicated to do such a swap).
We need to find a good middle-way for OpenVPN 2.5, where we clearly signal
"weak ciphers will be removed" and when we will do that. While also moving
forward and break as few configs as possible and not make configs weaker than
before.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
