diff mbox series

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

Message ID 20200622113022.23047-1-davids@openvpn.net
State Rejected
Headers show
Series [Openvpn-devel] systemd: Change the default cipher to AES-256-GCM for server configs | expand

Commit Message

David Sommerseth June 22, 2020, 1:30 a.m. UTC 
This change makes the server use AES-256-GCM instead of BF-CBC as the
default cipher for the VPN tunnel when starting OpenVPN via systemd
and the openvpn-server@.service unit file.

To avoid breaking existing running configurations defaulting to BF-CBC,
the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in
addition to AES-CBC.  This makes it possible to migrate existing older
client configurations one-by-one to use at least AES-CBC unless the
client is updated to v2.4 or newer (which defaults to upgrade to
AES-GCM automatically)

This has been tested in Fedora 27 (released November 2017) with no
reported issues.  By making this default for all Linux distributions
with systemd shipping with the unit files we provide, we gradually
expand setups using this possibility.  As we gather experience from
this change, we can further move these changes into the defaults of
the OpenVPN binary itself with time.

Signed-off-by: David Sommerseth <davids@openvpn.net>
---
 Changes.rst                               | 15 +++++++++++++++
 distro/systemd/openvpn-server@.service.in |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

Comments

Arne Schwabe June 22, 2020, 2:21 a.m. UTC | #1 
>  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.

Arne
David Sommerseth June 22, 2020, 2:29 a.m. UTC | #2 
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.

<https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2>
Steffan Karger June 22, 2020, 2:43 a.m. UTC | #3 
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.

-Steffan
Arne Schwabe June 22, 2020, 4:01 a.m. UTC | #4 
Am 22.06.20 um 14:43 schrieb Steffan Karger:
> 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.

I had a different suggestion in the channel:

- Deprecate ncp-disable. Reason: Was a good debug switch when introduced
should not be necessary anymore.

- Introduce ncp-fallback-cipher for compatibility with ncp-disable/old
versions
    - needs to be a cipher from ncp-ciphers list
    - Eventually default the first cipher from ncp-ciphers list
    - in 2.5 default to --cipher if --cipher is set and automatically
add cipher to ncp-ciphers and set ncp-fallback-cipher.

    - If cipher is not set
	a) warn about that cipher will be ignored in p2mp mode and if BF-CBC is
still needed (e.g. peer 2.3 or older) that ncp-fallback-cipher should be set
        b) same a) but do it automatically for the user+warn


This allows us to eventually get rid of --cipher while providing still a
smooth transaction.

Arne
Selva Nair June 22, 2020, 6:58 a.m. UTC | #5 
On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth <davids@openvpn.net> wrote:
>
> This change makes the server use AES-256-GCM instead of BF-CBC as the
> default cipher for the VPN tunnel when starting OpenVPN via systemd
> and the openvpn-server@.service unit file.
>
> To avoid breaking existing running configurations defaulting to BF-CBC,
> the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in
> addition to AES-CBC.  This makes it possible to migrate existing older
> client configurations one-by-one to use at least AES-CBC unless the
> client is updated to v2.4 or newer (which defaults to upgrade to
> AES-GCM automatically)
>
> This has been tested in Fedora 27 (released November 2017) with no
> reported issues.  By making this default for all Linux distributions
> with systemd shipping with the unit files we provide, we gradually
> expand setups using this possibility.  As we gather experience from
> this change, we can further move these changes into the defaults of
> the OpenVPN binary itself with time.
>
> Signed-off-by: David Sommerseth <davids@openvpn.net>
> ---
>  Changes.rst                               | 15 +++++++++++++++
>  distro/systemd/openvpn-server@.service.in |  2 +-
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/Changes.rst b/Changes.rst
> index 00dd6ed8..e76d3c73 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support
>      channel.
>
>
> +User-visible Changes
> +--------------------
> +New default cipher for systemd based Linux distributions
> +    For Linux distributions with systemd which packages the systemd unit files
> +    from the OpenVPN project, the default cipher is now changed to AES-256-GCM,
> +    with BF-CBC as a fallback through the NCP feature.  This change has been
> +    tested successfully since the Fedora 27 release (released November 2017).
> +
> +    *WARNING*   This MAY break configurations where the client uses
> +                ``--disable-occ`` feature where the ``--cipher`` has
> +                not been explicitly configured on both client and
> +                server side.  It is recommended to remove the ``--disable-occ``
> +                option *or* explicitly add ``--cipher AES-256-GCM`` on the
> +                client side if ``--disable-occ`` is strictly needed.
> +
>  Overview of changes in 2.4
>  ==========================
>
> diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in
> index d1cc72cb..f3545ff5 100644
> --- a/distro/systemd/openvpn-server@.service.in
> +++ b/distro/systemd/openvpn-server@.service.in
> @@ -10,7 +10,7 @@ Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
>  Type=notify
>  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

This is why I keep my openvpn servers out of systemd's view -- it
keeps deciding what's good for us. I want to run my configs as is.

Selva
Kristof Provost via Openvpn-devel June 22, 2020, 7:20 a.m. UTC | #6 
Hi,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday 22 June 2020 18:58, Selva Nair <selva.nair@gmail.com> wrote:

> On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth davids@openvpn.net wrote:
>
> > This change makes the server use AES-256-GCM instead of BF-CBC as the
> > default cipher for the VPN tunnel when starting OpenVPN via systemd
> > and the openvpn-server@.service unit file.
> > To avoid breaking existing running configurations defaulting to BF-CBC,
> > the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in
> > addition to AES-CBC. This makes it possible to migrate existing older
> > client configurations one-by-one to use at least AES-CBC unless the
> > client is updated to v2.4 or newer (which defaults to upgrade to
> > AES-GCM automatically)
> > This has been tested in Fedora 27 (released November 2017) with no
> > reported issues. By making this default for all Linux distributions
> > with systemd shipping with the unit files we provide, we gradually
> > expand setups using this possibility. As we gather experience from
> > this change, we can further move these changes into the defaults of
> > the OpenVPN binary itself with time.
> >
> > Signed-off-by: David Sommerseth davids@openvpn.net
> >
> > ---------------------------------------------------
> >
> > Changes.rst | 15 +++++++++++++++
> > distro/systemd/openvpn-server@.service.in | 2 +-
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> > diff --git a/Changes.rst b/Changes.rst
> > index 00dd6ed8..e76d3c73 100644
> > --- a/Changes.rst
> > +++ b/Changes.rst
> > @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support
> > channel.
> > +User-visible Changes
> > +--------------------
> > +New default cipher for systemd based Linux distributions
> >
> > -   For Linux distributions with systemd which packages the systemd unit files
> > -   from the OpenVPN project, the default cipher is now changed to AES-256-GCM,
> > -   with BF-CBC as a fallback through the NCP feature. This change has been
> > -   tested successfully since the Fedora 27 release (released November 2017).
> > -
> > -   WARNING This MAY break configurations where the client uses
> > -                  ``--disable-occ`` feature where the ``--cipher`` has
> >
> >
> > -                  not been explicitly configured on both client and
> >
> >
> > -                  server side.  It is recommended to remove the ``--disable-occ``
> >
> >
> > -                  option *or* explicitly add ``--cipher AES-256-GCM`` on the
> >
> >
> > -                  client side if ``--disable-occ`` is strictly needed.
> >
> >
> > -
> >
> > Overview of changes in 2.4
> >
> > ===========================
> >
> > diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in
> > index d1cc72cb..f3545ff5 100644
> > --- a/distro/systemd/openvpn-server@.service.in
> > +++ b/distro/systemd/openvpn-server@.service.in
> > @@ -10,7 +10,7 @@ Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
> > Type=notify
> > 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
>
> This is why I keep my openvpn servers out of systemd's view -- it
> keeps deciding what's good for us. I want to run my configs as is.
>
> Selva
>
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Sorry for the noise in advance but I agree.
No idea how to keep it out of systemd's view :) but I change the line to
-ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
+ExecStart=@sbindir@/openvpn --config %i.conf
and do everything in %i.conf
No unexpected configuration behaviour that way like missing timestamps in log.

Pippin
David Sommerseth June 22, 2020, 7:53 a.m. UTC | #7 
On 22/06/2020 19:20, André via Openvpn-devel wrote:
> Hi,
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday 22 June 2020 18:58, Selva Nair <selva.nair@gmail.com> wrote:
> 
>> On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth davids@openvpn.net wrote:
>>
>>> This change makes the server use AES-256-GCM instead of BF-CBC as the
>>> default cipher for the VPN tunnel when starting OpenVPN via systemd
>>> and the openvpn-server@.service unit file.
>>> To avoid breaking existing running configurations defaulting to BF-CBC,
>>> the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in
>>> addition to AES-CBC. This makes it possible to migrate existing older
>>> client configurations one-by-one to use at least AES-CBC unless the
>>> client is updated to v2.4 or newer (which defaults to upgrade to
>>> AES-GCM automatically)
>>> This has been tested in Fedora 27 (released November 2017) with no
>>> reported issues. By making this default for all Linux distributions
>>> with systemd shipping with the unit files we provide, we gradually
>>> expand setups using this possibility. As we gather experience from
>>> this change, we can further move these changes into the defaults of
>>> the OpenVPN binary itself with time.
>>>
>>> Signed-off-by: David Sommerseth davids@openvpn.net
>>>
>>> ---------------------------------------------------
>>>
>>> Changes.rst | 15 +++++++++++++++
>>> distro/systemd/openvpn-server@.service.in | 2 +-
>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>> diff --git a/Changes.rst b/Changes.rst
>>> index 00dd6ed8..e76d3c73 100644
>>> --- a/Changes.rst
>>> +++ b/Changes.rst
>>> @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support
>>> channel.
>>> +User-visible Changes
>>> +--------------------
>>> +New default cipher for systemd based Linux distributions
>>>
>>> -   For Linux distributions with systemd which packages the systemd unit files
>>> -   from the OpenVPN project, the default cipher is now changed to AES-256-GCM,
>>> -   with BF-CBC as a fallback through the NCP feature. This change has been
>>> -   tested successfully since the Fedora 27 release (released November 2017).
>>> -
>>> -   WARNING This MAY break configurations where the client uses
>>> -                  ``--disable-occ`` feature where the ``--cipher`` has
>>>
>>>
>>> -                  not been explicitly configured on both client and
>>>
>>>
>>> -                  server side.  It is recommended to remove the ``--disable-occ``
>>>
>>>
>>> -                  option *or* explicitly add ``--cipher AES-256-GCM`` on the
>>>
>>>
>>> -                  client side if ``--disable-occ`` is strictly needed.
>>>
>>>
>>> -
>>>
>>> Overview of changes in 2.4
>>>
>>> ===========================
>>>
>>> diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in
>>> index d1cc72cb..f3545ff5 100644
>>> --- a/distro/systemd/openvpn-server@.service.in
>>> +++ b/distro/systemd/openvpn-server@.service.in
>>> @@ -10,7 +10,7 @@ Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
>>> Type=notify
>>> 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
>>
>> This is why I keep my openvpn servers out of systemd's view -- it
>> keeps deciding what's good for us. I want to run my configs as is.
>>
>> Selva
>>
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 
> Sorry for the noise in advance but I agree.
> No idea how to keep it out of systemd's view :) but I change the line to
> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
> +ExecStart=@sbindir@/openvpn --config %i.conf
> and do everything in %i.conf
> No unexpected configuration behaviour that way like missing timestamps in log.

The --suppress-timestamps is actually the _only_ option there which cannot be
overridden.  By not having it there, a lot of users would be annoyed by
duplicated timestamps in their logs when they don't use log files directly.
But I can agree, having a way to override this option could be beneficial for
some users.

There might be many reasons why to use separate log files, but on a busy
server it may actually slow openvpn down a little bit (it is still single
threaded and logging happens in the same thread as key negotiations and VPN
network traffic) - especially if file write caches fills up and the fprint()
calls are blocked until file system has synced up.

By default, all logging is easily accessible via 'journalctl -u
openvpn-server@CONFIG_NAME', where you can do all sorts of filtering (like
--since today or --since yesterday ... and you can pipe it through grep if you
want).  The journal also has built in log rotation plus it ensures your file
system will never go completely full (unless you've explicitly disabled that
feature).  Plus it contains a lot more meta-data to use for filtering and
debugging than most other logging systems on Linux these days (try journalctl
-o json-pretty); we don't make use of those features in openvpn 2.x though.

If you do have a syslog daemon running, all logging will normally also go to
the syslog files as well (where rsyslog and syslog-ng allows you to filter out
log events from specific servivces to a separate log file, if that's a
requirement).  Most distros also ship with preconfigured log rotation tools,
or the syslog service has that included into the service.

By using the journal or syslog will _not_ block openvpn when it does log
operations.

I can understand if you feel I have this "I know better" attitude here.  I
really don't intend that, but I also do not understand this resistance of new
tools which can really make your life simpler - if you just care enough to
learn these new tools.  Neither systemd nor the journal are new tools these days.

On the other hand ... this resistance to embrace new tools might also explain
better why some users are still clinging to BF-CBC - *not* saying they are the
same persons ... but, as Steffan said in regards to BF-CBC, we need to move on
... also on the tooling around openvpn.
David Sommerseth June 22, 2020, 7:59 a.m. UTC | #8 
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.
Dmitry Melekhov June 22, 2020, 6:16 p.m. UTC | #9 
22.06.2020 20:58, Selva Nair пишет:
> +*WARNING*    This MAY break configurations where the client uses
> +                ``--disable-occ`` feature where the ``--cipher`` has
> +                not been explicitly configured on both client and
> +                server side.  It is recommended to remove the ``--disable-occ``
> +                option*or*  explicitly add ``--cipher AES-256-GCM`` on the
> +                client side if ``--disable-occ`` is strictly needed.

Well, may be it is possible to add support for setting cipher in ccd

as it was possible before 2.4.9 using patch from here

https://community.openvpn.net/openvpn/ticket/845

?


Thank you!
Arne Schwabe June 22, 2020, 10:34 p.m. UTC | #10 
Am 23.06.20 um 06:16 schrieb Dmitry Melekhov:
> 22.06.2020 20:58, Selva Nair пишет:
>> +*WARNING*    This MAY break configurations where the client uses
>> +                ``--disable-occ`` feature where the ``--cipher`` has
>> +                not been explicitly configured on both client and
>> +                server side.  It is recommended to remove the
>> ``--disable-occ``
>> +                option*or*  explicitly add ``--cipher AES-256-GCM``
>> on the
>> +                client side if ``--disable-occ`` is strictly needed.
> 
> Well, may be it is possible to add support for setting cipher in ccd
> 
> as it was possible before 2.4.9 using patch from here
> 
> https://community.openvpn.net/openvpn/ticket/845
>

I get that this might have been needed in 2.4.x with the first version
of NCP. But the NCP negoiation in 2.5.x should handle all use cases.

Help me understand why --cipher in ccd should be needed?

Arne
Dmitry Melekhov June 22, 2020, 10:52 p.m. UTC | #11 
23.06.2020 12:34, Arne Schwabe пишет:
> Am 23.06.20 um 06:16 schrieb Dmitry Melekhov:
>> 22.06.2020 20:58, Selva Nair пишет:
>>> +*WARNING*    This MAY break configurations where the client uses
>>> +                ``--disable-occ`` feature where the ``--cipher`` has
>>> +                not been explicitly configured on both client and
>>> +                server side.  It is recommended to remove the
>>> ``--disable-occ``
>>> +                option*or*  explicitly add ``--cipher AES-256-GCM``
>>> on the
>>> +                client side if ``--disable-occ`` is strictly needed.
>> Well, may be it is possible to add support for setting cipher in ccd
>>
>> as it was possible before 2.4.9 using patch from here
>>
>> https://community.openvpn.net/openvpn/ticket/845
>>
> I get that this might have been needed in 2.4.x with the first version
> of NCP. But the NCP negoiation in 2.5.x should handle all use cases.
>
> Help me understand why --cipher in ccd should be needed?
>
> Arne
>
There are openvpn 2.3 clients in 3g routers which  are built without 
ability to inform server about cipher, so server uses default cipher for 
them,

in case you need to change default cipher on server you can't do this , 
because clients will not work, it is also impossible to change default 
cipher on all clients at once,

so this is where ability to set default cipher on ccd helps.  All these 
are explained in ticket.

Thanks to patch author we were able to change default cipher without 
downtime.

btw, we still run such routers but can't do the same procedure because 
patch is not compatible with 2.4.9 if for some reason current cipher 
will became nonsecure as blowfish.


Thank you!
Gert Doering June 22, 2020, 11:02 p.m. UTC | #12 
Hi,

On Tue, Jun 23, 2020 at 10:34:47AM +0200, Arne Schwabe wrote:
> > Well, may be it is possible to add support for setting cipher in ccd
> > 
> > as it was possible before 2.4.9 using patch from here
> > 
> > https://community.openvpn.net/openvpn/ticket/845
> >
> 
> I get that this might have been needed in 2.4.x with the first version
> of NCP. But the NCP negoiation in 2.5.x should handle all use cases.
> 
> Help me understand why --cipher in ccd should be needed?

Non-negotiated (because dumb clients) per-client cipher - e.g. for 
migration.

That patch is from Steffan, and review has been sitting in my lap for
way too long.  Need to see if it still applies.

gert
Dmitry Melekhov June 22, 2020, 11:12 p.m. UTC | #13 
23.06.2020 13:02, Gert Doering пишет:
>
>
> That patch is from Steffan, and review has been sitting in my lap for
> way too long.  Need to see if it still applies.
>

Unfortunately it is not compatible with 2.4.9, because of introduced 
change...
Gert Doering June 22, 2020, 11:31 p.m. UTC | #14 
Hi,

On Tue, Jun 23, 2020 at 01:12:42PM +0400, Dmitry Melekhov wrote:
> 23.06.2020 13:02, Gert Doering ??????????:
> > That patch is from Steffan, and review has been sitting in my lap for
> > way too long.  Need to see if it still applies.
> 
> Unfortunately it is not compatible with 2.4.9, because of introduced 
> change...

Depending on how intrusive that patch is, it won't go into 2.4.9 anyway
but into git master (to be 2.5.0 "some time this summer").

gert
Arne Schwabe June 24, 2020, 12:12 a.m. UTC | #15 
> There are openvpn 2.3 clients in 3g routers which  are built without
> ability to inform server about cipher, so server uses default cipher for
> them,
> 
> in case you need to change default cipher on server you can't do this ,
> because clients will not work, it is also impossible to change default
> cipher on all clients at once,
> 
> so this is where ability to set default cipher on ccd helps.  All these
> are explained in ticket.
> 
> Thanks to patch author we were able to change default cipher without
> downtime.
> 
> btw, we still run such routers but can't do the same procedure because
> patch is not compatible with 2.4.9 if for some reason current cipher
> will became nonsecure as blowfish.
> 

Allowing to be able to specify ncp-fallback-cipher from my proposal per
ccd if no NCP could be performed would also fix your use case, right?

