OpenVPN: Introduce Negotiable Crypto Parameters for roadwarriors

  The ncp-ciphers differs to the OpenVPN default value and has been adapted from Fedora.
Please see explanations in https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN .
---
 html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++-----------
 langs/de/cgi-bin/de.pl    |  1 +
 langs/en/cgi-bin/en.pl    |  1 +
 3 files changed, 29 insertions(+), 11 deletions(-)
  

Hello,

hmm, I am not sure if I agree with the patch.

Could you answer some questions so that I understand better what the
implications are.

On Mon, 2018-08-06 at 09:25 +0200, Erik Kapfer wrote:
> The ncp-ciphers differs to the OpenVPN default value and has been adapted from Fedora.
> Please see explanations in https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN .
> ---
>  html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++-----------
>  langs/de/cgi-bin/de.pl    |  1 +
>  langs/en/cgi-bin/en.pl    |  1 +
>  3 files changed, 29 insertions(+), 11 deletions(-)
> 
> diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi
> index 976300f..dc22ba5 100644
> --- a/html/cgi-bin/ovpnmain.cgi
> +++ b/html/cgi-bin/ovpnmain.cgi
> @@ -321,8 +321,13 @@ sub writeserverconf {
>      }	
>      print CONF "status-version 1\n";
>      print CONF "status /var/run/ovpnserver.log 30\n";
> -    print CONF "ncp-disable\n";
>      print CONF "cipher $sovpnsettings{DCIPHER}\n";
> +    # Enable Negotiable Crypto Parameters
> +    if ($sovpnsettings{'NCP'} eq 'on') {
> +         print CONF "ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC\n";
> +    } else {
> +        print CONF "ncp-disable\n";
> +    }

Questions here:

1) Why do we hard-code the cipher list?

2) Who would want to disable this as it should always peacefully co-
exists with the "cipher" options.

