From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: OpenVPN-2.5.0 update procedure and idea collector
Date: Mon, 23 Nov 2020 15:44:29 +0100 [thread overview]
Message-ID: <872552b2bdeb41dabfa66667095f537824f9c011.camel@ipfire.org> (raw)
In-Reply-To: <adeb05e0-d81a-abdb-4133-ca021a356b76@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5573 bytes --]
Hi Adolf,
and thanks for your feedback.
Am Montag, den 23.11.2020, 12:41 +0100 schrieb Adolf Belka:
> Hi Erik,
>
> Thanks for all your work on OpenVPN. Much appreciated, especially in
> these challenging times of many changes.
thank you too.
>
> Am I correct in my presumption that in the advanced encryption
> settings GUI we will be able to select multiple entries, which will
> then be made into a list in order that the entries are in the tables.
Yes, the negotiation was already introduced in 2.4. The server check
via 'IV_NCP=2' if and then which ciphers the client does support and
uses the first in place then e.g. AES-256-GCM:AES-256-CBC . Same with -
-tls-ciphers and tls-ciphersuites. Every client above 2.4.0 does not
recognize the renegotiation, therefor --data-ciphers-fallback .
>
> From the advanced encryption settings page I see that you have
> removed the old insecure options, which is good.
Yes i would really love to do this as soon as possible but since we
introduce the negotiation not before, older configurations does not
have had the possibility to migrate. My idea is now to leave the old
ciphers for the first in --data-ciphers-fallback, but give the user a
message in the WUI and may also in IPFire blog that he should change as
soon as possible since those (64 bit block ciphers) will be removed
very soon. We can handle this via &pkiconfigcheck function e.g. .
> For the Data-Channel fallback do you have to have a default or can
> you unselect everything. There could be people who only want to
> connect to systems that have the strongest ciphers and just refuse to
> connect with weaker ones.
We can make there a checkbox to disable data-channel-fallback but for
the first time it might be better to leave it there in my opinion for
the above described migration possiblity. It is the substitute for --
cipher.
Nevertheless, if you use --data-ciphers and the clients are OpenVPN >=
2.4.0 or if system library >= OpenSSL-1.1.0 they will use the --data-
ciphers algorithm before --data-cipher-fallback.
>
> For the Control-Channel sections I would suggest swapping the order
> of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most
> secure to least secure from left to right. I think that the
> Control-Channel should do the same.
Gret, good idea. Done.
>
> I don't have any comments about the defaults. They seem reasonable to
> me.
Yes, the cipher listing takes also care of the order i think.
>
> Excellent work, it's looking very nice.
Thanks for the flowers always good to hear :-) .
>
> Regards,
> Adolf.
Best,
Erik
P.S. Short update. I moved now the --cipher and --auth part from the
global to the advanced encryption page. I think the defaults should
handle it for not so experience users so they do not need to bother
around with all that. Am not sure if the layout looks good, for a short
look -->
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_enc_hmac.png
or should we leave it as a flip menu ?
>
>
> On 22/11/2020 17:30, ummeegge wrote:
> > Hi all,
> > i am currently in the update process of the already realeased
> > OpenVPN-
> > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
> > has
> > been tested and worked so far also with the old default client
> > configuration (tested with 2.4.9 client). There are two warnings
> > -->
> >
> > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > negotiation
> > is a deprecated debug feature that will be removed in OpenVPN 2.6
> >
> > 2) WARNING: --topology net30 support for server configs with IPv4
> > pools
> > will be removed in a future release. Please migrate to --topology
> > subnet as soon as possible.
> >
> > in the server log but it nevertheless works flawlessly.
> >
> > Am working currently on an "Advanced Encryption Settings" page
> > which
> > includes currently four new directives --data-ciphers (data channel
> > encryption), --data-ciphers-fallback (data-channel encryption for
> > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > only)
> > and --tls-ciphersuites (control channel >= TLSv3) all options are
> > explained in here -->
> > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > , which works here currently and looks like this:
> >
> > Button to belong to this page:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> >
> > And the page itself:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> >
> >
> > You can see also the default settings, were i need also your ideas
> > and
> > comments for may better defaults.
> > On the page itself is also more planned but to not overload this
> > here
> > now, i wanted to go now a two step procedure with this update.
> >
> > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > regukar
> > global settings for RW and N2N. A overview of the new crypto can be
> > found in here -->
> > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
.
> > 2) I would push the "Advanced Encryption settings" development as
> > seen
> > above then as one patch <-- this would also eliminate the first
> > warning
> > causing --ncp-disable since we can delete this option then.
> >
> > Everything else would come detached from this.
> >
> > Some feedback might be nice.
> >
> > Best,
> >
> > Erik
> >
next prev parent reply other threads:[~2020-11-23 14:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 16:30 ummeegge
2020-11-23 9:14 ` ummeegge
2020-11-23 14:28 ` Kienker, Fred
2020-11-23 14:52 ` ummeegge
2020-11-23 18:06 ` Michael Tremer
2020-11-26 18:47 ` ummeegge
2020-11-26 22:33 ` Adolf Belka
2020-11-27 7:20 ` ummeegge
2020-11-27 12:19 ` Adolf Belka
2020-11-27 13:23 ` ummeegge
2020-11-27 16:43 ` ummeegge
2020-11-27 12:40 ` Adolf Belka
2020-11-27 13:24 ` ummeegge
2020-11-28 5:52 ` ummeegge
2020-11-28 14:12 ` Adolf Belka
2020-11-28 16:00 ` Adolf Belka
2020-11-29 11:15 ` ummeegge
2020-11-29 13:12 ` Adolf Belka
2020-11-29 18:36 ` ummeegge
2020-11-23 11:41 ` Adolf Belka
2020-11-23 14:44 ` ummeegge [this message]
2020-11-23 18:00 ` Michael Tremer
2020-11-23 22:29 ` Adolf Belka
2020-11-24 15:27 ` ummeegge
2020-12-14 14:13 ` Michael Tremer
2020-12-14 14:09 ` Michael Tremer
2020-11-23 17:58 ` Michael Tremer
2020-11-23 19:49 ` ummeegge
2020-11-23 22:38 ` Adolf Belka
2020-11-25 17:10 ` ummeegge
2020-12-14 14:05 ` Michael Tremer
[not found] <92ba003d-a1a9-4f7e-0608-35ff42f64bf8@gmail.com>
2020-12-01 4:26 ` ummeegge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=872552b2bdeb41dabfa66667095f537824f9c011.camel@ipfire.org \
--to=ummeegge@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox