public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
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:
> > 

  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