>      if ($sovpnsettings{'DAUTH'} eq '') {
>          print CONF "";
>      } else {
> @@ -789,6 +794,7 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save-adv-options'}) {
>      $vpnsettings{'ROUTES_PUSH'} = $cgiparams{'ROUTES_PUSH'};
>      $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
>      $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
> +    $vpnsettings{'NCP'} = $cgiparams{'NCP'};
>      my @temp=();
>      
>      if ($cgiparams{'FRAGMENT'} eq '') {
> @@ -2685,6 +2691,9 @@ ADV_ERROR:
>      $checked{'TLSAUTH'}{'off'} = '';
>      $checked{'TLSAUTH'}{'on'} = '';
>      $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
> +    $checked{'NCP'}{'off'} = '';
> +    $checked{'NCP'}{'on'} = '';
> +    $checked{'NCP'}{$cgiparams{'NCP'}} = 'CHECKED';
>     
>      &Header::showhttpheaders();
>      &Header::openpage($Lang::tr{'status ovpn'}, 1, '');
> @@ -2818,6 +2827,22 @@ print <<END;
>      <tr>
>  		<td class'base'><b>$Lang::tr{'ovpn crypt options'}</b></td>
>  	</tr>
> +
> +<table width='100%'>
> +    <tr>
> +    <td width='20%'></td> <td width='15%'> </td><td width='15%'> </td><td width='15%'></td><td width='35%'></td>
> +    </tr>
> +
> +    <tr>
> +         <td class='base'>$Lang::tr{'ovpn ncp'}</td>
> +         <td><input type='checkbox' name='NCP' $checked{'NCP'}{'on'} /></td>
> +    </tr>
> +
> +    <tr>
> +         <td class='base'>HMAC tls-auth</td>
> +         <td><input type='checkbox' name='TLSAUTH' $checked{'TLSAUTH'}{'on'} /></td>
> +    </tr>
> +
>  	<tr>
>  		<td width='20%'></td> <td width='30%'> </td><td width='25%'> </td><td width='25%'></td>
>      </tr>	
> @@ -2833,17 +2858,8 @@ print <<END;
>  		<td>$Lang::tr{'openvpn default'}: <span class="base">SHA1 (160 $Lang::tr{'bit'})</span></td>
>      </tr>
>  </table>
> +<hr size='1'>
>  
> -<table width='100%'>
> -    <tr>
> -	<td width='20%'></td> <td width='15%'> </td><td width='15%'> </td><td width='15%'></td><td width='35%'></td>
> -    </tr>
> -
> -    <tr>
> -	<td class='base'>HMAC tls-auth</td>
> -	<td><input type='checkbox' name='TLSAUTH' $checked{'TLSAUTH'}{'on'} /></td>
> -    </tr>
> -    </table><hr>
>  END
>  
>  if ( -e "/var/run/openvpn.pid"){
> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
> index 6e3dba4..9f0de6b 100644
> --- a/langs/de/cgi-bin/de.pl
> +++ b/langs/de/cgi-bin/de.pl
> @@ -1833,6 +1833,7 @@
>  'ovpn mtu-disc off' => 'Deaktiviert',
>  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery kann nicht gemeinsam mit mssfix oder fragment verwendet werden.',
>  'ovpn mtu-disc yes' => 'Forciert',
> +'ovpn ncp' => 'Verschlüsselung aushandeln',
>  'ovpn no connections' => 'Keine aktiven OpenVPN Verbindungen',
>  'ovpn on blue' => 'OpenVPN auf BLAU:',
>  'ovpn on orange' => 'OpenVPN auf ORANGE:',
> diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
> index 3ec5af5..5cd47b1 100644
> --- a/langs/en/cgi-bin/en.pl
> +++ b/langs/en/cgi-bin/en.pl
> @@ -1866,6 +1866,7 @@
>  'ovpn mtu-disc off' => 'Disabled',
>  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery cannot be used with mssfix or fragment.',
>  'ovpn mtu-disc yes' => 'Forced',
> +'ovpn ncp' => 'Negotiate encryption',

This doesn't fully explain to the user actually is being negotiated.
The control channel? The data channel? TLS?

>  'ovpn no connections' => 'No active OpenVPN connections',
>  'ovpn on blue' => 'OpenVPN on BLUE:',
>  'ovpn on orange' => 'OpenVPN on ORANGE:',

Best,
-Michael
  

Hi Michael,

Am Dienstag, den 07.08.2018, 14:10 +0100 schrieb Michael Tremer:
> Hello,
> 
> hmm, I am not sure if I agree with the patch.
> 
> Could you answer some questions so that I understand better what the
> implications are.
Sure.

> 
> On Mon, 2018-08-06 at 09:25 +0200, Erik Kapfer wrote:
> > The ncp-ciphers differs to the OpenVPN default value and has been
> > adapted from Fedora.
> > Please see explanations in https://fedoraproject.org/wiki/Changes/N
> > ew_default_cipher_in_OpenVPN .
> > ---
> >  html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++------
> > -----
> >  langs/de/cgi-bin/de.pl    |  1 +
> >  langs/en/cgi-bin/en.pl    |  1 +
> >  3 files changed, 29 insertions(+), 11 deletions(-)
> > 
> > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi
> > index 976300f..dc22ba5 100644
> > --- a/html/cgi-bin/ovpnmain.cgi
> > +++ b/html/cgi-bin/ovpnmain.cgi
> > @@ -321,8 +321,13 @@ sub writeserverconf {
> >      }	
> >      print CONF "status-version 1\n";
> >      print CONF "status /var/run/ovpnserver.log 30\n";
> > -    print CONF "ncp-disable\n";
> >      print CONF "cipher $sovpnsettings{DCIPHER}\n";
> > +    # Enable Negotiable Crypto Parameters
> > +    if ($sovpnsettings{'NCP'} eq 'on') {
> > +         print CONF "ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-
> > GCM:AES-128-CBC:BF-CBC\n";
> > +    } else {
> > +        print CONF "ncp-disable\n";
> > +    }
> 
> Questions here:
> 
> 1) Why do we hard-code the cipher list?
There is also the possibility to set --ncp-ciphers only whereby OpenVPN
 uses then AES-256-GCM:AES-128-GCM per default. The linked Fedora
example uses in first place longer keys 256-GCM:256-CBC before 128-GCM
whereby i think longer keys (stronger encryption) where prefered to
128-GCM (192-GCM is also available and might be also an idea ?) .

The second point in there is if a client is 2.4 ready but uses older
OpenSSL libs from the system where no GCM is available, this --ncp-
ciphers list can nevertheless be used.

> 
> 2) Who would want to disable this as it should always peacefully co-
> exists with the "cipher" options.
The --ncp-ciphers option is currently completely disabled and not
available on IPFire and only --ciphers are used just before Core 120
and with OpenVPN-2.3.x .
I think this option is quiet neat if you have a lot´s of clients cause
an client update to >= 2.4 and clicking the checkbox on server side is
enough to change the encryption for very old configurations (BF-CBC old
default) to a strong cipher without the need to generate and distribute
new configuration files to each client.
Have often see that old unsecure configs has been used cause the hassle
to change all of them togehter was simply a lots of stress.

In my case, i won´t disable it cause as you said, it co-exists
peacfully beneath the old directives.

> 
> >      if ($sovpnsettings{'DAUTH'} eq '') {
> >          print CONF "";
> >      } else {
> > @@ -789,6 +794,7 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save-
> > adv-options'}) {
> >      $vpnsettings{'ROUTES_PUSH'} = $cgiparams{'ROUTES_PUSH'};
> >      $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> >      $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
> > +    $vpnsettings{'NCP'} = $cgiparams{'NCP'};
> >      my @temp=();
> >      
> >      if ($cgiparams{'FRAGMENT'} eq '') {
> > @@ -2685,6 +2691,9 @@ ADV_ERROR:
> >      $checked{'TLSAUTH'}{'off'} = '';
> >      $checked{'TLSAUTH'}{'on'} = '';
> >      $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
> > +    $checked{'NCP'}{'off'} = '';
> > +    $checked{'NCP'}{'on'} = '';
> > +    $checked{'NCP'}{$cgiparams{'NCP'}} = 'CHECKED';
> >     
> >      &Header::showhttpheaders();
> >      &Header::openpage($Lang::tr{'status ovpn'}, 1, '');
> > @@ -2818,6 +2827,22 @@ print <<END;
> >      <tr>
> >  		<td class'base'><b>$Lang::tr{'ovpn crypt
> > options'}</b></td>
> >  	</tr>
> > +
> > +<table width='100%'>
> > +    <tr>
> > +    <td width='20%'></td> <td width='15%'> </td><td width='15%'>
> > </td><td width='15%'></td><td width='35%'></td>
> > +    </tr>
> > +
> > +    <tr>
> > +         <td class='base'>$Lang::tr{'ovpn ncp'}</td>
> > +         <td><input type='checkbox' name='NCP'
> > $checked{'NCP'}{'on'} /></td>
> > +    </tr>
> > +
> > +    <tr>
> > +         <td class='base'>HMAC tls-auth</td>
> > +         <td><input type='checkbox' name='TLSAUTH'
> > $checked{'TLSAUTH'}{'on'} /></td>
> > +    </tr>
> > +
> >  	<tr>
> >  		<td width='20%'></td> <td width='30%'> </td><td
> > width='25%'> </td><td width='25%'></td>
> >      </tr>	
> > @@ -2833,17 +2858,8 @@ print <<END;
> >  		<td>$Lang::tr{'openvpn default'}: <span
> > class="base">SHA1 (160 $Lang::tr{'bit'})</span></td>
> >      </tr>
> >  </table>
> > +<hr size='1'>
> >  
> > -<table width='100%'>
> > -    <tr>
> > -	<td width='20%'></td> <td width='15%'> </td><td
> > width='15%'> </td><td width='15%'></td><td width='35%'></td>
> > -    </tr>
> > -
> > -    <tr>
> > -	<td class='base'>HMAC tls-auth</td>
> > -	<td><input type='checkbox' name='TLSAUTH'
> > $checked{'TLSAUTH'}{'on'} /></td>
> > -    </tr>
> > -    </table><hr>
> >  END
> >  
> >  if ( -e "/var/run/openvpn.pid"){
> > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
> > index 6e3dba4..9f0de6b 100644
> > --- a/langs/de/cgi-bin/de.pl
> > +++ b/langs/de/cgi-bin/de.pl
> > @@ -1833,6 +1833,7 @@
> >  'ovpn mtu-disc off' => 'Deaktiviert',
> >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > kann nicht gemeinsam mit mssfix oder fragment verwendet werden.',
> >  'ovpn mtu-disc yes' => 'Forciert',
> > +'ovpn ncp' => 'Verschlüsselung aushandeln',
> >  'ovpn no connections' => 'Keine aktiven OpenVPN Verbindungen',
> >  'ovpn on blue' => 'OpenVPN auf BLAU:',
> >  'ovpn on orange' => 'OpenVPN auf ORANGE:',
> > diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
> > index 3ec5af5..5cd47b1 100644
> > --- a/langs/en/cgi-bin/en.pl
> > +++ b/langs/en/cgi-bin/en.pl
> > @@ -1866,6 +1866,7 @@
> >  'ovpn mtu-disc off' => 'Disabled',
> >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > cannot be used with mssfix or fragment.',
> >  'ovpn mtu-disc yes' => 'Forced',
> > +'ovpn ncp' => 'Negotiate encryption',
> 
> This doesn't fully explain to the user actually is being negotiated.
> The control channel? The data channel? TLS?
It is the data channel. The control channel uses since OpenVPN-2.4.x
 "TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA" and can not be
configured.

If this patch might be interesting, i can also change the description.
If you have an good idea, let it me know.


Best,

Erik
  

Hi,

On Tue, 2018-08-07 at 18:19 +0200, ummeegge wrote:
> Hi Michael,
> 
> Am Dienstag, den 07.08.2018, 14:10 +0100 schrieb Michael Tremer:
> > Hello,
> > 
> > hmm, I am not sure if I agree with the patch.
> > 
> > Could you answer some questions so that I understand better what the
> > implications are.
> 
> Sure.
> 
> > 
> > On Mon, 2018-08-06 at 09:25 +0200, Erik Kapfer wrote:
> > > The ncp-ciphers differs to the OpenVPN default value and has been
> > > adapted from Fedora.
> > > Please see explanations in https://fedoraproject.org/wiki/Changes/N
> > > ew_default_cipher_in_OpenVPN .
> > > ---
> > >  html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++------
> > > -----
> > >  langs/de/cgi-bin/de.pl    |  1 +
> > >  langs/en/cgi-bin/en.pl    |  1 +
> > >  3 files changed, 29 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi
> > > index 976300f..dc22ba5 100644
> > > --- a/html/cgi-bin/ovpnmain.cgi
> > > +++ b/html/cgi-bin/ovpnmain.cgi
> > > @@ -321,8 +321,13 @@ sub writeserverconf {
> > >      }	
> > >      print CONF "status-version 1\n";
> > >      print CONF "status /var/run/ovpnserver.log 30\n";
> > > -    print CONF "ncp-disable\n";
> > >      print CONF "cipher $sovpnsettings{DCIPHER}\n";
> > > +    # Enable Negotiable Crypto Parameters
> > > +    if ($sovpnsettings{'NCP'} eq 'on') {
> > > +         print CONF "ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-
> > > GCM:AES-128-CBC:BF-CBC\n";
> > > +    } else {
> > > +        print CONF "ncp-disable\n";
> > > +    }
> > 
> > Questions here:
> > 
> > 1) Why do we hard-code the cipher list?
> 
> There is also the possibility to set --ncp-ciphers only whereby OpenVPN
>  uses then AES-256-GCM:AES-128-GCM per default. The linked Fedora
> example uses in first place longer keys 256-GCM:256-CBC before 128-GCM
> whereby i think longer keys (stronger encryption) where prefered to
> 128-GCM (192-GCM is also available and might be also an idea ?) .
> 
> The second point in there is if a client is 2.4 ready but uses older
> OpenSSL libs from the system where no GCM is available, this --ncp-
> ciphers list can nevertheless be used.

I suppose this should include CBC. CBC isn't broken, so there is no
reason to not use it, but as you said, many older clients don't support
GCM yet and therefore won't be able to connect.

Should we have blowfish enabled? That's a good question. Should the
last option rather not be what the user has selected on the web UI?

What happens if someone selected CAMELLIA-256-CBC? Will that still be
used? I assume no. And then the cipher selection doesn't make any sense
any more.

> > 
> > 2) Who would want to disable this as it should always peacefully co-
> > exists with the "cipher" options.
> 
> The --ncp-ciphers option is currently completely disabled and not
> available on IPFire and only --ciphers are used just before Core 120
> and with OpenVPN-2.3.x .
> I think this option is quiet neat if you have a lot´s of clients cause
> an client update to >= 2.4 and clicking the checkbox on server side is
> enough to change the encryption for very old configurations (BF-CBC old
> default) to a strong cipher without the need to generate and distribute
> new configuration files to each client.
> Have often see that old unsecure configs has been used cause the hassle
> to change all of them togehter was simply a lots of stress.
> 
> In my case, i won´t disable it cause as you said, it co-exists
> peacfully beneath the old directives.

What takes precedence? cipher or ncp-ciphers?

> 
> > 
> > >      if ($sovpnsettings{'DAUTH'} eq '') {
> > >          print CONF "";
> > >      } else {
> > > @@ -789,6 +794,7 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save-
> > > adv-options'}) {
> > >      $vpnsettings{'ROUTES_PUSH'} = $cgiparams{'ROUTES_PUSH'};
> > >      $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> > >      $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
> > > +    $vpnsettings{'NCP'} = $cgiparams{'NCP'};
> > >      my @temp=();
> > >      
> > >      if ($cgiparams{'FRAGMENT'} eq '') {
> > > @@ -2685,6 +2691,9 @@ ADV_ERROR:
> > >      $checked{'TLSAUTH'}{'off'} = '';
> > >      $checked{'TLSAUTH'}{'on'} = '';
> > >      $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
> > > +    $checked{'NCP'}{'off'} = '';
> > > +    $checked{'NCP'}{'on'} = '';
> > > +    $checked{'NCP'}{$cgiparams{'NCP'}} = 'CHECKED';
> > >     
> > >      &Header::showhttpheaders();
> > >      &Header::openpage($Lang::tr{'status ovpn'}, 1, '');
> > > @@ -2818,6 +2827,22 @@ print <<END;
> > >      <tr>
> > >  		<td class'base'><b>$Lang::tr{'ovpn crypt
> > > options'}</b></td>
> > >  	</tr>
> > > +
> > > +<table width='100%'>
> > > +    <tr>
> > > +    <td width='20%'></td> <td width='15%'> </td><td width='15%'>
> > > </td><td width='15%'></td><td width='35%'></td>
> > > +    </tr>
> > > +
> > > +    <tr>
> > > +         <td class='base'>$Lang::tr{'ovpn ncp'}</td>
> > > +         <td><input type='checkbox' name='NCP'
> > > $checked{'NCP'}{'on'} /></td>
> > > +    </tr>
> > > +
> > > +    <tr>
> > > +         <td class='base'>HMAC tls-auth</td>
> > > +         <td><input type='checkbox' name='TLSAUTH'
> > > $checked{'TLSAUTH'}{'on'} /></td>
> > > +    </tr>
> > > +
> > >  	<tr>
> > >  		<td width='20%'></td> <td width='30%'> </td><td
> > > width='25%'> </td><td width='25%'></td>
> > >      </tr>	
> > > @@ -2833,17 +2858,8 @@ print <<END;
> > >  		<td>$Lang::tr{'openvpn default'}: <span
> > > class="base">SHA1 (160 $Lang::tr{'bit'})</span></td>
> > >      </tr>
> > >  </table>
> > > +<hr size='1'>
> > >  
> > > -<table width='100%'>
> > > -    <tr>
> > > -	<td width='20%'></td> <td width='15%'> </td><td
> > > width='15%'> </td><td width='15%'></td><td width='35%'></td>
> > > -    </tr>
> > > -
> > > -    <tr>
> > > -	<td class='base'>HMAC tls-auth</td>
> > > -	<td><input type='checkbox' name='TLSAUTH'
> > > $checked{'TLSAUTH'}{'on'} /></td>
> > > -    </tr>
> > > -    </table><hr>
> > >  END
> > >  
> > >  if ( -e "/var/run/openvpn.pid"){
> > > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
> > > index 6e3dba4..9f0de6b 100644
> > > --- a/langs/de/cgi-bin/de.pl
> > > +++ b/langs/de/cgi-bin/de.pl
> > > @@ -1833,6 +1833,7 @@
> > >  'ovpn mtu-disc off' => 'Deaktiviert',
> > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > kann nicht gemeinsam mit mssfix oder fragment verwendet werden.',
> > >  'ovpn mtu-disc yes' => 'Forciert',
> > > +'ovpn ncp' => 'Verschlüsselung aushandeln',
> > >  'ovpn no connections' => 'Keine aktiven OpenVPN Verbindungen',
> > >  'ovpn on blue' => 'OpenVPN auf BLAU:',
> > >  'ovpn on orange' => 'OpenVPN auf ORANGE:',
> > > diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
> > > index 3ec5af5..5cd47b1 100644
> > > --- a/langs/en/cgi-bin/en.pl
> > > +++ b/langs/en/cgi-bin/en.pl
> > > @@ -1866,6 +1866,7 @@
> > >  'ovpn mtu-disc off' => 'Disabled',
> > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > cannot be used with mssfix or fragment.',
> > >  'ovpn mtu-disc yes' => 'Forced',
> > > +'ovpn ncp' => 'Negotiate encryption',
> > 
> > This doesn't fully explain to the user actually is being negotiated.
> > The control channel? The data channel? TLS?
> 
> It is the data channel. The control channel uses since OpenVPN-2.4.x
>  "TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA" and can not be
> configured.

Does that mean that ECDHE-RSA-AES256-GCM-SHA384 is hardcoded and will
always be used even if for example blowfish was selected from the ncp-
ciphers list?

> If this patch might be interesting, i can also change the description.
> If you have an good idea, let it me know.

Not yet, but I thought that "Negotiate encryption" doesn't let the user
know what will actually be used. And I think we have no reason so ever
disable this. I think it should always be enabled, but what the role of
the cipher dropdown is, isn't clear to me.

Best,
-Michael

> 
> 
> Best,
> 
> Erik
  

Hi Michael,

Am Mittwoch, den 08.08.2018, 08:55 +0100 schrieb Michael Tremer:
> Hi,
> 
> On Tue, 2018-08-07 at 18:19 +0200, ummeegge wrote:
> > Hi Michael,
> > 
> > Am Dienstag, den 07.08.2018, 14:10 +0100 schrieb Michael Tremer:
> > > Hello,
> > > 
> > > hmm, I am not sure if I agree with the patch.
> > > 
> > > Could you answer some questions so that I understand better what
> > > the
> > > implications are.
> > 
> > Sure.
> > 
> > > 
> > > On Mon, 2018-08-06 at 09:25 +0200, Erik Kapfer wrote:
> > > > The ncp-ciphers differs to the OpenVPN default value and has
> > > > been
> > > > adapted from Fedora.
> > > > Please see explanations in https://fedoraproject.org/wiki/Chang
> > > > es/N
> > > > ew_default_cipher_in_OpenVPN .
> > > > ---
> > > >  html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++--
> > > > ----
> > > > -----
> > > >  langs/de/cgi-bin/de.pl    |  1 +
> > > >  langs/en/cgi-bin/en.pl    |  1 +
> > > >  3 files changed, 29 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-
> > > > bin/ovpnmain.cgi
> > > > index 976300f..dc22ba5 100644
> > > > --- a/html/cgi-bin/ovpnmain.cgi
> > > > +++ b/html/cgi-bin/ovpnmain.cgi
> > > > @@ -321,8 +321,13 @@ sub writeserverconf {
> > > >      }	
> > > >      print CONF "status-version 1\n";
> > > >      print CONF "status /var/run/ovpnserver.log 30\n";
> > > > -    print CONF "ncp-disable\n";
> > > >      print CONF "cipher $sovpnsettings{DCIPHER}\n";
> > > > +    # Enable Negotiable Crypto Parameters
> > > > +    if ($sovpnsettings{'NCP'} eq 'on') {
> > > > +         print CONF "ncp-ciphers AES-256-GCM:AES-256-CBC:AES-
> > > > 128-
> > > > GCM:AES-128-CBC:BF-CBC\n";
> > > > +    } else {
> > > > +        print CONF "ncp-disable\n";
> > > > +    }
> > > 
> > > Questions here:
> > > 
> > > 1) Why do we hard-code the cipher list?
> > 
> > There is also the possibility to set --ncp-ciphers only whereby
> > OpenVPN
> >  uses then AES-256-GCM:AES-128-GCM per default. The linked Fedora
> > example uses in first place longer keys 256-GCM:256-CBC before 128-
> > GCM
> > whereby i think longer keys (stronger encryption) where prefered to
> > 128-GCM (192-GCM is also available and might be also an idea ?) .
> > 
> > The second point in there is if a client is 2.4 ready but uses
> > older
> > OpenSSL libs from the system where no GCM is available, this --ncp-
> > ciphers list can nevertheless be used.
> 
> I suppose this should include CBC. CBC isn't broken, so there is no
> reason to not use it, but as you said, many older clients don't
> support
> GCM yet and therefore won't be able to connect.
I think this is also the reason why Fedora did used 256-CBC in second
place in their list. If --ncp-ciphers is activated and the client is
2.4 ready but uses old OpenSSL libs the second cipher 256-CBC should
match in mostly cases but uses also the longest possible keysize.

> 
> Should we have blowfish enabled? That's a good question. Should the
> last option rather not be what the user has selected on the web UI?
BF-CBC on that place is also shown as an example configuration on
OpenVPN itself
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
whereby it seems that this is only a temporary solution for very old
clients to migrate also via the help of --ncp-ciphers step by step to
other configurations without to change the whole at once.
I think there might be rare cases that the last cipher in the list will
be used especially if AES-CBC comes before which mostly systems should
have. 
BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes problem)
and is meanwhile deprecated but OpenVPN will also remove it with
OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).

> 
> What happens if someone selected CAMELLIA-256-CBC? Will that still be
> used? I assume no. And then the cipher selection doesn't make any
> sense
> any more.
> 
> > > 
> > > 2) Who would want to disable this as it should always peacefully
> > > co-
> > > exists with the "cipher" options.
> > 
> > The --ncp-ciphers option is currently completely disabled and not
> > available on IPFire and only --ciphers are used just before Core
> > 120
> > and with OpenVPN-2.3.x .
> > I think this option is quiet neat if you have a lot´s of clients
> > cause
> > an client update to >= 2.4 and clicking the checkbox on server side
> > is
> > enough to change the encryption for very old configurations (BF-CBC 
> > old
> > default) to a strong cipher without the need to generate and
> > distribute
> > new configuration files to each client.
> > Have often see that old unsecure configs has been used cause the
> > hassle
> > to change all of them togehter was simply a lots of stress.
> > 
> > In my case, i won´t disable it cause as you said, it co-exists
> > peacfully beneath the old directives.
> 
> What takes precedence? cipher or ncp-ciphers?
ncp-ciphers will be preceded if activated.

> 
> > 
> > > 
> > > >      if ($sovpnsettings{'DAUTH'} eq '') {
> > > >          print CONF "";
> > > >      } else {
> > > > @@ -789,6 +794,7 @@ if ($cgiparams{'ACTION'} eq
> > > > $Lang::tr{'save-
> > > > adv-options'}) {
> > > >      $vpnsettings{'ROUTES_PUSH'} = $cgiparams{'ROUTES_PUSH'};
> > > >      $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> > > >      $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
> > > > +    $vpnsettings{'NCP'} = $cgiparams{'NCP'};
> > > >      my @temp=();
> > > >      
> > > >      if ($cgiparams{'FRAGMENT'} eq '') {
> > > > @@ -2685,6 +2691,9 @@ ADV_ERROR:
> > > >      $checked{'TLSAUTH'}{'off'} = '';
> > > >      $checked{'TLSAUTH'}{'on'} = '';
> > > >      $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
> > > > +    $checked{'NCP'}{'off'} = '';
> > > > +    $checked{'NCP'}{'on'} = '';
> > > > +    $checked{'NCP'}{$cgiparams{'NCP'}} = 'CHECKED';
> > > >     
> > > >      &Header::showhttpheaders();
> > > >      &Header::openpage($Lang::tr{'status ovpn'}, 1, '');
> > > > @@ -2818,6 +2827,22 @@ print <<END;
> > > >      <tr>
> > > >  		<td class'base'><b>$Lang::tr{'ovpn crypt
> > > > options'}</b></td>
> > > >  	</tr>
> > > > +
> > > > +<table width='100%'>
> > > > +    <tr>
> > > > +    <td width='20%'></td> <td width='15%'> </td><td
> > > > width='15%'>
> > > > </td><td width='15%'></td><td width='35%'></td>
> > > > +    </tr>
> > > > +
> > > > +    <tr>
> > > > +         <td class='base'>$Lang::tr{'ovpn ncp'}</td>
> > > > +         <td><input type='checkbox' name='NCP'
> > > > $checked{'NCP'}{'on'} /></td>
> > > > +    </tr>
> > > > +
> > > > +    <tr>
> > > > +         <td class='base'>HMAC tls-auth</td>
> > > > +         <td><input type='checkbox' name='TLSAUTH'
> > > > $checked{'TLSAUTH'}{'on'} /></td>
> > > > +    </tr>
> > > > +
> > > >  	<tr>
> > > >  		<td width='20%'></td> <td width='30%'>
> > > > </td><td
> > > > width='25%'> </td><td width='25%'></td>
> > > >      </tr>	
> > > > @@ -2833,17 +2858,8 @@ print <<END;
> > > >  		<td>$Lang::tr{'openvpn default'}: <span
> > > > class="base">SHA1 (160 $Lang::tr{'bit'})</span></td>
> > > >      </tr>
> > > >  </table>
> > > > +<hr size='1'>
> > > >  
> > > > -<table width='100%'>
> > > > -    <tr>
> > > > -	<td width='20%'></td> <td width='15%'> </td><td
> > > > width='15%'> </td><td width='15%'></td><td width='35%'></td>
> > > > -    </tr>
> > > > -
> > > > -    <tr>
> > > > -	<td class='base'>HMAC tls-auth</td>
> > > > -	<td><input type='checkbox' name='TLSAUTH'
> > > > $checked{'TLSAUTH'}{'on'} /></td>
> > > > -    </tr>
> > > > -    </table><hr>
> > > >  END
> > > >  
> > > >  if ( -e "/var/run/openvpn.pid"){
> > > > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
> > > > index 6e3dba4..9f0de6b 100644
> > > > --- a/langs/de/cgi-bin/de.pl
> > > > +++ b/langs/de/cgi-bin/de.pl
> > > > @@ -1833,6 +1833,7 @@
> > > >  'ovpn mtu-disc off' => 'Deaktiviert',
> > > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > > kann nicht gemeinsam mit mssfix oder fragment verwendet
> > > > werden.',
> > > >  'ovpn mtu-disc yes' => 'Forciert',
> > > > +'ovpn ncp' => 'Verschlüsselung aushandeln',
> > > >  'ovpn no connections' => 'Keine aktiven OpenVPN Verbindungen',
> > > >  'ovpn on blue' => 'OpenVPN auf BLAU:',
> > > >  'ovpn on orange' => 'OpenVPN auf ORANGE:',
> > > > diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
> > > > index 3ec5af5..5cd47b1 100644
> > > > --- a/langs/en/cgi-bin/en.pl
> > > > +++ b/langs/en/cgi-bin/en.pl
> > > > @@ -1866,6 +1866,7 @@
> > > >  'ovpn mtu-disc off' => 'Disabled',
> > > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > > cannot be used with mssfix or fragment.',
> > > >  'ovpn mtu-disc yes' => 'Forced',
> > > > +'ovpn ncp' => 'Negotiate encryption',
> > > 
> > > This doesn't fully explain to the user actually is being
> > > negotiated.
> > > The control channel? The data channel? TLS?
> > 
> > It is the data channel. The control channel uses since OpenVPN-
> > 2.4.x
> >  "TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA" and can not be
> > configured.
> 
> Does that mean that ECDHE-RSA-AES256-GCM-SHA384 is hardcoded and will
> always be used even if for example blowfish was selected from the
> ncp-
> ciphers list?
This are two different configuration directives. "--ciphers" and "--ncp-ciphers"
algorithms are used for the data channel. "--tls-cipher" 
--> https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher
is used for the control channel and can not be configured via IPFires
webinterface.

> 
> > If this patch might be interesting, i can also change the
> > description.
> > If you have an good idea, let it me know.
> 
> Not yet, but I thought that "Negotiate encryption" doesn't let the
> user
> know what will actually be used. And I think we have no reason so
> ever
> disable this. I think it should always be enabled, but what the role
> of
> the cipher dropdown is, isn't clear to me.

With the Core 120 release we did decided to leave the "Negotiate
encryption" for the first completely out to have it easier for
following potential bugs up. So we set "--ncp-disable" and only "
--ciphers" are used as before the 2.4 update, this is true until now.
This patch offers the possibility to enable it (there is the need to
activate it via checkbox in advanced settings) but it do not shows up
which ciphers are used cause theoretically every client can use
different ciphers (pushable option). The server checks which ciphers
the client supports and pushes then the appropriate one but i think it
is one of the first two, new OpenVPN version (2.4) with own OpenSSL or
newer OpenSSL system library are AES-256-GCM older version are AES-256-
CBC, should be the case in 99% .

The cipher dropdown is useful in two cases.
1) The client is below OpenVPN-2.4 and can not handle the "Cipher
negotiation", in that case the algorithm selected via dropdown will be
used just as before. If you have lots of clients < 2.4 but also lots of
clients > 2.4 both directives are used by the server since the cipher
are not fixed anymore (no more 'lowest common multiple') and can
deliver the needed but also the best ciphers for each client.

2) The user wants a specific cipher only for all clients and do not
enables the negotiation option.


Best,

Erik
  

Hi,
just wanted to know if i should drop this one ?

Best,

Erik
  

No, I just didn't have time to write a good response, yet...

Will try to do that as soon as possible.

On Tue, 2018-08-14 at 13:11 +0200, ummeegge wrote:
> Hi,
> just wanted to know if i should drop this one ?
> 
> Best,
> 
> Erik
  

Hey,

On Wed, 2018-08-08 at 12:32 +0200, ummeegge wrote:
> Hi Michael,
> 
> Am Mittwoch, den 08.08.2018, 08:55 +0100 schrieb Michael Tremer:
> > Hi,
> > 
> > On Tue, 2018-08-07 at 18:19 +0200, ummeegge wrote:
> > > Hi Michael,
> > > 
> > > Am Dienstag, den 07.08.2018, 14:10 +0100 schrieb Michael Tremer:
> > > > Hello,
> > > > 
> > > > hmm, I am not sure if I agree with the patch.
> > > > 
> > > > Could you answer some questions so that I understand better what
> > > > the
> > > > implications are.
> > > 
> > > Sure.
> > > 
> > > > 
> > > > On Mon, 2018-08-06 at 09:25 +0200, Erik Kapfer wrote:
> > > > > The ncp-ciphers differs to the OpenVPN default value and has
> > > > > been
> > > > > adapted from Fedora.
> > > > > Please see explanations in https://fedoraproject.org/wiki/Chang
> > > > > es/N
> > > > > ew_default_cipher_in_OpenVPN .
> > > > > ---
> > > > >  html/cgi-bin/ovpnmain.cgi | 38 +++++++++++++++++++++++++++--
> > > > > ----
> > > > > -----
> > > > >  langs/de/cgi-bin/de.pl    |  1 +
> > > > >  langs/en/cgi-bin/en.pl    |  1 +
> > > > >  3 files changed, 29 insertions(+), 11 deletions(-)
> > > > > 
> > > > > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-
> > > > > bin/ovpnmain.cgi
> > > > > index 976300f..dc22ba5 100644
> > > > > --- a/html/cgi-bin/ovpnmain.cgi
> > > > > +++ b/html/cgi-bin/ovpnmain.cgi
> > > > > @@ -321,8 +321,13 @@ sub writeserverconf {
> > > > >      }	
> > > > >      print CONF "status-version 1\n";
> > > > >      print CONF "status /var/run/ovpnserver.log 30\n";
> > > > > -    print CONF "ncp-disable\n";
> > > > >      print CONF "cipher $sovpnsettings{DCIPHER}\n";
> > > > > +    # Enable Negotiable Crypto Parameters
> > > > > +    if ($sovpnsettings{'NCP'} eq 'on') {
> > > > > +         print CONF "ncp-ciphers AES-256-GCM:AES-256-CBC:AES-
> > > > > 128-
> > > > > GCM:AES-128-CBC:BF-CBC\n";
> > > > > +    } else {
> > > > > +        print CONF "ncp-disable\n";
> > > > > +    }
> > > > 
> > > > Questions here:
> > > > 
> > > > 1) Why do we hard-code the cipher list?
> > > 
> > > There is also the possibility to set --ncp-ciphers only whereby
> > > OpenVPN
> > >  uses then AES-256-GCM:AES-128-GCM per default. The linked Fedora
> > > example uses in first place longer keys 256-GCM:256-CBC before 128-
> > > GCM
> > > whereby i think longer keys (stronger encryption) where prefered to
> > > 128-GCM (192-GCM is also available and might be also an idea ?) .
> > > 
> > > The second point in there is if a client is 2.4 ready but uses
> > > older
> > > OpenSSL libs from the system where no GCM is available, this --ncp-
> > > ciphers list can nevertheless be used.
> > 
> > I suppose this should include CBC. CBC isn't broken, so there is no
> > reason to not use it, but as you said, many older clients don't
> > support
> > GCM yet and therefore won't be able to connect.
> 
> I think this is also the reason why Fedora did used 256-CBC in second
> place in their list. If --ncp-ciphers is activated and the client is
> 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC should
> match in mostly cases but uses also the longest possible keysize.

So I had a little thought about all of this and I guess I have figured out what
my problem is with the current approach:

* NCP generally is a good idea. We should *encourage* people to use/activate it
and make sure that they use the strongest cipher possible.+

* Hardcoding is, however, a very bad idea. I would agree that AES-256-GCM/CBC is
good enough for everyone right now. But we don't know what is happening further
down the line.

So my suggestion is to add a menu just like we have in the "advanced" section of
every IPsec connection. A dropdown where you can select multiple ciphers at the
same time. That should be the ncp-ciphers list. And there should be an extra
dropdown for the legacy "cipher" option.

Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher option should be
empty if possible or AES-256-GCM for new setups.

* That would allow loads of flexibility to the users and they would be able to
deselect certain things. So if CBC gets broken (hypothetically), people can
deselect those and they are done. That's better than having an option called
"strong" that is hardcoded to AES-256-* and "fast" that is AES-128-* or so.

I thought we would get around it to implement this, because it probably is a
little bit more to write (especially checking for valid input). But I guess
there is ultimately no easy option.

> > Should we have blowfish enabled? That's a good question. Should the
> > last option rather not be what the user has selected on the web UI?
> 
> BF-CBC on that place is also shown as an example configuration on
> OpenVPN itself
> 
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> whereby it seems that this is only a temporary solution for very old
> clients to migrate also via the help of --ncp-ciphers step by step to
> other configurations without to change the whole at once.
> I think there might be rare cases that the last cipher in the list will
> be used especially if AES-CBC comes before which mostly systems should
> have. 
> BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes problem)
> and is meanwhile deprecated but OpenVPN will also remove it with
> OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).

LOL. Great idea. There are tons of deployments out there that will just break
because of no way for the client to negotiate a cipher.

Not sure when ncp-ciphers was introduced, but I have never seen that anywhere.

> > What happens if someone selected CAMELLIA-256-CBC? Will that still be
> > used? I assume no. And then the cipher selection doesn't make any
> > sense
> > any more.
> > 
> > > > 
> > > > 2) Who would want to disable this as it should always peacefully
> > > > co-
> > > > exists with the "cipher" options.
> > > 
> > > The --ncp-ciphers option is currently completely disabled and not
> > > available on IPFire and only --ciphers are used just before Core
> > > 120
> > > and with OpenVPN-2.3.x .
> > > I think this option is quiet neat if you have a lot´s of clients
> > > cause
> > > an client update to >= 2.4 and clicking the checkbox on server side
> > > is
> > > enough to change the encryption for very old configurations (BF-CBC 
> > > old
> > > default) to a strong cipher without the need to generate and
> > > distribute
> > > new configuration files to each client.
> > > Have often see that old unsecure configs has been used cause the
> > > hassle
> > > to change all of them togehter was simply a lots of stress.
> > > 
> > > In my case, i won´t disable it cause as you said, it co-exists
> > > peacfully beneath the old directives.
> > 
> > What takes precedence? cipher or ncp-ciphers?
> 
> ncp-ciphers will be preceded if activated.

Good.

> 
> > 
> > > 
> > > > 
> > > > >      if ($sovpnsettings{'DAUTH'} eq '') {
> > > > >          print CONF "";
> > > > >      } else {
> > > > > @@ -789,6 +794,7 @@ if ($cgiparams{'ACTION'} eq
> > > > > $Lang::tr{'save-
> > > > > adv-options'}) {
> > > > >      $vpnsettings{'ROUTES_PUSH'} = $cgiparams{'ROUTES_PUSH'};
> > > > >      $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> > > > >      $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
> > > > > +    $vpnsettings{'NCP'} = $cgiparams{'NCP'};
> > > > >      my @temp=();
> > > > >      
> > > > >      if ($cgiparams{'FRAGMENT'} eq '') {
> > > > > @@ -2685,6 +2691,9 @@ ADV_ERROR:
> > > > >      $checked{'TLSAUTH'}{'off'} = '';
> > > > >      $checked{'TLSAUTH'}{'on'} = '';
> > > > >      $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
> > > > > +    $checked{'NCP'}{'off'} = '';
> > > > > +    $checked{'NCP'}{'on'} = '';
> > > > > +    $checked{'NCP'}{$cgiparams{'NCP'}} = 'CHECKED';
> > > > >     
> > > > >      &Header::showhttpheaders();
> > > > >      &Header::openpage($Lang::tr{'status ovpn'}, 1, '');
> > > > > @@ -2818,6 +2827,22 @@ print <<END;
> > > > >      <tr>
> > > > >  		<td class'base'><b>$Lang::tr{'ovpn crypt
> > > > > options'}</b></td>
> > > > >  	</tr>
> > > > > +
> > > > > +<table width='100%'>
> > > > > +    <tr>
> > > > > +    <td width='20%'></td> <td width='15%'> </td><td
> > > > > width='15%'>
> > > > > </td><td width='15%'></td><td width='35%'></td>
> > > > > +    </tr>
> > > > > +
> > > > > +    <tr>
> > > > > +         <td class='base'>$Lang::tr{'ovpn ncp'}</td>
> > > > > +         <td><input type='checkbox' name='NCP'
> > > > > $checked{'NCP'}{'on'} /></td>
> > > > > +    </tr>
> > > > > +
> > > > > +    <tr>
> > > > > +         <td class='base'>HMAC tls-auth</td>
> > > > > +         <td><input type='checkbox' name='TLSAUTH'
> > > > > $checked{'TLSAUTH'}{'on'} /></td>
> > > > > +    </tr>
> > > > > +
> > > > >  	<tr>
> > > > >  		<td width='20%'></td> <td width='30%'>
> > > > > </td><td
> > > > > width='25%'> </td><td width='25%'></td>
> > > > >      </tr>	
> > > > > @@ -2833,17 +2858,8 @@ print <<END;
> > > > >  		<td>$Lang::tr{'openvpn default'}: <span
> > > > > class="base">SHA1 (160 $Lang::tr{'bit'})</span></td>
> > > > >      </tr>
> > > > >  </table>
> > > > > +<hr size='1'>
> > > > >  
> > > > > -<table width='100%'>
> > > > > -    <tr>
> > > > > -	<td width='20%'></td> <td width='15%'> </td><td
> > > > > width='15%'> </td><td width='15%'></td><td width='35%'></td>
> > > > > -    </tr>
> > > > > -
> > > > > -    <tr>
> > > > > -	<td class='base'>HMAC tls-auth</td>
> > > > > -	<td><input type='checkbox' name='TLSAUTH'
> > > > > $checked{'TLSAUTH'}{'on'} /></td>
> > > > > -    </tr>
> > > > > -    </table><hr>
> > > > >  END
> > > > >  
> > > > >  if ( -e "/var/run/openvpn.pid"){
> > > > > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
> > > > > index 6e3dba4..9f0de6b 100644
> > > > > --- a/langs/de/cgi-bin/de.pl
> > > > > +++ b/langs/de/cgi-bin/de.pl
> > > > > @@ -1833,6 +1833,7 @@
> > > > >  'ovpn mtu-disc off' => 'Deaktiviert',
> > > > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > > > kann nicht gemeinsam mit mssfix oder fragment verwendet
> > > > > werden.',
> > > > >  'ovpn mtu-disc yes' => 'Forciert',
> > > > > +'ovpn ncp' => 'Verschlüsselung aushandeln',
> > > > >  'ovpn no connections' => 'Keine aktiven OpenVPN Verbindungen',
> > > > >  'ovpn on blue' => 'OpenVPN auf BLAU:',
> > > > >  'ovpn on orange' => 'OpenVPN auf ORANGE:',
> > > > > diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
> > > > > index 3ec5af5..5cd47b1 100644
> > > > > --- a/langs/en/cgi-bin/en.pl
> > > > > +++ b/langs/en/cgi-bin/en.pl
> > > > > @@ -1866,6 +1866,7 @@
> > > > >  'ovpn mtu-disc off' => 'Disabled',
> > > > >  'ovpn mtu-disc with mssfix or fragment' => 'Path MTU Discovery
> > > > > cannot be used with mssfix or fragment.',
> > > > >  'ovpn mtu-disc yes' => 'Forced',
> > > > > +'ovpn ncp' => 'Negotiate encryption',
> > > > 
> > > > This doesn't fully explain to the user actually is being
> > > > negotiated.
> > > > The control channel? The data channel? TLS?
> > > 
> > > It is the data channel. The control channel uses since OpenVPN-
> > > 2.4.x
> > >  "TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA" and can not be
> > > configured.
> > 
> > Does that mean that ECDHE-RSA-AES256-GCM-SHA384 is hardcoded and will
> > always be used even if for example blowfish was selected from the
> > ncp-
> > ciphers list?
> 
> This are two different configuration directives. "--ciphers" and "--ncp-
> ciphers"
> algorithms are used for the data channel. "--tls-cipher" 
> --> https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher
> is used for the control channel and can not be configured via IPFires
> webinterface.
> 
> > 
> > > If this patch might be interesting, i can also change the
> > > description.
> > > If you have an good idea, let it me know.
> > 
> > Not yet, but I thought that "Negotiate encryption" doesn't let the
> > user
> > know what will actually be used. And I think we have no reason so
> > ever
> > disable this. I think it should always be enabled, but what the role
> > of
> > the cipher dropdown is, isn't clear to me.
> 
> With the Core 120 release we did decided to leave the "Negotiate
> encryption" for the first completely out to have it easier for
> following potential bugs up. So we set "--ncp-disable" and only "
> --ciphers" are used as before the 2.4 update, this is true until now.
> This patch offers the possibility to enable it (there is the need to
> activate it via checkbox in advanced settings) but it do not shows up
> which ciphers are used cause theoretically every client can use
> different ciphers (pushable option). The server checks which ciphers
> the client supports and pushes then the appropriate one but i think it
> is one of the first two, new OpenVPN version (2.4) with own OpenSSL or
> newer OpenSSL system library are AES-256-GCM older version are AES-256-
> CBC, should be the case in 99% .
> 
> The cipher dropdown is useful in two cases.
> 1) The client is below OpenVPN-2.4 and can not handle the "Cipher
> negotiation", in that case the algorithm selected via dropdown will be
> used just as before. If you have lots of clients < 2.4 but also lots of
> clients > 2.4 both directives are used by the server since the cipher
> are not fixed anymore (no more 'lowest common multiple') and can
> deliver the needed but also the best ciphers for each client.
> 
> 2) The user wants a specific cipher only for all clients and do not
> enables the negotiation option.

See above.

> 
> 
> Best,
> 
> Erik
  

Hi Michael,

Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > > 
> > I think this is also the reason why Fedora did used 256-CBC in
> > second
> > place in their list. If --ncp-ciphers is activated and the client
> > is
> > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > should
> > match in mostly cases but uses also the longest possible keysize.
> 
> So I had a little thought about all of this and I guess I have
> figured out what
> my problem is with the current approach:
> 
> * NCP generally is a good idea. We should *encourage* people to
> use/activate it
> and make sure that they use the strongest cipher possible.+
Think so.

> 
> * Hardcoding is, however, a very bad idea. I would agree that AES-
> 256-GCM/CBC is
> good enough for everyone right now. But we don't know what is
> happening further
> down the line.
That´s true but a good point in there is that this configuration is
only presant on server side so the old problem to make changes on
client and server side do not appears anymore which is different to
mostly other directives.

> 
> So my suggestion is to add a menu just like we have in the "advanced"
> section of
> every IPsec connection. A dropdown where you can select multiple
> ciphers at the
> same time. That should be the ncp-ciphers list.
Since OpenVPN have the reputation of an easy to use VPN i´ am not sure
if this is a good idea. People with not that background knowledge 
(e.g. what is the difference between CBC and GCM) might have there a
problem with a good decision. As outlined before, the first Cipher if
it is a Galois/counter mode should be used meanwhile in possibly more
than 50% of the machines out there, the second one, if CBC, is a 99%er
so the whole selection like for IPSec becomes overkill in my opinion
even there is also no possiblity to select integrity, or Grouptypes.

>  And there should be an extra
> dropdown for the legacy "cipher" option.
The old cipher drop down is still presant and is also needed to deliver
a cipher for those clients which do not understand --ncp-cipher (all
clients below 2.4).

> 
> Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher option
> should be
> empty if possible 
Won´t leave it empty othewise all clients below 2.4 won´t work anymore.
The NCP stuff comes with v2.4.

> or AES-256-GCM for new setups.
We can become there also problems if older OpenSSL libs are in usage.
As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
100% sure with this) so we would strip all systems below out (if no
internal OpenSSL are in usage via e.g. a OpenVPN client software). AES-
256-CBC is the current default value for the "legacy" cipher drop down
which should match all the old ones out there too and should also
provide a good state of security.

> 
> * That would allow loads of flexibility to the users and they would
> be able to
> deselect certain things. So if CBC gets broken (hypothetically),
> people can
> deselect those and they are done. That's better than having an option
> called
> "strong" that is hardcoded to AES-256-* and "fast" that is AES-128-*
> or so.
I guess i would do it in that way. If (hypothetically) CBC gets broken,
we can change this settings centrally via updates since the server
pushes this directives and the clients do not see that in their
configuration.
IPFire is and was always fast to fix seriouse problems ;-) and such
problem can be fixed via ovpnmain.cgi for all existing clients which
uses NCP.

> 
> I thought we would get around it to implement this, because it
> probably is a
> little bit more to write (especially checking for valid input). But I
> guess
> there is ultimately no easy option.
I think there is one. Currently i´d have only a checkbox to switch this
one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other side do
supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it for
them.
I think it is nice to have a little menu with 2 or 3 different
selection possibilities (strong, fast, legacy) but like in IPSec
advanced settings would sprinkle the frame in my opinion. Let´s start
with this if we have ECC fully implemented and TLS1.3 arives in OpenVPN
:D .

> 
> > > Should we have blowfish enabled? That's a good question. Should
> > > the
> > > last option rather not be what the user has selected on the web
> > > UI?
> > 
> > BF-CBC on that place is also shown as an example configuration on
> > OpenVPN itself
> > 
> 
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalo
> finsecureciphers:Cipherswithcipherblock-
> sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > whereby it seems that this is only a temporary solution for very
> > old
> > clients to migrate also via the help of --ncp-ciphers step by step
> > to
> > other configurations without to change the whole at once.
> > I think there might be rare cases that the last cipher in the list
> > will
> > be used especially if AES-CBC comes before which mostly systems
> > should
> > have. 
> > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > problem)
> > and is meanwhile deprecated but OpenVPN will also remove it with
> > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
> 
> LOL. Great idea. There are tons of deployments out there that will
> just break
> because of no way for the client to negotiate a cipher.
Yes, rough days ahead :D. Here is the official one --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2 .


> 
> Not sure when ncp-ciphers was introduced, but I have never seen that
> anywhere.
NCP comes with v2.4


Best,


Erik
  

Hi,

On Mon, 2018-08-27 at 18:21 +0200, ummeegge wrote:
> Hi Michael,
> 
> Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > > > 
> > > 
> > > I think this is also the reason why Fedora did used 256-CBC in
> > > second
> > > place in their list. If --ncp-ciphers is activated and the client
> > > is
> > > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > > should
> > > match in mostly cases but uses also the longest possible keysize.
> > 
> > So I had a little thought about all of this and I guess I have
> > figured out what
> > my problem is with the current approach:
> > 
> > * NCP generally is a good idea. We should *encourage* people to
> > use/activate it
> > and make sure that they use the strongest cipher possible.+
> 
> Think so.
> 
> > 
> > * Hardcoding is, however, a very bad idea. I would agree that AES-
> > 256-GCM/CBC is
> > good enough for everyone right now. But we don't know what is
> > happening further
> > down the line.
> 
> That´s true but a good point in there is that this configuration is
> only presant on server side so the old problem to make changes on
> client and server side do not appears anymore which is different to
> mostly other directives.

Now it is, but it wasn't in the past.

> > So my suggestion is to add a menu just like we have in the "advanced"
> > section of
> > every IPsec connection. A dropdown where you can select multiple
> > ciphers at the
> > same time. That should be the ncp-ciphers list.
> 
> Since OpenVPN have the reputation of an easy to use VPN i´ am not sure
> if this is a good idea. People with not that background knowledge 
> (e.g. what is the difference between CBC and GCM) might have there a
> problem with a good decision. As outlined before, the first Cipher if
> it is a Galois/counter mode should be used meanwhile in possibly more
> than 50% of the machines out there, the second one, if CBC, is a 99%er
> so the whole selection like for IPSec becomes overkill in my opinion
> even there is also no possiblity to select integrity, or Grouptypes.

OpenVPN isn't easy. People with too little knowledge should better not touch
anything here.

Therefore we put the cipher selection into the advanced section. If you have no
idea what you are doing, don't touch it and go with the default. If you want to
change things, you have all the freedom that there is.

There is no need for integrity and group types. We have those options somewhere
else and OpenVPN only supports one at a time. This will only be for the cihers.

> >  And there should be an extra
> > dropdown for the legacy "cipher" option.
> 
> The old cipher drop down is still presant and is also needed to deliver
> a cipher for those clients which do not understand --ncp-cipher (all
> clients below 2.4).
> 
> > 
> > Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher option
> > should be
> > empty if possible 
> 
> Won´t leave it empty othewise all clients below 2.4 won´t work anymore.
> The NCP stuff comes with v2.4.

Okay.

> 
> > or AES-256-GCM for new setups.
> 
> We can become there also problems if older OpenSSL libs are in usage.
> As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
> 100% sure with this) so we would strip all systems below out (if no
> internal OpenSSL are in usage via e.g. a OpenVPN client software). AES-
> 256-CBC is the current default value for the "legacy" cipher drop down
> which should match all the old ones out there too and should also
> provide a good state of security.

Okay, AES-256-CBC is fine, too when there is better interoperability.

> 
> > 
> > * That would allow loads of flexibility to the users and they would
> > be able to
> > deselect certain things. So if CBC gets broken (hypothetically),
> > people can
> > deselect those and they are done. That's better than having an option
> > called
> > "strong" that is hardcoded to AES-256-* and "fast" that is AES-128-*
> > or so.
> 
> I guess i would do it in that way. If (hypothetically) CBC gets broken,
> we can change this settings centrally via updates since the server
> pushes this directives and the clients do not see that in their
> configuration.

We cannot touch any configuration ever. We never do that.

Even *if* a cipher is utterly broken, we have to leave it in there to not break
any existing setups.

> IPFire is and was always fast to fix seriouse problems ;-) and such
> problem can be fixed via ovpnmain.cgi for all existing clients which
> uses NCP.
> 
> > 
> > I thought we would get around it to implement this, because it
> > probably is a
> > little bit more to write (especially checking for valid input). But I
> > guess
> > there is ultimately no easy option.
> 
> I think there is one. Currently i´d have only a checkbox to switch this
> one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other side do
> supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it for
> them.

It is not acceptable to hard-code the ciphers here.

> I think it is nice to have a little menu with 2 or 3 different
> selection possibilities (strong, fast, legacy) but like in IPSec
> advanced settings would sprinkle the frame in my opinion. Let´s start
> with this if we have ECC fully implemented and TLS1.3 arives in OpenVPN
> :D .

If you want one dropdown with multiple options, then that leaves you with a lot
of combinations to implement. It also requires extra documentation to make clear
what "fast" is supposed to mean. This is not a good solution.

> 
> > 
> > > > Should we have blowfish enabled? That's a good question. Should
> > > > the
> > > > last option rather not be what the user has selected on the web
> > > > UI?
> > > 
> > > BF-CBC on that place is also shown as an example configuration on
> > > OpenVPN itself
> > > 
> > 
> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalo
> > finsecureciphers:Cipherswithcipherblock-
> > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > > whereby it seems that this is only a temporary solution for very
> > > old
> > > clients to migrate also via the help of --ncp-ciphers step by step
> > > to
> > > other configurations without to change the whole at once.
> > > I think there might be rare cases that the last cipher in the list
> > > will
> > > be used especially if AES-CBC comes before which mostly systems
> > > should
> > > have. 
> > > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > > problem)
> > > and is meanwhile deprecated but OpenVPN will also remove it with
> > > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
> > 
> > LOL. Great idea. There are tons of deployments out there that will
> > just break
> > because of no way for the client to negotiate a cipher.
> 
> Yes, rough days ahead :D. Here is the official one --> 
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
>  .
> 

I cannot believe my eyes what I am reading on that page.


https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratingawayfromdeprecatedciphers

Basically, people are already using something else than what they have selected
with the ciphers option. *Everyone* is using AES-256-GCM now. No matter what is
being selected.

> 
> > 
> > Not sure when ncp-ciphers was introduced, but I have never seen that
> > anywhere.
> 
> NCP comes with v2.4

No I means it being configured somewhere.

> 
> 
> Best,
> 
> 
> Erik
  

Am Dienstag, den 28.08.2018, 11:21 +0100 schrieb Michael Tremer:
> Hi,
> 
> On Mon, 2018-08-27 at 18:21 +0200, ummeegge wrote:
> > Hi Michael,
> > 
> > Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > > > > 
> > > > 
> > > > I think this is also the reason why Fedora did used 256-CBC in
> > > > second
> > > > place in their list. If --ncp-ciphers is activated and the
> > > > client
> > > > is
> > > > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > > > should
> > > > match in mostly cases but uses also the longest possible
> > > > keysize.
> > > 
> > > So I had a little thought about all of this and I guess I have
> > > figured out what
> > > my problem is with the current approach:
> > > 
> > > * NCP generally is a good idea. We should *encourage* people to
> > > use/activate it
> > > and make sure that they use the strongest cipher possible.+
> > 
> > Think so.
> > 
> > > 
> > > * Hardcoding is, however, a very bad idea. I would agree that
> > > AES-
> > > 256-GCM/CBC is
> > > good enough for everyone right now. But we don't know what is
> > > happening further
> > > down the line.
> > 
> > That´s true but a good point in there is that this configuration is
> > only presant on server side so the old problem to make changes on
> > client and server side do not appears anymore which is different to
> > mostly other directives.
> 
> Now it is, but it wasn't in the past.
Yes.

> 
> > > So my suggestion is to add a menu just like we have in the
> > > "advanced"
> > > section of
> > > every IPsec connection. A dropdown where you can select multiple
> > > ciphers at the
> > > same time. That should be the ncp-ciphers list.
> > 
> > Since OpenVPN have the reputation of an easy to use VPN i´ am not
> > sure
> > if this is a good idea. People with not that background knowledge 
> > (e.g. what is the difference between CBC and GCM) might have there
> > a
> > problem with a good decision. As outlined before, the first Cipher
> > if
> > it is a Galois/counter mode should be used meanwhile in possibly
> > more
> > than 50% of the machines out there, the second one, if CBC, is a
> > 99%er
> > so the whole selection like for IPSec becomes overkill in my
> > opinion
> > even there is also no possiblity to select integrity, or
> > Grouptypes.
> 
> OpenVPN isn't easy. People with too little knowledge should better
> not touch
> anything here.
> 
> Therefore we put the cipher selection into the advanced section. If
> you have no
> idea what you are doing, don't touch it and go with the default. If
> you want to
> change things, you have all the freedom that there is.
> 
> There is no need for integrity and group types. We have those options
> somewhere
> else and OpenVPN only supports one at a time. This will only be for
> the cihers.
OK, Will need longer time for this one then.

> 
> > >  And there should be an extra
> > > dropdown for the legacy "cipher" option.
> > 
> > The old cipher drop down is still presant and is also needed to
> > deliver
> > a cipher for those clients which do not understand --ncp-cipher
> > (all
> > clients below 2.4).
> > 
> > > 
> > > Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher
> > > option
> > > should be
> > > empty if possible 
> > 
> > Won´t leave it empty othewise all clients below 2.4 won´t work
> > anymore.
> > The NCP stuff comes with v2.4.
> 
> Okay.
> 
> > 
> > > or AES-256-GCM for new setups.
> > 
> > We can become there also problems if older OpenSSL libs are in
> > usage.
> > As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
> > 100% sure with this) so we would strip all systems below out (if no
> > internal OpenSSL are in usage via e.g. a OpenVPN client software).
> > AES-
> > 256-CBC is the current default value for the "legacy" cipher drop
> > down
> > which should match all the old ones out there too and should also
> > provide a good state of security.
> 
> Okay, AES-256-CBC is fine, too when there is better interoperability.
> 
> > 
> > > 
> > > * That would allow loads of flexibility to the users and they
> > > would
> > > be able to
> > > deselect certain things. So if CBC gets broken (hypothetically),
> > > people can
> > > deselect those and they are done. That's better than having an
> > > option
> > > called
> > > "strong" that is hardcoded to AES-256-* and "fast" that is AES-
> > > 128-*
> > > or so.
> > 
> > I guess i would do it in that way. If (hypothetically) CBC gets
> > broken,
> > we can change this settings centrally via updates since the server
> > pushes this directives and the clients do not see that in their
> > configuration.
> 
> We cannot touch any configuration ever. We never do that.
> 
> Even *if* a cipher is utterly broken, we have to leave it in there to
> not break
> any existing setups.
OK, this makes sense.

