From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Delete 1024 bit DH-parameter from menu
Date: Tue, 19 Jun 2018 20:39:13 +0200 [thread overview]
Message-ID: <1529433553.13577.15.camel@ipfire.org> (raw)
In-Reply-To: <8bb086ce31c86c409ffa6495a0f9218ff9d92d7f.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]
Hi Michael,
Am Dienstag, den 19.06.2018, 14:03 +0100 schrieb Michael Tremer:
> We need to *warn* people about these changes in advance.
This would be best suited but i didn´t realize that OpenVPN-2.4x do not
accept 1024 bit anymore. All testers seems to oversee this too and the
OpenVPN change log didn´t pointed it out clearly...
> And we need to
> have a visual indicator that some action is required here to replace
> the DH params then.
Started to make a $problemmessage section where we can put also some
other potential or real problems like e.g. check for 'no MD5 for
signature anymore', 'Soon needed RFC3280 compliance for the
certificates' . There is surely more...
Good idea ?
>
> We cannot break things and expect people to find something in the log
> files.
Should be like above written displayed then above the main settings
section like $errormessage.
>
> Can we do that and automatically generate a 2k DH params for them?
> Would the clients notice that this has changed?
Except a little longer time for the handshake the clients won´t realize
this since the DH-parameter takes only place on server side.
Should we do an automatic DH generation of 2k via update.sh with the
next update ?
Best,
Erik
>
> Best,
> -Michael
>
> On Tue, 2018-06-19 at 13:58 +0200, ummeegge wrote:
> >
> > Hi Michael,
> > the connections won´t start for this systems and the logs should
> > display an appropriate error, in that case they will need to
> > recreate
> > it which is possible over the WUI.
> > After the update to Core 120 only a few people wrote about that
> > problem
> > possibly because mostly people do use already 2048 bit.
> >
> > Erik
> >
> > Am Dienstag, den 19.06.2018, 11:31 +0100 schrieb Michael Tremer:
> > >
> > > Hello,
> > >
> > > this patch is fine, but what do we do with systems that already
> > > have
> > > a key
> > > generated with that size?
> > >
> > > -Michael
> > >
> > > On Mon, 2018-06-18 at 19:16 +0200, Erik Kapfer wrote:
> >
next prev parent reply other threads:[~2018-06-19 18:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 17:16 Erik Kapfer
2018-06-19 10:31 ` Michael Tremer
2018-06-19 11:58 ` ummeegge
2018-06-19 13:03 ` Michael Tremer
2018-06-19 18:39 ` ummeegge [this message]
2018-06-21 9:52 ` 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=1529433553.13577.15.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