Arne
Dmitry Melekhov June 24, 2020, 12:37 a.m. UTC | #16 
24.06.2020 14:12, Arne Schwabe пишет:
>> There are openvpn 2.3 clients in 3g routers which  are built without
>> ability to inform server about cipher, so server uses default cipher for
>> them,
>>
>> in case you need to change default cipher on server you can't do this ,
>> because clients will not work, it is also impossible to change default
>> cipher on all clients at once,
>>
>> so this is where ability to set default cipher on ccd helps.  All these
>> are explained in ticket.
>>
>> Thanks to patch author we were able to change default cipher without
>> downtime.
>>
>> btw, we still run such routers but can't do the same procedure because
>> patch is not compatible with 2.4.9 if for some reason current cipher
>> will became nonsecure as blowfish.
>>
> Allowing to be able to specify ncp-fallback-cipher from my proposal per
> ccd if no NCP could be performed would also fix your use case, right?
>

Yes, sure!

Thank you!
Steffan Karger June 29, 2020, 10:29 p.m. UTC | #17 
Hi,

On 22-06-2020 16:01, Arne Schwabe wrote:
> Am 22.06.20 um 14:43 schrieb Steffan Karger:
>> 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.
> 
> I had a different suggestion in the channel:
> 
> - Deprecate ncp-disable. Reason: Was a good debug switch when introduced
> should not be necessary anymore.

Deprecate in 2.5, remove in 2.6 makes sense to me.

Should we do the same for --cipher in P2MP configs?

> - Introduce ncp-fallback-cipher for compatibility with ncp-disable/old
> versions
>     - needs to be a cipher from ncp-ciphers list
>     - Eventually default the first cipher from ncp-ciphers list
>     - in 2.5 default to --cipher if --cipher is set and automatically
> add cipher to ncp-ciphers and set ncp-fallback-cipher.
> 
>     - If cipher is not set
> 	a) warn about that cipher will be ignored in p2mp mode and if BF-CBC is
> still needed (e.g. peer 2.3 or older) that ncp-fallback-cipher should be set
>         b) same a) but do it automatically for the user+warn
> 
> This allows us to eventually get rid of --cipher while providing still a
> smooth transaction.

That does sounds more friendly than my proposal.

But do we really need an extra option? Does is really differ so much
from changing the default cipher to AES-256-CBC? Both proposals require
config changes to keep old clients working with 2.5+ if --cipher wasn't
set explicitly.

We already have a lot of things in place to cater for a smooth transition:
 - 2.4+ does NCP by default.
 - Any 2.4+ client always sends OCC strings, which makes "poor man's
NCP" work for --ncp-disable clients as long as their cipher is in the
server's --ncp-ciphers list.
 - pre-2.4 clients almost always send OCC strings too, except for
ENABLE_SMALL builds.
 - If NCP and poor-man's NCP fail, 2.5 can (if --cipher is explicitly
set) fall back to whatever is in --cipher and print a big fat warning
that this connection will break in 2.6.
 - If someone *really* wants to have 2.3 ENABLE_SMALL clients connect to