> 
> > IPFire is and was always fast to fix seriouse problems ;-) and such
> > problem can be fixed via ovpnmain.cgi for all existing clients
> > which
> > uses NCP.
> > 
> > > 
> > > I thought we would get around it to implement this, because it
> > > probably is a
> > > little bit more to write (especially checking for valid input).
> > > But I
> > > guess
> > > there is ultimately no easy option.
> > 
> > I think there is one. Currently i´d have only a checkbox to switch
> > this
> > one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other
> > side do
> > supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it
> > for
> > them.
> 
> It is not acceptable to hard-code the ciphers here.
> 
> > I think it is nice to have a little menu with 2 or 3 different
> > selection possibilities (strong, fast, legacy) but like in IPSec
> > advanced settings would sprinkle the frame in my opinion. Let´s
> > start
> > with this if we have ECC fully implemented and TLS1.3 arives in
> > OpenVPN
> > :D .
> 
> If you want one dropdown with multiple options, then that leaves you
> with a lot
> of combinations to implement. It also requires extra documentation to
> make clear
> what "fast" is supposed to mean. This is not a good solution.
I see.

> 
> > 
> > > 
> > > > > Should we have blowfish enabled? That's a good question.
> > > > > Should
> > > > > the
> > > > > last option rather not be what the user has selected on the
> > > > > web
> > > > > UI?
> > > > 
> > > > BF-CBC on that place is also shown as an example configuration
> > > > on
> > > > OpenVPN itself
> > > > 
> > > 
> > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remo
> > > valo
> > > finsecureciphers:Cipherswithcipherblock-
> > > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > > > whereby it seems that this is only a temporary solution for
> > > > very
> > > > old
> > > > clients to migrate also via the help of --ncp-ciphers step by
> > > > step
> > > > to
> > > > other configurations without to change the whole at once.
> > > > I think there might be rare cases that the last cipher in the
> > > > list
> > > > will
> > > > be used especially if AES-CBC comes before which mostly systems
> > > > should
> > > > have. 
> > > > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > > > problem)
> > > > and is meanwhile deprecated but OpenVPN will also remove it
> > > > with
> > > > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
> > > 
> > > LOL. Great idea. There are tons of deployments out there that
> > > will
> > > just break
> > > because of no way for the client to negotiate a cipher.
> > 
> > Yes, rough days ahead :D. Here is the official one --> 
> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remova
> > lofinsecureciphers:Cipherswithcipherblock-
> > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> >  .
> > 
> 
> I cannot believe my eyes what I am reading on that page.
Yes, needed also some braingoo for all that and it seems that it is not
finished at all...


