public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Introduce Negotiable Crypto Parameters for roadwarriors
Date: Wed, 08 Aug 2018 08:55:16 +0100	[thread overview]
Message-ID: <9f1e972f661096d1ec64f970c42c537766f180ab.camel@ipfire.org> (raw)
In-Reply-To: <1d60a4c661c9e0b026762c92e9776d641a5e7e2c.camel@ipfire.org>

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

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


  reply	other threads:[~2018-08-08  7:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06  7:25 Erik Kapfer
2018-08-07 13:10 ` Michael Tremer
2018-08-07 16:19   ` ummeegge
2018-08-08  7:55     ` Michael Tremer [this message]
2018-08-08 10:32       ` ummeegge
2018-08-14 11:11         ` ummeegge
2018-08-14 11:21           ` Michael Tremer
2018-08-27  7:20         ` Michael Tremer
2018-08-27 16:21           ` ummeegge
2018-08-28 10:21             ` Michael Tremer
2018-08-28 19:35               ` ummeegge
2018-08-29 10:33                 ` Michael Tremer
2018-08-29 21:49                   ` ummeegge
2018-08-30  7:35                     ` Michael Tremer
2018-08-30 10:31                       ` ummeegge
2018-08-30 11:59                         ` Michael Tremer
2018-08-30 14:02                           ` ummeegge
2018-08-30 14:08                             ` Michael Tremer
2018-09-05 15:22                               ` Kienker, Fred
2018-09-09 12:46                                 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f1e972f661096d1ec64f970c42c537766f180ab.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox