Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

On 22-06-2020 19:59, David Sommerseth wrote: > On 22/06/2020 14:43, Steffan Karger wrote: >> 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. I agree the warning we log should be made even more scary. The DeprecatedOptions wiki however already says: Removal of insecure ciphers: Ciphers with cipher block-size less than 128 bits (most commonly BF, DES, CAST5, IDEA and RC2) Deprecated in: OpenVPN v2.4 To be removed in: OpenVPN v2.6 What I'm proposing is a step in between for something that is long overdue: update the *defaults* to no longer use insecure ciphers. But to cater for those that are unprepared, allow them to explicitly re-enable BF-CBC during a transition period. They've been ignoring our advice to migrate for a long time now, and even the wiki page says that these ciphers are already deprecated in 2.4. -Steffan