> 
> 
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratin
> gawayfromdeprecatedciphers
> 
> Basically, people are already using something else than what they
> have selected
> with the ciphers option. *Everyone* is using AES-256-GCM now. No
> matter what is
> being selected.
> 
> > 
> > > 
> > > Not sure when ncp-ciphers was introduced, but I have never seen
> > > that
> > > anywhere.
> > 
> > NCP comes with v2.4
> 
> No I means it being configured somewhere.Ah OK.
OK.

Best,

Erik
  

On Tue, 2018-08-28 at 21:35 +0200, ummeegge wrote:
> Am Dienstag, den 28.08.2018, 11:21 +0100 schrieb Michael Tremer:
> > Hi,
> > 
> > On Mon, 2018-08-27 at 18:21 +0200, ummeegge wrote:
> > > Hi Michael,
> > > 
> > > Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > > > > > 
> > > > > 
> > > > > I think this is also the reason why Fedora did used 256-CBC in
> > > > > second
> > > > > place in their list. If --ncp-ciphers is activated and the
> > > > > client
> > > > > is
> > > > > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > > > > should
> > > > > match in mostly cases but uses also the longest possible
> > > > > keysize.
> > > > 
> > > > So I had a little thought about all of this and I guess I have
> > > > figured out what
> > > > my problem is with the current approach:
> > > > 
> > > > * NCP generally is a good idea. We should *encourage* people to
> > > > use/activate it
> > > > and make sure that they use the strongest cipher possible.+
> > > 
> > > Think so.
> > > 
> > > > 
> > > > * Hardcoding is, however, a very bad idea. I would agree that
> > > > AES-
> > > > 256-GCM/CBC is
> > > > good enough for everyone right now. But we don't know what is
> > > > happening further
> > > > down the line.
> > > 
> > > That´s true but a good point in there is that this configuration is
> > > only presant on server side so the old problem to make changes on
> > > client and server side do not appears anymore which is different to
> > > mostly other directives.
> > 
> > Now it is, but it wasn't in the past.
> 
> Yes.
> 
> > 
> > > > So my suggestion is to add a menu just like we have in the
> > > > "advanced"
> > > > section of
> > > > every IPsec connection. A dropdown where you can select multiple
> > > > ciphers at the
> > > > same time. That should be the ncp-ciphers list.
> > > 
> > > Since OpenVPN have the reputation of an easy to use VPN i´ am not
> > > sure
> > > if this is a good idea. People with not that background knowledge 
> > > (e.g. what is the difference between CBC and GCM) might have there
> > > a
> > > problem with a good decision. As outlined before, the first Cipher
> > > if
> > > it is a Galois/counter mode should be used meanwhile in possibly
> > > more
> > > than 50% of the machines out there, the second one, if CBC, is a
> > > 99%er
> > > so the whole selection like for IPSec becomes overkill in my
> > > opinion
> > > even there is also no possiblity to select integrity, or
> > > Grouptypes.
> > 
> > OpenVPN isn't easy. People with too little knowledge should better
> > not touch
> > anything here.
> > 
> > Therefore we put the cipher selection into the advanced section. If
> > you have no
> > idea what you are doing, don't touch it and go with the default. If
> > you want to
> > change things, you have all the freedom that there is.
> > 
> > There is no need for integrity and group types. We have those options
> > somewhere
> > else and OpenVPN only supports one at a time. This will only be for
> > the cihers.
> 
> OK, Will need longer time for this one then.
> 
> > 
> > > >  And there should be an extra
> > > > dropdown for the legacy "cipher" option.
> > > 
> > > The old cipher drop down is still presant and is also needed to
> > > deliver
> > > a cipher for those clients which do not understand --ncp-cipher
> > > (all
> > > clients below 2.4).
> > > 
> > > > 
> > > > Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher
> > > > option
> > > > should be
> > > > empty if possible 
> > > 
> > > Won´t leave it empty othewise all clients below 2.4 won´t work
> > > anymore.
> > > The NCP stuff comes with v2.4.
> > 
> > Okay.
> > 
> > > 
> > > > or AES-256-GCM for new setups.
> > > 
> > > We can become there also problems if older OpenSSL libs are in
> > > usage.
> > > As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
> > > 100% sure with this) so we would strip all systems below out (if no
> > > internal OpenSSL are in usage via e.g. a OpenVPN client software).
> > > AES-
> > > 256-CBC is the current default value for the "legacy" cipher drop
> > > down
> > > which should match all the old ones out there too and should also
> > > provide a good state of security.
> > 
> > Okay, AES-256-CBC is fine, too when there is better interoperability.
> > 
> > > 
> > > > 
> > > > * That would allow loads of flexibility to the users and they
> > > > would
> > > > be able to
> > > > deselect certain things. So if CBC gets broken (hypothetically),
> > > > people can
> > > > deselect those and they are done. That's better than having an
> > > > option
> > > > called
> > > > "strong" that is hardcoded to AES-256-* and "fast" that is AES-
> > > > 128-*
> > > > or so.
> > > 
> > > I guess i would do it in that way. If (hypothetically) CBC gets
> > > broken,
> > > we can change this settings centrally via updates since the server
> > > pushes this directives and the clients do not see that in their
> > > configuration.
> > 
> > We cannot touch any configuration ever. We never do that.
> > 
> > Even *if* a cipher is utterly broken, we have to leave it in there to
> > not break
> > any existing setups.
> 
> OK, this makes sense.
> 
> > 
> > > IPFire is and was always fast to fix seriouse problems ;-) and such
> > > problem can be fixed via ovpnmain.cgi for all existing clients
> > > which
> > > uses NCP.
> > > 
> > > > 
> > > > I thought we would get around it to implement this, because it
> > > > probably is a
> > > > little bit more to write (especially checking for valid input).
> > > > But I
> > > > guess
> > > > there is ultimately no easy option.
> > > 
> > > I think there is one. Currently i´d have only a checkbox to switch
> > > this
> > > one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other
> > > side do
> > > supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it
> > > for
> > > them.
> > 
> > It is not acceptable to hard-code the ciphers here.
> > 
> > > I think it is nice to have a little menu with 2 or 3 different
> > > selection possibilities (strong, fast, legacy) but like in IPSec
> > > advanced settings would sprinkle the frame in my opinion. Let´s
> > > start
> > > with this if we have ECC fully implemented and TLS1.3 arives in
> > > OpenVPN
> > > :D .
> > 
> > If you want one dropdown with multiple options, then that leaves you
> > with a lot
> > of combinations to implement. It also requires extra documentation to
> > make clear
> > what "fast" is supposed to mean. This is not a good solution.
> 
> I see.
> 
> > 
> > > 
> > > > 
> > > > > > Should we have blowfish enabled? That's a good question.
> > > > > > Should
> > > > > > the
> > > > > > last option rather not be what the user has selected on the
> > > > > > web
> > > > > > UI?
> > > > > 
> > > > > BF-CBC on that place is also shown as an example configuration
> > > > > on
> > > > > OpenVPN itself
> > > > > 
> > > > 
> > > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remo
> > > > valo
> > > > finsecureciphers:Cipherswithcipherblock-
> > > > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > > > > whereby it seems that this is only a temporary solution for
> > > > > very
> > > > > old
> > > > > clients to migrate also via the help of --ncp-ciphers step by
> > > > > step
> > > > > to
> > > > > other configurations without to change the whole at once.
> > > > > I think there might be rare cases that the last cipher in the
> > > > > list
> > > > > will
> > > > > be used especially if AES-CBC comes before which mostly systems
> > > > > should
> > > > > have. 
> > > > > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > > > > problem)
> > > > > and is meanwhile deprecated but OpenVPN will also remove it
> > > > > with
> > > > > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
> > > > 
> > > > LOL. Great idea. There are tons of deployments out there that
> > > > will
> > > > just break
> > > > because of no way for the client to negotiate a cipher.
> > > 
> > > Yes, rough days ahead :D. Here is the official one --> 
> > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remova
> > > lofinsecureciphers:Cipherswithcipherblock-
> > > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > >  .
> > > 
> > 
> > I cannot believe my eyes what I am reading on that page.
> 
> Yes, needed also some braingoo for all that and it seems that it is not
> finished at all...

