Re: F27 Self Contained Change: New default cipher in OpenVPN
On 20/07/17 09:46, Farkas Levente wrote:
On 07/20/2017 02:09 AM, David Sommerseth wrote:
> On 18/07/17 22:55, Farkas Levente wrote:
>> On 07/18/2017 10:03 PM, David Sommerseth wrote:
>>> On 18/07/17 17:50, Farkas Levente wrote:
>>>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>>>>> This will result in the following:
>>>>> * OpenVPN 2.4 based clients will automatically upgrade to
AES-256-GCM,
>>>>> regardless if they have --cipher in their configuration file or not.
>>>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>>>>> client configuration needs to deploy --ncp-disable.
>>>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>>>>> --ncp-disable in the client configuration) can connect to the server
>>>>> using any of the --ncp-ciphers list; this is what is called
"poor
>>>>> man's cipher negotiation" by the upstream OpenVPN
developers.
>>>>> * Any client not providing --cipher defaults to BF-CBC. These
clients
>>>>> should still be able to connect to the server as the server allows
>>>>> BF-CBC through --ncp-ciphers.
>>>>
>>>> unfortunately it's not working:-(
>>>> it takes me long time to debug it on my own server and a long discussion
>>>> in this ticket:
>>>> https://community.openvpn.net/openvpn/ticket/886
>>>> it's not possible to set
>>>> cipher AES-256-GCM
>>>> since in this case old clients eg android client which not updated to
>>>> 2.4.x are not able to connect.
>>>
>>> The issue I believe you refer to ("unreliable NCP") should be fixed
in
>>> OpenVPN v2.4.3.
>>> <https://community.openvpn.net/openvpn/ticket/887#comment:13>
>>
>> this means only a few weeks ago...
>> imho openvpn is _very_ widely used and if it's break anything it's break
>> a lots of thing...
>> i'd rather postpone it to f28 when it's fully tested and stabilized.
>
> What is the benefit of postponing based on a bug which have been fixed?
> And have been tested? And where the test process should reasonably
> thoroughly documented and can be verified by others?
>
> Also considering that we're just in the very early planning phase of
> F-27 and F-26 have just been released. So F-27 is at least 6 months
> ahead of us. Which means the NCP feature will be at least 1 year old,
> with the last fix making this work will be 6 months - which should be
> plenty of time to test this out. Plus considering that OpenVPN is
> deployed elsewhere in much grander scales than Fedora alone where also
> NCP is getting more and more used and rolled out in similar ways as this
> proposal. So this is also being tested outside the Fedora universe as well.
if this is so obvious and has only benefits and at the same time you
also upstream developer why the upstream openvpn not change it's
default? since it'll exactly has the same effect as it's changed in
fedora and in this case fedora don't have to do anything.
You never seem to really answer any questions, you just shoot new ones.
This makes it really makes it hard to take your feedback serious.
Especially when you even base your claims that this won't work on false
premises, completely disregards issues have been fixed upstream already
and it is reasonably easy to verify my claims it works. You have not
provided any feedback that there are any flaws in neither the example
configurations nor the test script described in the change proposal.
With this argumentation tactic, Fedora would still be arguing when to
include systemd in an official release. And this OpenVPN change is a
far less invasive change. And even only hitting OpenVPN server
configurations.
But to answer your yet new question: A far more invasive change is being
discussed upstream, which will enforce this change also on non-systemd
based OSes (that change will be happen in the OpenVPN executable). The
experienced functionality will be most likely be pretty much the same.
But as this is a very simple change for Fedora - by changing the unit
file, so I didn't really see any reason to postpone it. This also helps
preparing Fedora users once it hits a future upstream OpenVPN release
(something I got lots complaints about when moving towards OpenVPN 2.4
in Fedora).
So if the consensus is that we should just silently wait until upstream
OpenVPN forces this change upon us, then I don't want to he hear a lot
of noise and complaints when OpenVPN is updated later on in Fedora.
I rather prefer to have this change in Fedora _now_ in a _planned_
release where this can be tested out before the final F27 is released.
And where we have a chance roll it back if yet unknown and unexpected
issues are found and not getting a proper fix in a timely manner. With
this approach _we_ have better control of what happens for our Fedora
users. And this is me wearing the Fedora, not the OpenVPN hat.
--
kind regards,
David Sommerseth