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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to