public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: OpenVPN-2.5.0 update procedure and idea collector
Date: Tue, 24 Nov 2020 16:27:45 +0100	[thread overview]
Message-ID: <9d9bcb7f4172d000041a465f4f7ceac6e11ca28e.camel@ipfire.org> (raw)
In-Reply-To: <dee02ad1-2f0c-53a6-cbf9-bf4efc2e852a@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5941 bytes --]

Hi all,

Am Montag, den 23.11.2020, 23:29 +0100 schrieb Adolf Belka:
> Hi Michael,
> 
> 
> On 23/11/2020 19:00, Michael Tremer wrote:
> > Hi,
> > 
> > > On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com>
> > > wrote:
> > > 
> > > Hi Erik,
> > > 
> > > Thanks for all your work on OpenVPN. Much appreciated, especially
> > > in these challenging times of many changes.
> > > 
> > > 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.
> > > 
> > >  From the advanced encryption settings page I see that you have
> > > removed the old insecure options, which is good.
> > 
> > It is good to encourage people to use modern cryptography, but I
> > would like to raise the point that if we want to support older
> > clients, we will have to support the old crypto, too. Otherwise it
> > is not worth to add the extra work if it is virtually unusable.
> 
> I understand the need/desire to support older clients but I just
> wonder how old we should be supporting. Erik's previous page picture
> showed the older crypto (BF-CBC, CAST etc) which were marked Data-
> Channel fallback (insecure). If those are going to be left in then I
> think they should be labelled Data-Channel fallback
> (insecure/deprecated) so people know they are not secure and/or
> likely to disappear before too long.
Did that now in the menu 'insecure/broken' for DES, BF and Cast.
Shouldn´t we probably mark CBC in general also as 'insecure' ?

> 
> I also want to be sure that if these unsecure algorithms are listed
> and selected for fallback I want to be sure that there is no way for
> my system to fallback to using them by accident or whatever. That is
> why I would then like to have the ability to not have any fallback
> algorithm selected. The default can be to have one or more selected
> but I would like to be able to unselect all fallback algorithms if
> they are of this type of security.
Have tested this with a client (2.4.9) which have had AES-256-CBC as --
cipher configured. The server provided --data-ciphers ChaCha20-
Poly1305:AES-256-GCM but also --data-ciphers-fallback AES-256-CBC and
the connection initiated the data channel with AES-256-GCM which i
think is even better than the existing client configuration provides
it. May there are also good news :-) .

> 
> > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > I don't have any comments about the defaults. They seem
> > > reasonable to me.
> > > 
> > > Excellent work, it's looking very nice.
> > > 
> > > Regards,
> > > Adolf.
> > > 
> > > 
> > > 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
> > 



  reply	other threads:[~2020-11-24 15:27 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
2020-11-23 18:00   ` Michael Tremer
2020-11-23 22:29     ` Adolf Belka
2020-11-24 15:27       ` ummeegge [this message]
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=9d9bcb7f4172d000041a465f4f7ceac6e11ca28e.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