Just because this is quite topical today: Alex just told me how long it took him
to replace 20 N2N connections and 80 RW connections. Poor him.

There is a very good reason why we don't have OpenVPN in IPFire 3.

> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratin
> > gawayfromdeprecatedciphers
> > 
> > Basically, people are already using something else than what they
> > have selected
> > with the ciphers option. *Everyone* is using AES-256-GCM now. No
> > matter what is
> > being selected.
> > 
> > > 
> > > > 
> > > > Not sure when ncp-ciphers was introduced, but I have never seen
> > > > that
> > > > anywhere.
> > > 
> > > NCP comes with v2.4
> > 
> > No I means it being configured somewhere.Ah OK.
> 
> OK.
> 
> Best,
> 
> Erik
  

Hi Michael and Alex,

Am Mittwoch, den 29.08.2018, 11:33 +0100 schrieb Michael Tremer:
> > 
> > Yes, needed also some braingoo for all that and it seems that it is
> > not
> > finished at all...
> 
> Just because this is quite topical today: Alex just told me how long
> it took him
> to replace 20 N2N connections and 80 RW connections. Poor him.
> 
> There is a very good reason why we don't have OpenVPN in IPFire 3.
100 connections are a lot. Can we use this knowlegdge for bugreports on
OpenPVN or is this topic (OpenVPN) just obsolet ? 

