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