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"; + } 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', 'ovpn no connections' => 'No active OpenVPN connections', 'ovpn on blue' => 'OpenVPN on BLUE:', 'ovpn on orange' => 'OpenVPN on ORANGE:',
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:
- 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.
- 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:
- 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.
- 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:
- 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#Removalofinsecu... 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.
- 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
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:
- 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#Removalofinsecu...
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.
- 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.
- 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.
- 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#Removalofinsecu... .
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#Removalofinsecu... .
I cannot believe my eyes what I am reading on that page.
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratingawayfr...
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
-
Erik Kapfer -
Kienker, Fred -
Michael Tremer -
ummeegge