> > 
> > Best,
> > 
> > Erik
> 
>
  

Hi,

this is indeed on the lower side of some bigger users.

It is quite common to have hundreds of RW connections. >= 200 is not very rare.

Replacing them because of the MD5 change was troubling for them and that is why
I am stressing backwards-compatibility so much with the latest changes. It makes
the difference between OpenVPN being usable or making life a lot worse for the
admins.

Best,
-Michael

On Wed, 2018-08-29 at 23:49 +0200, ummeegge wrote:
> Hi Michael and Alex,
> 
> Am Mittwoch, den 29.08.2018, 11:33 +0100 schrieb Michael Tremer:
> > > 
> > > Yes, needed also some braingoo for all that and it seems that it is
> > > not
> > > finished at all...
> > 
> > Just because this is quite topical today: Alex just told me how long
> > it took him
> > to replace 20 N2N connections and 80 RW connections. Poor him.
> > 
> > There is a very good reason why we don't have OpenVPN in IPFire 3.
> 
> 100 connections are a lot. Can we use this knowlegdge for bugreports on
> OpenPVN or is this topic (OpenVPN) just obsolet ? 
> 
> > > 
> > > Best,
> > > 
> > > Erik
> > 
> >
  

Hi,
it is also a question if the life is not more worst to use broken stuff
which is in the case of MD5 not only a problem of OpenVPN. The
backwards compatibility stands sometimes diametral to security so using
 the good old way includes regular not much work (for administration
but also for implementation) but leads especially for VPNs to an
apparent security.
Beneath the 64bit block cipher desaster where more than 50% of the
ciphers on IPFires OpenVPN are affected will surely comes in a closer
future a question if 2048 bit key lenghts (which we have in the host
certificates) are long enough, where again all needs to be setup again
if this should be changed. ECC crypto, also a nice one, new, fast,
secure, but again all needs to be setup again if it should be used
(there is more..).
From my point of view i wanted to bring new stuff as early as possible
into the forum to inform but also to test it as good as possible and
tried to find ways to make the life of the users easy but sometimes it
is simply not possible to go new ways without work/user_interaction. If
i also try to consider every use case (backwards compatibility,
configuration, setup) i can leave my feed on the ground and don´t need
to make steps forward cause with 100% someone needs to fix something on
it´s setup.