a 2.6 server, they can run a separate server for those clients with only
the cipher of their choice in --ncp-ciphers ("Fall back to the first
cipher", as you proposed).

Basically: if we can agree to no longer guarantee interoperability
between 2.6+ and 2.3- ("mostly just works, but special cases - in
particular ENABLE_SMALL builds - might break"), I don't think we need to
add yet another option.

-Steffan
Steffan Karger June 29, 2020, 10:41 p.m. UTC | #18 
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
Arne Schwabe July 11, 2020, 2:05 p.m. UTC | #19 
Am 23.06.20 um 11:12 schrieb Dmitry Melekhov:
> 23.06.2020 13:02, Gert Doering пишет:
>>
>>
>> That patch is from Steffan, and review has been sitting in my lap for
>> way too long.  Need to see if it still applies.
>>
> 
> Unfortunately it is not compatible with 2.4.9, because of introduced
> change...

Can you test with current openvpn master if that works for you? That has
now allows you set the --cipher in ccd/connect-client scripts.

Arne
Dmitry Melekhov July 12, 2020, 7:36 p.m. UTC | #20 
12.07.2020 04:05, Arne Schwabe пишет:
> Am 23.06.20 um 11:12 schrieb Dmitry Melekhov:
>> 23.06.2020 13:02, Gert Doering пишет:
>>>
>>> That patch is from Steffan, and review has been sitting in my lap for
>>> way too long.  Need to see if it still applies.
>>>
>> Unfortunately it is not compatible with 2.4.9, because of introduced
>> change...
> Can you test with current openvpn master if that works for you? That has
> now allows you set the --cipher in ccd/connect-client scripts.
>
> Arne
>
Hello!

Compiled master from git, installed on server copy with Ubuntu 18.04.

Compiled  the same master with enable-small on my Ubuntu 20.04 desktop.

Added ncp-disable to config.

If cipher is different from default on client and there is no cipher in 
ccd for client - connection fails.

If I add specific cipher to client, i.e. ciphers match- everything is fine.


So, looks like it works, but unfortunately, there is problem:


Then I compiled openvpn-2.3.18 on Centos 6.

It connects if it is compiled by just  using configure.

But if I compile 2.3.18 with enable-small, then 2.5 server dies, always, 
even if there is no cipher in ccd and ciphers match.

On client side:

./openvpn belkam.ovpn
Mon Jul 13 09:33:17 2020 OpenVPN 2.3.18 x86_64-unknown-linux-gnu [SSL 
(OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 13 2020
Mon Jul 13 09:33:17 2020 library versions: OpenSSL 1.0.1e-fips 11 Feb 
2013, LZO 2.03
Enter Auth Username:dm
Enter Auth Password:
Mon Jul 13 09:33:20 2020 WARNING: No server certificate verification 
method has been enabled.  See http://openvpn.net/howto.html#mitm for 
more info.
Mon Jul 13 09:33:20 2020 WARNING: file '/home/dm/openvpn/dm.key' is 
group or others accessible
Mon Jul 13 09:33:20 2020 Socket Buffers: R=[87380->87380] S=[16384->16384]
Mon Jul 13 09:33:20 2020 Attempting to establish TCP connection with 
[AF_INET]192.168.222.2:1194 [nonblock]
Mon Jul 13 09:33:21 2020 TCP connection established with 
[AF_INET]192.168.222.2:1194
Mon Jul 13 09:33:21 2020 TCPv4_CLIENT link local: [undef]
Mon Jul 13 09:33:21 2020 TCPv4_CLIENT link remote: 
[AF_INET]192.168.222.2:1194
Mon Jul 13 09:33:21 2020 TLS: Initial packet from 
[AF_INET]192.168.222.2:1194, sid=7c5295f5 d243c13b
Mon Jul 13 09:33:21 2020 WARNING: this configuration may cache passwords 
in memory -- use the auth-nocache option to prevent this
Mon Jul 13 09:33:21 2020 VERIFY OK: depth=1, C=RU, ST=Udm, L=Izhevsk, 
O=Belkam, OU=UIT, CN=vpn.belkam.com, emailAddress=support@belkam.com
Mon Jul 13 09:33:21 2020 VERIFY OK: depth=0, C=RU, ST=Udm, L=Izhevsk, 
O=Belkam, OU=UIT, CN=ovpn1, emailAddress=support@belkam.com
Mon Jul 13 09:33:22 2020 Data Channel Encrypt: Cipher 'AES-256-CBC' 
initialized with 256 bit key
Mon Jul 13 09:33:22 2020 Data Channel Encrypt: Using 160 bit message 
hash 'SHA1' for HMAC authentication
Mon Jul 13 09:33:22 2020 Data Channel Decrypt: Cipher 'AES-256-CBC' 
initialized with 256 bit key
Mon Jul 13 09:33:22 2020 Data Channel Decrypt: Using 160 bit message 
hash 'SHA1' for HMAC authentication
Mon Jul 13 09:33:22 2020 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Mon Jul 13 09:33:22 2020 [ovpn1] Peer Connection Initiated with 
[AF_INET]192.168.222.2:1194
Mon Jul 13 09:33:22 2020 Connection reset, restarting [0]
Mon Jul 13 09:33:22 2020 SIGUSR1[soft,connection-reset] received, 
process restarting
Mon Jul 13 09:33:22 2020 Restart pause, 5 second(s)

On server side:

Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Main process 
exited, code=killed, status=11/SEGV
Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Killing 
process 9231 (openvpn) with signal SIGKILL.
Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Failed with 
result 'signal'.


Servers just dies...

Thank you!
Dmitry Melekhov July 12, 2020, 8:07 p.m. UTC | #21 
13.07.2020 09:36, Dmitry Melekhov пишет:
> 12.07.2020 04:05, Arne Schwabe пишет:
>> Am 23.06.20 um 11:12 schrieb Dmitry Melekhov:
>>> 23.06.2020 13:02, Gert Doering пишет:
>>>>
>>>> That patch is from Steffan, and review has been sitting in my lap for
>>>> way too long.  Need to see if it still applies.
>>>>
>>> Unfortunately it is not compatible with 2.4.9, because of introduced
>>> change...
>> Can you test with current openvpn master if that works for you? That has
>> now allows you set the --cipher in ccd/connect-client scripts.
>>
>> Arne
>>
> Hello!
>
> Compiled master from git, installed on server copy with Ubuntu 18.04.
>
> Compiled  the same master with enable-small on my Ubuntu 20.04 desktop.
>
> Added ncp-disable to config.
>
> If cipher is different from default on client and there is no cipher 
> in ccd for client - connection fails.
>
> If I add specific cipher to client, i.e. ciphers match- everything is 
> fine.
>
>
> So, looks like it works, but unfortunately, there is problem:
>
>
> Then I compiled openvpn-2.3.18 on Centos 6.
>
> It connects if it is compiled by just  using configure.
>
> But if I compile 2.3.18 with enable-small, then 2.5 server dies, 
> always, even if there is no cipher in ccd and ciphers match.
>
> On client side:
>
> ./openvpn belkam.ovpn
> Mon Jul 13 09:33:17 2020 OpenVPN 2.3.18 x86_64-unknown-linux-gnu [SSL 
> (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 13 2020
> Mon Jul 13 09:33:17 2020 library versions: OpenSSL 1.0.1e-fips 11 Feb 
> 2013, LZO 2.03
> Enter Auth Username:dm
> Enter Auth Password:
> Mon Jul 13 09:33:20 2020 WARNING: No server certificate verification 
> method has been enabled.  See http://openvpn.net/howto.html#mitm for 
> more info.
> Mon Jul 13 09:33:20 2020 WARNING: file '/home/dm/openvpn/dm.key' is 
> group or others accessible
> Mon Jul 13 09:33:20 2020 Socket Buffers: R=[87380->87380] 
> S=[16384->16384]
> Mon Jul 13 09:33:20 2020 Attempting to establish TCP connection with 
> [AF_INET]192.168.222.2:1194 [nonblock]
> Mon Jul 13 09:33:21 2020 TCP connection established with 
> [AF_INET]192.168.222.2:1194
> Mon Jul 13 09:33:21 2020 TCPv4_CLIENT link local: [undef]
> Mon Jul 13 09:33:21 2020 TCPv4_CLIENT link remote: 
> [AF_INET]192.168.222.2:1194
> Mon Jul 13 09:33:21 2020 TLS: Initial packet from 
> [AF_INET]192.168.222.2:1194, sid=7c5295f5 d243c13b
> Mon Jul 13 09:33:21 2020 WARNING: this configuration may cache 
> passwords in memory -- use the auth-nocache option to prevent this
> Mon Jul 13 09:33:21 2020 VERIFY OK: depth=1, C=RU, ST=Udm, L=Izhevsk, 
> O=Belkam, OU=UIT, CN=vpn.belkam.com, emailAddress=support@belkam.com
> Mon Jul 13 09:33:21 2020 VERIFY OK: depth=0, C=RU, ST=Udm, L=Izhevsk, 
> O=Belkam, OU=UIT, CN=ovpn1, emailAddress=support@belkam.com
> Mon Jul 13 09:33:22 2020 Data Channel Encrypt: Cipher 'AES-256-CBC' 
> initialized with 256 bit key
> Mon Jul 13 09:33:22 2020 Data Channel Encrypt: Using 160 bit message 
> hash 'SHA1' for HMAC authentication
> Mon Jul 13 09:33:22 2020 Data Channel Decrypt: Cipher 'AES-256-CBC' 
> initialized with 256 bit key
> Mon Jul 13 09:33:22 2020 Data Channel Decrypt: Using 160 bit message 
> hash 'SHA1' for HMAC authentication
> Mon Jul 13 09:33:22 2020 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 
> ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
> Mon Jul 13 09:33:22 2020 [ovpn1] Peer Connection Initiated with 
> [AF_INET]192.168.222.2:1194
> Mon Jul 13 09:33:22 2020 Connection reset, restarting [0]
> Mon Jul 13 09:33:22 2020 SIGUSR1[soft,connection-reset] received, 
> process restarting
> Mon Jul 13 09:33:22 2020 Restart pause, 5 second(s)
>
> On server side:
>
> Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Main process 
> exited, code=killed, status=11/SEGV
> Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Killing 
> process 9231 (openvpn) with signal SIGKILL.
> Jul 13 09:33:22 ovpn1 systemd[1]: openvpn@server.service: Failed with 
> result 'signal'.
>
>
> Servers just dies...


Forgot to add info from server console, last messages  are:


2020-07-13 10:04:41 us=435946 10.1.1.17:53148 WARNING: 'version' is used 
inconsistently, local='version V4', remote='version V0 UNDEF'
2020-07-13 10:04:41 us=435976 10.1.1.17:53148 WARNING: 'dev-type' is 
present in local config but missing in remote config, local='dev-type tun'
2020-07-13 10:04:41 us=436004 10.1.1.17:53148 WARNING: 'link-mtu' is 
present in local config but missing in remote config, local='link-mtu 1560'
2020-07-13 10:04:41 us=436029 10.1.1.17:53148 WARNING: 'tun-mtu' is 
present in local config but missing in remote config, local='tun-mtu 1500'
2020-07-13 10:04:41 us=436054 10.1.1.17:53148 WARNING: 'comp-lzo' is 
present in local config but missing in remote config, local='comp-lzo'
2020-07-13 10:04:41 us=436078 10.1.1.17:53148 WARNING: 'cipher' is 
present in local config but missing in remote config, local='cipher 
AES-256-CBC'
2020-07-13 10:04:41 us=436104 10.1.1.17:53148 WARNING: 'auth' is present 
in local config but missing in remote config, local='auth SHA1'
2020-07-13 10:04:41 us=436127 10.1.1.17:53148 WARNING: 'keysize' is 
present in local config but missing in remote config, local='keysize 256'
2020-07-13 10:04:41 us=436152 10.1.1.17:53148 WARNING: 'tls-client' is 
present in local config but missing in remote config, local='tls-client'
2020-07-13 10:04:41 us=436327 10.1.1.17:53148 TCPv4_SERVER WRITE [268] 
to [AF_INET]10.1.1.17:53148: P_CONTROL_V1 kid=0 [ 4 ] pid=5 DATA len=242
2020-07-13 10:04:41 us=460634 10.1.1.17:53148 TCPv4_SERVER READ [22] 
from [AF_INET]10.1.1.17:53148: P_ACK_V1 kid=0 [ 5 ]
2020-07-13 10:04:41 us=460719 10.1.1.17:53148 Control Channel: TLSv1.2, 
cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
2020-07-13 10:04:41 us=460770 10.1.1.17:53148 [dm] Peer Connection 
Initiated with [AF_INET]10.1.1.17:53148
2020-07-13 10:04:41 us=460894 dm/10.1.1.17:53148 OPTIONS IMPORT: reading 
client specific options from: ccd/dm
2020-07-13 10:04:41 us=463521 dm/10.1.1.17:53148 OPTIONS IMPORT: reading 
client specific options from: 
/tmp/openvpn_cc_593ba3a3a328173c613df936795e0647.tmp
2020-07-13 10:04:41 us=463769 dm/10.1.1.17:53148 MULTI: Learn: 
192.168.43.74 -> dm/10.1.1.17:53148
2020-07-13 10:04:41 us=463813 dm/10.1.1.17:53148 MULTI: primary virtual 
IP for dm/10.1.1.17:53148: 192.168.43.74
Ошибка сегментирования


root@ovpn1:/etc/openvpn/ccd# cat dm
ifconfig-push 192.168.43.74 255.255.255.0

root@ovpn1:/etc/openvpn/ccd#



>
> Thank you!
>
>
btw
Gert Doering July 12, 2020, 8:10 p.m. UTC | #22 
Hi,

On Mon, Jul 13, 2020 at 09:36:45AM +0400, Dmitry Melekhov wrote:
> Then I compiled openvpn-2.3.18 on Centos 6.
> 
> It connects if it is compiled by just  using configure.
> 
> But if I compile 2.3.18 with enable-small, then 2.5 server dies, always, 
> even if there is no cipher in ccd and ciphers match.

Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
no OCC *and* no NCP = the server runs across a NULL pointer here".

Can you run the server side with --verb 4 to get a bit more log before
the crash?

I'll see that I can reproduce this on my end as well.

gert
Gert Doering July 12, 2020, 8:12 p.m. UTC | #23 
Hi,

On Mon, Jul 13, 2020 at 10:07:38AM +0400, dm wrote:
> Forgot to add info from server console, last messages  are:
> 
> 2020-07-13 10:04:41 us=435946 10.1.1.17:53148 WARNING: 'version' is used 
> inconsistently, local='version V4', remote='version V0 UNDEF'
> 2020-07-13 10:04:41 us=435976 10.1.1.17:53148 WARNING: 'dev-type' is 
> present in local config but missing in remote config, local='dev-type tun'

Yeah, it's "no OCC and no NCP".  Should be easy to reproduce here.

thanks,

gert
Gert Doering July 12, 2020, 8:33 p.m. UTC | #24 
Hi,

On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
> Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
> no OCC *and* no NCP = the server runs across a NULL pointer here".

Bäm.  Fully reproduceable here

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7af51be in ?? () from /lib64/libc.so.6
(gdb) where
#0  0x00007ffff7af51be in ?? () from /lib64/libc.so.6
#1  0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>, 
    server_cipher=0x5555555f28da "BF-CBC", 
    peer_info=peer_info@entry=0x5555556781c0 "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, gc=gc@entry=0x55555565e070) at ssl_ncp.c:231
#2  0x000055555558f430 in multi_client_set_protocol_options (c=0x55555565e070)
    at multi.c:1823
#3  multi_connection_established (m=m@entry=0x7fffffffc550, 
    mi=mi@entry=0x55555565deb0) at multi.c:2174
#4  0x00005555555908af in multi_process_post (m=m@entry=0x7fffffffc550, 
    mi=0x55555565deb0, flags=flags@entry=5) at multi.c:2483
#5  0x0000555555590d32 in multi_process_incoming_link (
    m=m@entry=0x7fffffffc550, instance=instance@entry=0x0, 
    mpp_flags=mpp_flags@entry=5) at multi.c:2847

I'll see what I find in there...

gert
Gert Doering July 12, 2020, 8:58 p.m. UTC | #25 
Hi,

On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
> > Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
> > no OCC *and* no NCP = the server runs across a NULL pointer here".
> 
> Bäm.  Fully reproduceable here
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
> (gdb) where
> #0  0x00007ffff7af51be in ?? () from /lib64/libc.so.6
> #1  0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>, 
>     server_cipher=0x5555555f28da "BF-CBC", 
>     peer_info=peer_info@entry=0x5555556781c0 "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, gc=gc@entry=0x55555565e070) at ssl_ncp.c:231

... and this is why (added a msg() call):

2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=, tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC, remote_cipher=(null), server_cipher=BF-CBC

if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
does not want it.


Returning NULL from ncp_get_best_cipher() if there is nothing the client
has to offer works fine, though it triggers this warning

2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927 PUSH: No common cipher between server and client.Expect this connection not to work. Server ncp-ciphers: 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client supported ciphers ''


which we might want to reword for this case ("No information about cipher 
support received from client, cannot ensure correct operation" or so).

Patch appended.

Comments?

gert
Dmitry Melekhov July 12, 2020, 9:12 p.m. UTC | #26 
13.07.2020 10:58, Gert Doering пишет:
> Hi,
>
> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
>> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
>>> Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small =
>>> no OCC *and* no NCP = the server runs across a NULL pointer here".
>> Bäm.  Fully reproduceable here
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>> (gdb) where
>> #0  0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>> #1  0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>,
>>      server_cipher=0x5555555f28da "BF-CBC",
>>      peer_info=peer_info@entry=0x5555556781c0 "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, gc=gc@entry=0x55555565e070) at ssl_ncp.c:231
> ... and this is why (added a msg() call):
>
> 2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=, tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC, remote_cipher=(null), server_cipher=BF-CBC
>
> if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
> does not want it.
>
>
> Returning NULL from ncp_get_best_cipher() if there is nothing the client
> has to offer works fine, though it triggers this warning
>
> 2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927 PUSH: No common cipher between server and client.Expect this connection not to work. Server ncp-ciphers: 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client supported ciphers ''
>
>
> which we might want to reword for this case ("No information about cipher
> support received from client, cannot ensure correct operation" or so).
>
> Patch appended.
>
> Comments?
>
> gert

I just applied patch, now server works correctly with 2.3.18 client 
compiled with enable-small

and with 2.5git with enable-small and ncp-disable in config.

I.e. everything works as expected.


Thank you!
Gert Doering July 12, 2020, 9:14 p.m. UTC | #27 
Hi,

On Mon, Jul 13, 2020 at 11:12:30AM +0400, Dmitry Melekhov wrote:
> I just applied patch, now server works correctly with 2.3.18 client 
> compiled with enable-small
> 
> and with 2.5git with enable-small and ncp-disable in config.
> 
> I.e. everything works as expected.

Thanks for testing and for confirmation.

I'll leave the decision if this is "the right fix" to Arne, but at
least we know where the problem is/was.

gert
Arne Schwabe July 12, 2020, 10:57 p.m. UTC | #28 
Am 13.07.20 um 08:58 schrieb Gert Doering:
> Hi,
> 
> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
>> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
>>> Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
>>> no OCC *and* no NCP = the server runs across a NULL pointer here".
>>
>> Bäm.  Fully reproduceable here
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>> (gdb) where
>> #0  0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>> #1  0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>, 
>>     server_cipher=0x5555555f28da "BF-CBC", 
>>     peer_info=peer_info@entry=0x5555556781c0 "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, gc=gc@entry=0x55555565e070) at ssl_ncp.c:231
> 
> ... and this is why (added a msg() call):
> 
> 2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=, tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC, remote_cipher=(null), server_cipher=BF-CBC
> 
> if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
> does not want it.
> 
> 
> Returning NULL from ncp_get_best_cipher() if there is nothing the client
> has to offer works fine, though it triggers this warning
> 
> 2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927 PUSH: No common cipher between server and client.Expect this connection not to work. Server ncp-ciphers: 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client supported ciphers ''
> 
> 
> which we might want to reword for this case ("No information about cipher 
> support received from client, cannot ensure correct operation" or so).
> 
> Patch appended.
> 
> Comments?




+                }
+                else
+                {
+                    msg(M_INFO, "PUSH: No cipher info received from
client "
+                        "(no NCP and no OCC).  Cannot ensure
compatibility.");
+                }
                 gc_free(&gc);


This is misleading. peer_chipers == "" only says that the peer does not
send IV_CIPHERS/IV_NCP.  I think I would rather do something change the
message to:


	msg(M_INFO, "No NCP data received from peer, falling back to --cipher
'%s'. Peer reports in OCC --cipher '%s'", o->ciphername,
np(tls_multi->remote_ciphername));


This avoid adding another if else for now. And yes for clients without
occ you get that annoying warning in the log but that is okay.


Otherwise ACK.

Arne
Marvin July 13, 2020, 4:23 a.m. UTC | #29 
I’m wondering if the opposite of this scenario has been tested, where the server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries to connect?

I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server is running on an appliance that cannot be upgraded past Linux 2.6, and I don’t think 2.4.x can run on Linux 2.6. 

Marvin 


Sent from my iPhone

> On Jul 13, 2020, at 1:57 AM, Arne Schwabe <arne@rfc2549.org> wrote:
> 
>> Am 13.07.20 um 08:58 schrieb Gert Doering:
>> Hi,
>> 
>>> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
>>>> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
>>>> Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
>>>> no OCC *and* no NCP = the server runs across a NULL pointer here".
>>> 
>>> Bäm.  Fully reproduceable here
>>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>>> (gdb) where
>>> #0  0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>>> #1  0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>, 
>>>    server_cipher=0x5555555f28da "BF-CBC", 
>>>    peer_info=peer_info@entry=0x5555556781c0 "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, gc=gc@entry=0x55555565e070) at ssl_ncp.c:231
>> 
>> ... and this is why (added a msg() call):
>> 
>> 2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=, tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC, remote_cipher=(null), server_cipher=BF-CBC
>> 
>> if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
>> does not want it.
>> 
>> 
>> Returning NULL from ncp_get_best_cipher() if there is nothing the client
>> has to offer works fine, though it triggers this warning
>> 
>> 2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927 PUSH: No common cipher between server and client.Expect this connection not to work. Server ncp-ciphers: 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client supported ciphers ''
>> 
>> 
>> which we might want to reword for this case ("No information about cipher 
>> support received from client, cannot ensure correct operation" or so).
>> 
>> Patch appended.
>> 
>> Comments?
> 
> 
> 
> 
> +                }
> +                else
> +                {
> +                    msg(M_INFO, "PUSH: No cipher info received from
> client "
> +                        "(no NCP and no OCC).  Cannot ensure
> compatibility.");
> +                }
>                 gc_free(&gc);
> 
> 
> This is misleading. peer_chipers == "" only says that the peer does not
> send IV_CIPHERS/IV_NCP.  I think I would rather do something change the
> message to:
> 
> 
>    msg(M_INFO, "No NCP data received from peer, falling back to --cipher
> '%s'. Peer reports in OCC --cipher '%s'", o->ciphername,
> np(tls_multi->remote_ciphername));
> 
> 
> This avoid adding another if else for now. And yes for clients without
> occ you get that annoying warning in the log but that is okay.
> 
> 
> Otherwise ACK.
> 
> Arne
> 
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Gert Doering July 13, 2020, 4:34 a.m. UTC | #30 
Hi,

On Mon, Jul 13, 2020 at 07:23:59AM -0700, Marvin Adeff wrote:
> I???m wondering if the opposite of this scenario has been tested, where the server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries to connect?

It should work, but this is a "should".  It's hard enough to test all
possible combinations of clients and features against git master, so we
do not normally test current clients against out-of-service releases
on the server.

On the other hand we do not purposely break client-server protocol, 
so it *should* work.  It's just not regularily tested.

If you test, and it breaks, please show client and server logs so we can
fix it :-)


> I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server is running on an appliance that cannot be upgraded past Linux 2.6, and I don???t think 2.4.x can run on Linux 2.6. 

You do not want to have an appliance that is running an ancient linux
version connected to the Internet either...

But besides that, compiling OpenVPN 2.4 should be no big problem - it is
not very demanding regarding system environment or OpenSSL version.

For OpenVPN 2.5 (git master) you'll need an update openssl library - but
this is also not hard, you can compile it and install it to a non-default
place ("/usr/local/openssl-1.1.1") and point OpenVPN's configure script
at it.

One of my test clients is FreeBSD 7.4, which stopped receiving updates
in 2013 - but with a local openssl installation, it works fine, with
git master  (this is sort of a "are we using fancy features that break
older unixes now?" lithmus test, not something you want exposed on the
Internet, or something I'd recommend).
Arne Schwabe July 13, 2020, 4:36 a.m. UTC | #31 
Am 13.07.20 um 16:23 schrieb Marvin Adeff:
> I’m wondering if the opposite of this scenario has been tested, where the server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries to connect?
> 
> I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server is running on an appliance that cannot be upgraded past Linux 2.6, and I don’t think 2.4.x can run on Linux 2.6. 

It should still work. We just test these combination less often since
2.3 is very old. However, if you still BF-CBC, this will probably stop
working in OpenVPN 2.6.

Arne
Dmitry Melekhov July 13, 2020, 6:06 a.m. UTC | #32 
13.07.2020 18:23, Marvin Adeff пишет:
> I’m wondering if the opposite of this scenario has been tested, where the server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries to connect?


No, I did not tried this, because we run 2.4.9 on servers now.

>
> I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server is running on an appliance that cannot be upgraded past Linux 2.6, and I don’t think 2.4.x can run on Linux 2.6.
>
>
Well, if you have running server you can easily test :-)
Marvin July 13, 2020, 7:31 a.m. UTC | #33 
Thank you I will try this. 

Marvin 

Sent from my iPhone

> On Jul 13, 2020, at 7:34 AM, Gert Doering <gert@greenie.muc.de> wrote:
> 
> Hi,
> 
>> On Mon, Jul 13, 2020 at 07:23:59AM -0700, Marvin Adeff wrote:
>> I???m wondering if the opposite of this scenario has been tested, where the server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries to connect?
> 
> It should work, but this is a "should".  It's hard enough to test all
> possible combinations of clients and features against git master, so we
> do not normally test current clients against out-of-service releases
> on the server.
> 
> On the other hand we do not purposely break client-server protocol, 
> so it *should* work.  It's just not regularily tested.
> 
> If you test, and it breaks, please show client and server logs so we can
> fix it :-)
> 
> 
>> I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server is running on an appliance that cannot be upgraded past Linux 2.6, and I don???t think 2.4.x can run on Linux 2.6. 
> 
> You do not want to have an appliance that is running an ancient linux
> version connected to the Internet either...
> 
> But besides that, compiling OpenVPN 2.4 should be no big problem - it is
> not very demanding regarding system environment or OpenSSL version.
> 
> For OpenVPN 2.5 (git master) you'll need an update openssl library - but
> this is also not hard, you can compile it and install it to a non-default
> place ("/usr/local/openssl-1.1.1") and point OpenVPN's configure script
> at it.
> 
> One of my test clients is FreeBSD 7.4, which stopped receiving updates
> in 2013 - but with a local openssl installation, it works fine, with
> git master  (this is sort of a "are we using fancy features that break
> older unixes now?" lithmus test, not something you want exposed on the
> Internet, or something I'd recommend).
> -- 
> "If was one thing all people took for granted, was conviction that if you 
> feed honest figures into a computer, honest figures come out. Never doubted 
> it myself till I met a computer with a sense of humor."
>                             Robert A. Heinlein, The Moon is a Harsh Mistress
> 
> Gert Doering - Munich, Germany                             gert@greenie.muc.de
diff mbox series

Patch

diff --git a/Changes.rst b/Changes.rst
index 00dd6ed8..e76d3c73 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -14,6 +14,21 @@  ChaCha20-Poly1305 cipher support
     channel.
 
 
+User-visible Changes
+--------------------
+New default cipher for systemd based Linux distributions
+    For Linux distributions with systemd which packages the systemd unit files
+    from the OpenVPN project, the default cipher is now changed to AES-256-GCM,
+    with BF-CBC as a fallback through the NCP feature.  This change has been
+    tested successfully since the Fedora 27 release (released November 2017).
+
+    *WARNING*   This MAY break configurations where the client uses
+                ``--disable-occ`` feature where the ``--cipher`` has
+                not been explicitly configured on both client and
+                server side.  It is recommended to remove the ``--disable-occ``
+                option *or* explicitly add ``--cipher AES-256-GCM`` on the
+                client side if ``--disable-occ`` is strictly needed.
+
 Overview of changes in 2.4
 ==========================
 
diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in
index d1cc72cb..f3545ff5 100644
--- a/distro/systemd/openvpn-server@.service.in
+++ b/distro/systemd/openvpn-server@.service.in
@@ -10,7 +10,7 @@  Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
 Type=notify
 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