8:55 a.m.
= Proposed Self Contained Change: New default cipher in OpenVPN =
https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN
Change owner(s):
* David Sommerseth <davids(a)openvpn.net>
Since the discovery of the SWEET32 flaw [1], ciphers using
cipher-blocks smaller than 128-bits are considered vulnerable and
should not be used any more. OpenVPN uses Blowfish (BF-128-CBC) as the
default cipher, which is hit by the SWEET32 flaw. This proposal
changes the default cipher to AES-256-GCM while in parallel allowing
clients to connect using AES-256-CBC, AES-128-CBC or the deprecated
BF-CBC,
This proposal will make use of that possibility by modifying the
openvpn-server@.service unit file slightly.
== Detailed Description ==
There have been two independent security audits of OpenVPN recently,
performed by QuarksLab SAS [2] and Cryptography Engineering [3]. Both
recommends moving away from the default Blowfish cipher (BF/BF-CBC) to
a stronger cipher.
The concept is fairly simple. In today's openvpn-server@.service
systemd unit file the following command line is used to start OpenVPN:
ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --config %i.conf
By adding --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC before the
--config option, the default cipher will be modified. The
--ncp-ciphers list allows clients to use any of the listed ciphers as
well. The new line will look like this:
ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config
%i.conf
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.
If an already configured OpenVPN v2.4 based server configuration
deploys --cipher and/or --ncp-ciphers, the options in the
configuration file will override command line options set before
--config. This should not break any existing configuration.
The log files will still complain about the use of BF-CBC if a client
uses that. But the advantage is that OpenVPN v2.3 and older clients
can be updated one-by-one, by adding the recommended --cipher
AES-256-CBC option in the client configurations in their own pace,
independent of the server - or upgrade to OpenVPN v2.4 or newer.
== Scope ==
* Proposal owners: Patch the openvpn-server@.service unit file which
adds the --cipher and --ncp-ciphers options.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [4] (a check of an impact with Release
Engineering is needed)
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
[1] https://sweet32.info/
[2] https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf
[3]
https://www.privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation...
[4] https://pagure.io/releng/issue/6908
Jaroslav
10:50 a.m.
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.
--
Levente "Si vis pacem para bellum!"
3:03 p.m.
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>
I just ran a few tests manually now.
---- server.conf --------------
dev tun
persist-tun
server 10.35.8.32 255.255.255.224
topology subnet
user openvpn
group openvpn
chroot /var/lib/openvpn
client-config-dir clients
proto udp
port 1194
verb 4
keepalive 20 45
persist-key
remote-cert-tls client
dh dh2048.pem
pkcs12 server-ec.p12
ecdh-curve secp521r1
cipher AES-256-GCM
auth SHA256
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC
key-direction 1
tls-auth vpn.ta
--------------------------------
---- client.conf ---------------
dev tun
pkcs12 client-ec.p12
remote testserver.example.com 65441 udp
tls-auth vpn.ta
key-direction 0
verb 4
client
auth SHA256
explicit-exit-notify 2
--------------------------------
I tested this client config on both OpenVPN v2.3.12 and v2.4.3. All
connects with BF-CBC, AES-256-CBC, AES-128-CBC and for v2.4.3 I also
tested AES-256-GCM (I didn't test AES-128-GCM).
So I would recommend to re-test your own setup with the latest v2.4.3 on
the server side; which is what we ship in F25 and newer.
--
kind regards,
David Sommerseth
3:55 p.m.
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.
--
Levente "Si vis pacem para bellum!"
7:09 p.m.
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.
In addition, the scope of this proposal *only* targets the server side
configurations. I would expect the vast majority of Fedora users run
OpenVPN as a client, and then I'd expect it to be more likely used via
the NetworkManager plug-in for OpenVPN. In both these scenarios,
nothing will change.
I know I am somewhat blinded to other potential issues, as I am also an
upstream OpenVPN developer. But if others see flaws in the proposed
test script [1], feel free to help improve it! And do report back
unexpected results ASAP.
[1]
<https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN#How_...
Bottom line is, from my perspective: This feature currently works as
expected - at least to my knowledge. If there are issues we do have
time to fix them before the final F-27 release. And if not, then we'll
roll it back - which is more than fair enough.
The change itself isn't big, but the security improvements are
considerably much more important for end users and system administrators
to help them easily move away from BF-CBC.
--
kind regards,
David Sommerseth
11:04 p.m.
David Sommerseth wrote:
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.
That's what one would reasonably assume, but sadly, they decided to cut the
schedule of F27 down to 3-4 months to compensate for the delays in
delivering F26.
https://fedoraproject.org/wiki/Releases/27/Schedule
Kevin Kofler
2:46 a.m.
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.
--
Levente "Si vis pacem para bellum!"
6:21 a.m.
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
6:55 a.m.
On Thu, Jul 20, 2017 at 2:21 PM, David Sommerseth <dazo(a)eurephia.org> wrote:
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.
I modified the unit file on a F26 VPS and I didn't have any problems
connecting with F24, F25, F26, a gentoo installation that hasn't been
updated in almost a year, OpenWrt (CC) and Android (Lineage OS 14.1).
Not that this is exhaustive testing, but I think this change is a lot
less pervasive than it is made out to be.
11:32 a.m.
On 20/07/17 13:55, Alexander Ploumistos wrote:
On Thu, Jul 20, 2017 at 2:21 PM, David Sommerseth
<dazo(a)eurephia.org> wrote:
> 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.
I modified the unit file on a F26 VPS and I didn't have any problems
connecting with F24, F25, F26, a gentoo installation that hasn't been
updated in almost a year, OpenWrt (CC) and Android (Lineage OS 14.1).
Not that this is exhaustive testing, but I think this change is a lot
less pervasive than it is made out to be.
Thank you very much for this testing! This is truly a valuable feedback.
And you are right, this shouldn't be such a risky or invasive change at
all - as it should provide the needed fallback to not break existing
configurations; which you seem to have confirmed as well.
But I wanted to make this change visible in Fedora, both due to there
were complaints when updating to OpenVPN v2.4 which broke some
configurations (several reasons, I won't dive into that now) - and to
highlight that there is now a way to seamlessly update client
configurations one-by-one to a far better cipher for those still using
BF-CBC.
--
kind regards,
David Sommerseth
2471
days inactive
2473
days old
9 comments
5 participants
participants (5)
-
Alexander Ploumistos -
David Sommerseth -
Farkas Levente -
Jaroslav Reznik -
Kevin Kofler