OpenVPN makes currently a lot new which makes it really tough for me to
implement all that without breaking something for someone since the
manpage do not delivers all the truth i need also to make tests whereby
the whole 2.4 update of OpenVPN and implementation into IPFire goes
into weeks of work to be a little safer of what works and what not.

So in summary, if IPFire will drop OpenVPN with 3.x and the life of the
admins are as worst as described in here it is a possiblity to change
the VPNs now to IPSec, i can spare my time with implementing all that
unfunny changes and the current state (which is OK in my opinion) can
be left as it is, i know developing such things for free is a kind of
thankless cause mostly only the bugs a reported back but am currently a
little motivless to make more in here with this background knowledge.

Best,

Erik


Am Donnerstag, den 30.08.2018, 08:35 +0100 schrieb Michael Tremer:
> Hi,
> 
> this is indeed on the lower side of some bigger users.
> 
> It is quite common to have hundreds of RW connections. >= 200 is not
> very rare.
> 
> Replacing them because of the MD5 change was troubling for them and
> that is why
> I am stressing backwards-compatibility so much with the latest
> changes. It makes
> the difference between OpenVPN being usable or making life a lot
> worse for the
> admins.
> 
> Best,
> -Michael
> 
> On Wed, 2018-08-29 at 23:49 +0200, ummeegge wrote:
> > Hi Michael and Alex,
> > 
> > Am Mittwoch, den 29.08.2018, 11:33 +0100 schrieb Michael Tremer:
> > > > 
> > > > Yes, needed also some braingoo for all that and it seems that
> > > > it is
> > > > not
> > > > finished at all...
> > > 
> > > Just because this is quite topical today: Alex just told me how
> > > long
> > > it took him
> > > to replace 20 N2N connections and 80 RW connections. Poor him.
> > > 
> > > There is a very good reason why we don't have OpenVPN in IPFire
> > > 3.
> > 
> > 100 connections are a lot. Can we use this knowlegdge for
> > bugreports on
> > OpenPVN or is this topic (OpenVPN) just obsolet ? 
> > 
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > > 
> > > 
> 
>
  

