OpenVPN: Delete 1024 bit DH-parameter from menu

  Since OpenVPN-2.4.x do not accepts 1024 bit DH-parameter for security concerns anymore,
    it has been removed from the menu.

Signed-off-by: Erik Kapfer <erik.kapfer@ipfire.org>
---
 html/cgi-bin/ovpnmain.cgi | 2 --
 1 file changed, 2 deletions(-)
  

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:
> Since OpenVPN-2.4.x do not accepts 1024 bit DH-parameter for security concerns
> anymore,
>     it has been removed from the menu.
> 
> Signed-off-by: Erik Kapfer <erik.kapfer@ipfire.org>
> ---
>  html/cgi-bin/ovpnmain.cgi | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi
> index 0bc28ce..4bc3473 100644
> --- a/html/cgi-bin/ovpnmain.cgi
> +++ b/html/cgi-bin/ovpnmain.cgi
> @@ -1291,7 +1291,6 @@ END
>  		<form method='post'><input type='hidden' name='AREUSURE'
> value='yes' />
>  		<input type='hidden' name='KEY' value='$cgiparams{'KEY'}' />
>  			<select name='DHLENGHT'>
> -				<option value='1024'
> $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'} ($Lang::tr{'vpn
> weak'})</option>
>  				<option value='2048'
> $selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option>
>  				<option value='3072'
> $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option>
>  				<option value='4096'
> $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option>
> @@ -1973,7 +1972,6 @@ END
>  	    </select></td>
>  	<tr><td class='base'>$Lang::tr{'ovpn dh'}:</td>
>  		<td class='base'><select name='DHLENGHT'>
> -				<option value='1024'
> $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'} ($Lang::tr{'vpn
> weak'})</option>
>  				<option value='2048'
> $selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option>
>  				<option value='3072'
> $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option>
>  				<option value='4096'
> $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option>
  

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:
  

We need to *warn* people about these changes in advance. And we need to
have a visual indicator that some action is required here to replace
the DH params then.

We cannot break things and expect people to find something in the log
files.

Can we do that and automatically generate a 2k DH params for them?
Would the clients notice that this has changed?

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:
> 
>
  

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:
> >
  

Hi Michael,

Am Dienstag, den 19.06.2018, 14:03 +0100 schrieb Michael Tremer:
> We need to *warn* people about these changes in advance. And we need
> to
> have a visual indicator that some action is required here to replace
> the DH params then.
> 
> We cannot break things and expect people to find something in the log
> files.

here the first idea how we could solve this
-> https://patchwork.ipfire.
org/patch/1835/ .


Best,

Erik