Hi,

On Thu, 2018-08-30 at 12:31 +0200, ummeegge wrote:
> Hi,
> it is also a question if the life is not more worst to use broken stuff
> which is in the case of MD5 not only a problem of OpenVPN. The
> backwards compatibility stands sometimes diametral to security so using
>  the good old way includes regular not much work (for administration
> but also for implementation) but leads especially for VPNs to an
> apparent security.

Oh, nobody disagrees here. Broken crypto should not be used for obvious reasons.

The problem is only, that there is no migration path and that the OpenVPN
project is setting the time for when migration is being done. That is what is
making this so painful.

> Beneath the 64bit block cipher desaster where more than 50% of the
> ciphers on IPFires OpenVPN are affected will surely comes in a closer
> future a question if 2048 bit key lenghts (which we have in the host
> certificates) are long enough, where again all needs to be setup again
> if this should be changed. ECC crypto, also a nice one, new, fast,
> secure, but again all needs to be setup again if it should be used
> (there is more..).
> From my point of view i wanted to bring new stuff as early as possible
> into the forum to inform but also to test it as good as possible and
> tried to find ways to make the life of the users easy but sometimes it
> is simply not possible to go new ways without work/user_interaction. If
> i also try to consider every use case (backwards compatibility,
> configuration, setup) i can leave my feed on the ground and don´t need
> to make steps forward cause with 100% someone needs to fix something on
> it´s setup.

I think there should always be an option for backwards-compatibility unless it
is a very very very bad idea. For example: we still support MD5 for IPsec. It is
marked as broken, but it is there in case someone has some old equipment to
connect.

> OpenVPN makes currently a lot new which makes it really tough for me to
> implement all that without breaking something for someone since the
> manpage do not delivers all the truth i need also to make tests whereby
> the whole 2.4 update of OpenVPN and implementation into IPFire goes
> into weeks of work to be a little safer of what works and what not.
> 
> So in summary, if IPFire will drop OpenVPN with 3.x and the life of the
> admins are as worst as described in here it is a possiblity to change
> the VPNs now to IPSec, i can spare my time with implementing all that
> unfunny changes and the current state (which is OK in my opinion) can
> be left as it is, i know developing such things for free is a kind of
> thankless cause mostly only the bugs a reported back but am currently a
> little motivless to make more in here with this background knowledge.

You stated above why this is a good idea to implement all those things.

A very long discussion has been had about whether we should continue supporting
OpenVPN and the majority of the arguments were against OpenVPN. On paper, it is
just too broken; in the wrong hands and there were other reasons like "one VPN
implementation is enough for a start", too.

Best,
-Michael

> Best,
> 
> Erik
> 
> 
> Am Donnerstag, den 30.08.2018, 08:35 +0100 schrieb Michael Tremer:
> > Hi,
> > 
> > this is indeed on the lower side of some bigger users.
> > 
> > It is quite common to have hundreds of RW connections. >= 200 is not
> > very rare.
> > 
> > Replacing them because of the MD5 change was troubling for them and
> > that is why
> > I am stressing backwards-compatibility so much with the latest
> > changes. It makes
> > the difference between OpenVPN being usable or making life a lot
> > worse for the
> > admins.
> > 
> > Best,
> > -Michael
> > 
> > On Wed, 2018-08-29 at 23:49 +0200, ummeegge wrote:
> > > Hi Michael and Alex,
> > > 
> > > Am Mittwoch, den 29.08.2018, 11:33 +0100 schrieb Michael Tremer:
> > > > > 
> > > > > Yes, needed also some braingoo for all that and it seems that
> > > > > it is
> > > > > not
> > > > > finished at all...
> > > > 
> > > > Just because this is quite topical today: Alex just told me how
> > > > long
> > > > it took him
> > > > to replace 20 N2N connections and 80 RW connections. Poor him.
> > > > 
> > > > There is a very good reason why we don't have OpenVPN in IPFire
> > > > 3.
> > > 
> > > 100 connections are a lot. Can we use this knowlegdge for
> > > bugreports on
> > > OpenPVN or is this topic (OpenVPN) just obsolet ? 
> > > 
> > > > > 
> > > > > Best,
> > > > > 
> > > > > Erik
> > > > 
> > > > 
> > 
> >
  

Hi Michael,

Am Donnerstag, den 30.08.2018, 12:59 +0100 schrieb Michael Tremer:
> A very long discussion has been had about whether we should continue
> supporting
> OpenVPN and the majority of the arguments were against OpenVPN. On
> paper, it is
> just too broken; in the wrong hands and there were other reasons like
> "one VPN
> implementation is enough for a start", too.
OK haven´t heard about this discussion before but good to know now so i
will stop further development for OpenVPN.

> > Best,
> > 
> > Erik
  

On Thu, 2018-08-30 at 16:02 +0200, ummeegge wrote:
> Hi Michael,
> 
> Am Donnerstag, den 30.08.2018, 12:59 +0100 schrieb Michael Tremer:
> > A very long discussion has been had about whether we should continue
> > supporting
> > OpenVPN and the majority of the arguments were against OpenVPN. On
> > paper, it is
> > just too broken; in the wrong hands and there were other reasons like
> > "one VPN
> > implementation is enough for a start", too.
> 
> OK haven´t heard about this discussion before but good to know now so i
> will stop further development for OpenVPN.

This has been decided at the developer summit in 2015 at the Mozilla office.

  https://wiki.ipfire.org/ids/2015/results

> > > Best,
> > > 
> > > Erik
> 
>
  

-----Original Message-----
From: Michael Tremer <michael.tremer@ipfire.org> 
Sent: 30 August, 2018 10:09
To: ummeegge <ummeegge@ipfire.org>; development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Introduce Negotiable Crypto Parameters for 
roadwarriors

On Thu, 2018-08-30 at 16:02 +0200, ummeegge wrote:
> Hi Michael,
> 
> Am Donnerstag, den 30.08.2018, 12:59 +0100 schrieb Michael Tremer:
> > A very long discussion has been had about whether we should continue 

> > supporting OpenVPN and the majority of the arguments were against 
> > OpenVPN. On paper, it is just too broken; in the wrong hands and 
> > there were other reasons like "one VPN implementation is enough for 
> > a start", too.
> 
> OK haven´t heard about this discussion before but good to know now so 
> i will stop further development for OpenVPN.

This has been decided at the developer summit in 2015 at the Mozilla 
office.

  https://wiki.ipfire.org/ids/2015/results

> > > Best,
> > > 
> > > Erik
> 
> 

If OpenVPN is going to be dropped, then what will replace it? Is IPsec 
going to be the only supported VPN solution?

Best regards,
Fred Kienker
  

On Wed, 2018-09-05 at 11:22 -0400, Kienker, Fred wrote:
> -----Original Message-----
> From: Michael Tremer <michael.tremer@ipfire.org> 
> Sent: 30 August, 2018 10:09
> To: ummeegge <ummeegge@ipfire.org>; development@lists.ipfire.org
> Subject: Re: [PATCH] OpenVPN: Introduce Negotiable Crypto Parameters for 
> roadwarriors
> 
> On Thu, 2018-08-30 at 16:02 +0200, ummeegge wrote:
> > Hi Michael,
> > 
> > Am Donnerstag, den 30.08.2018, 12:59 +0100 schrieb Michael Tremer:
> > > A very long discussion has been had about whether we should continue 
> > > supporting OpenVPN and the majority of the arguments were against 
> > > OpenVPN. On paper, it is just too broken; in the wrong hands and 
> > > there were other reasons like "one VPN implementation is enough for 
> > > a start", too.
> > 
> > OK haven´t heard about this discussion before but good to know now so 
> > i will stop further development for OpenVPN.
> 
> This has been decided at the developer summit in 2015 at the Mozilla 
> office.
> 
>   https://wiki.ipfire.org/ids/2015/results
> 
> > > > Best,
> > > > 
> > > > Erik
> > 
> > 
> 
> If OpenVPN is going to be dropped, then what will replace it? Is IPsec 
> going to be the only supported VPN solution?

For now it is. It works, is well integrated into various OSes and is secure.

> 
> Best regards,
> Fred Kienker
>