CBC a vulnerable to a bunch of vulnerabilities (MAC-then-encrypt, Padding Oracle, ...) which were considered to be an academic threat.
However, research such as https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle... indicates these issues are more serious. Thereof, this patch marks remaining CBC ciphers (AES-CBC, SEED-CBC and CAMELLIA-CBC) as "weak"; they should be avoided in future.
It does not change the default, which is AES-256-CBC for compatibility reasons. Whether this can be changed or not needs to be discussed.
Signed-off-by: Peter Müller peter.mueller@ipfire.org Cc: Erik Kapfer ummeegge@ipfire.org --- html/cgi-bin/ovpnmain.cgi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 439390228..ae1fe8e77 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -2,7 +2,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2014 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # # # # This program is free software: you can redistribute it and/or modify # # it under the terms of the GNU General Public License as published by # @@ -4516,7 +4516,7 @@ if ($cgiparams{'TYPE'} eq 'net') { $selected{'DCIPHER'}{'CAST5-CBC'} = ''; $selected{'DCIPHER'}{'BF-CBC'} = ''; $selected{'DCIPHER'}{'DES-CBC'} = ''; - # If no cipher has been chossen yet, select + # If no cipher has been chosen yet, select # the old default (AES-256-CBC) for compatiblity reasons. if ($cgiparams{'DCIPHER'} eq '') { $cgiparams{'DCIPHER'} = 'AES-256-CBC'; @@ -4668,13 +4668,13 @@ if ($cgiparams{'TYPE'} eq 'net') { <option value='AES-256-GCM' $selected{'DCIPHER'}{'AES-256-GCM'}>AES-GCM (256 $Lang::tr{'bit'})</option> <option value='AES-192-GCM' $selected{'DCIPHER'}{'AES-192-GCM'}>AES-GCM (192 $Lang::tr{'bit'})</option> <option value='AES-128-GCM' $selected{'DCIPHER'}{'AES-128-GCM'}>AES-GCM (128 $Lang::tr{'bit'})</option> - <option value='CAMELLIA-256-CBC' $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 $Lang::tr{'bit'})</option> - <option value='CAMELLIA-192-CBC' $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 $Lang::tr{'bit'})</option> - <option value='CAMELLIA-128-CBC' $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 $Lang::tr{'bit'})</option> - <option value='AES-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'})</option> - <option value='AES-192-CBC' $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 $Lang::tr{'bit'})</option> - <option value='AES-128-CBC' $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 $Lang::tr{'bit'})</option> - <option value='SEED-CBC' $selected{'DCIPHER'}{'SEED-CBC'}>SEED-CBC (128 $Lang::tr{'bit'})</option> + <option value='CAMELLIA-256-CBC' $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> + <option value='CAMELLIA-192-CBC' $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> + <option value='CAMELLIA-128-CBC' $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> + <option value='AES-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}, $Lang::tr{'vpn weak'})</option> + <option value='AES-192-CBC' $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> + <option value='AES-128-CBC' $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> + <option value='SEED-CBC' $selected{'DCIPHER'}{'SEED-CBC'}>SEED-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DESX-CBC' $selected{'DCIPHER'}{'DESX-CBC'}>DESX-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DES-EDE-CBC' $selected{'DCIPHER'}{'DES-EDE-CBC'}>DES-EDE-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> @@ -5052,7 +5052,7 @@ END } }
-#default setzen +# set default values if ($cgiparams{'DCIPHER'} eq '') { $cgiparams{'DCIPHER'} = 'AES-256-CBC'; }
Hi,
I think I can ACK this although we definitely should change the default. I have raised that a couple of times before.
I also do not like having a very long list of ciphers that are weak. There are not too many left which are “strong”. But yeah, what can you do?
I will wait for Erik to ack this, too.
-Michael
On 10 Jun 2019, at 19:36, Peter Müller peter.mueller@ipfire.org wrote:
CBC a vulnerable to a bunch of vulnerabilities (MAC-then-encrypt, Padding Oracle, ...) which were considered to be an academic threat.
However, research such as https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle... indicates these issues are more serious. Thereof, this patch marks remaining CBC ciphers (AES-CBC, SEED-CBC and CAMELLIA-CBC) as "weak"; they should be avoided in future.
It does not change the default, which is AES-256-CBC for compatibility reasons. Whether this can be changed or not needs to be discussed.
Signed-off-by: Peter Müller peter.mueller@ipfire.org Cc: Erik Kapfer ummeegge@ipfire.org
html/cgi-bin/ovpnmain.cgi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 439390228..ae1fe8e77 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -2,7 +2,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2014 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # # # # This program is free software: you can redistribute it and/or modify # # it under the terms of the GNU General Public License as published by # @@ -4516,7 +4516,7 @@ if ($cgiparams{'TYPE'} eq 'net') { $selected{'DCIPHER'}{'CAST5-CBC'} = ''; $selected{'DCIPHER'}{'BF-CBC'} = ''; $selected{'DCIPHER'}{'DES-CBC'} = '';
- # If no cipher has been chossen yet, select
- # If no cipher has been chosen yet, select # the old default (AES-256-CBC) for compatiblity reasons. if ($cgiparams{'DCIPHER'} eq '') { $cgiparams{'DCIPHER'} = 'AES-256-CBC';
@@ -4668,13 +4668,13 @@ if ($cgiparams{'TYPE'} eq 'net') { <option value='AES-256-GCM' $selected{'DCIPHER'}{'AES-256-GCM'}>AES-GCM (256 $Lang::tr{'bit'})</option> <option value='AES-192-GCM' $selected{'DCIPHER'}{'AES-192-GCM'}>AES-GCM (192 $Lang::tr{'bit'})</option> <option value='AES-128-GCM' $selected{'DCIPHER'}{'AES-128-GCM'}>AES-GCM (128 $Lang::tr{'bit'})</option>
<option value='CAMELLIA-256-CBC' $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 $Lang::tr{'bit'})</option><option value='CAMELLIA-192-CBC' $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 $Lang::tr{'bit'})</option><option value='CAMELLIA-128-CBC' $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 $Lang::tr{'bit'})</option><option value='AES-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'})</option><option value='AES-192-CBC' $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 $Lang::tr{'bit'})</option><option value='AES-128-CBC' $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 $Lang::tr{'bit'})</option><option value='SEED-CBC' $selected{'DCIPHER'}{'SEED-CBC'}>SEED-CBC (128 $Lang::tr{'bit'})</option>
<option value='CAMELLIA-256-CBC' $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option><option value='CAMELLIA-192-CBC' $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option><option value='CAMELLIA-128-CBC' $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option><option value='AES-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}, $Lang::tr{'vpn weak'})</option><option value='AES-192-CBC' $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option><option value='AES-128-CBC' $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option><option value='SEED-CBC' $selected{'DCIPHER'}{'SEED-CBC'}>SEED-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DESX-CBC' $selected{'DCIPHER'}{'DESX-CBC'}>DESX-CBC (192 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option> <option value='DES-EDE-CBC' $selected{'DCIPHER'}{'DES-EDE-CBC'}>DES-EDE-CBC (128 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'})</option>@@ -5052,7 +5052,7 @@ END } }
-#default setzen +# set default values if ($cgiparams{'DCIPHER'} eq '') { $cgiparams{'DCIPHER'} = 'AES-256-CBC'; } -- 2.16.4
Hello Michael,
thanks for your comments.
Hi,
I think I can ACK this although we definitely should change the default. I have raised that a couple of times before.
Yes. This is true for IPsec as well... Patch is in my pipeline...
I also do not like having a very long list of ciphers that are weak. There are not too many left which are “strong”. But yeah, what can you do?
As far as I am concerned, there is little "strong" cryptography left indeed. It's basically only TLS >= 1.2 with AEAD (e.g. GCM) ciphers and Forward Secrecy.
Speaking about RFC 8446, this is more or less what survived discussions before standardizing TLS 1.3 ... :-)
I will wait for Erik to ack this, too.
-Michael
Thanks, and best regards, Peter Müller
Hi,
On 10 Jun 2019, at 20:08, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your comments.
Hi,
I think I can ACK this although we definitely should change the default. I have raised that a couple of times before.
Yes. This is true for IPsec as well... Patch is in my pipeline…
Okay. Can we try to make a patchset out of things like this in the future?
That keeps things together and we can coordinate better when we merge this.
We have closed the last Core Update technically last week. Now we have some big changes here and I would prefer to not break the update but have it rather shipped as soon as possible.
I also do not like having a very long list of ciphers that are weak. There are not too many left which are “strong”. But yeah, what can you do?
As far as I am concerned, there is little "strong" cryptography left indeed. It's basically only TLS >= 1.2 with AEAD (e.g. GCM) ciphers and Forward Secrecy.
Speaking about RFC 8446, this is more or less what survived discussions before standardizing TLS 1.3 ... :-)
Yeah I picked up on that too, but we have to make sure that we ensure compatibility.
OpenVPN is hard to update. People cannot migrate from a cipher to another one and not all versions support GCM.
-Michael
I will wait for Erik to ack this, too.
-Michael
Thanks, and best regards, Peter Müller -- The road to Hades is easy to travel. -- Bion of Borysthenes
Hi,
On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote:
Hi,
On 10 Jun 2019, at 20:08, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your comments.
Hi,
I think I can ACK this although we definitely should change the default. I have raised that a couple of times before.
Yes. This is true for IPsec as well... Patch is in my pipeline…
Okay. Can we try to make a patchset out of things like this in the future?
That keeps things together and we can coordinate better when we merge this.
We have closed the last Core Update technically last week. Now we have some big changes here and I would prefer to not break the update but have it rather shipped as soon as possible.
I also do not like having a very long list of ciphers that are weak. There are not too many left which are “strong”. But yeah, what can you do?
As far as I am concerned, there is little "strong" cryptography left indeed. It's basically only TLS >= 1.2 with AEAD (e.g. GCM) ciphers and Forward Secrecy.
Speaking about RFC 8446, this is more or less what survived discussions before standardizing TLS 1.3 ... :-)
Yeah I picked up on that too, but we have to make sure that we ensure compatibility.
OpenVPN is hard to update. People cannot migrate from a cipher to another one and not all versions support GCM.
A helpful feature for this is --ncp-ciphers where we have had also some discussions some time ago. In principle it is only a checkbox but choosing the ciphers is more work also if we want to have a separate encryption section in the WUI.
Another point which matches this topic i think is the DH-parameter which is, i think, for updated systems (OpenVPN-2.4.x) useless since mostly key exchanges are meanwhile managed via ECDH. We tested this with 'dh none' --> https://forum.ipfire.org/viewtopic.php?f=50&t=22664 . But this is again another encryption setting which is also in my opinion an advanced one in his specifics but a good candidate for a default. We could also spare then the DH-parameter while PKI generation (which needs really lot´s of time and can causes also troubles for weak machines and long paramters). An DH-upload possiblity can still be there for example to keep the possibility for backwards compatibility). Did also some work on this but my time is currently really really rare!
-Michael
I will wait for Erik to ack this, too.
I think we have two kinds of "weak" then. The 64bit block ciphers do have also some technical disadvantage since Sweet32 a renegotiation is forced after 64MB which can be fast reached. So we have a kind of "very weak" and "weak" then?
-Michael
Thanks, and best regards, Peter Müller -- The road to Hades is easy to travel. -- Bion of Borysthenes
Some thoughts from here.
Best,
Erik
Hi,
On 10 Jun 2019, at 20:49, ummeegge ummeegge@ipfire.org wrote:
Hi,
On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote:
Hi,
On 10 Jun 2019, at 20:08, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your comments.
Hi,
I think I can ACK this although we definitely should change the default. I have raised that a couple of times before.
Yes. This is true for IPsec as well... Patch is in my pipeline…
Okay. Can we try to make a patchset out of things like this in the future?
That keeps things together and we can coordinate better when we merge this.
We have closed the last Core Update technically last week. Now we have some big changes here and I would prefer to not break the update but have it rather shipped as soon as possible.
I also do not like having a very long list of ciphers that are weak. There are not too many left which are “strong”. But yeah, what can you do?
As far as I am concerned, there is little "strong" cryptography left indeed. It's basically only TLS >= 1.2 with AEAD (e.g. GCM) ciphers and Forward Secrecy.
Speaking about RFC 8446, this is more or less what survived discussions before standardizing TLS 1.3 ... :-)
Yeah I picked up on that too, but we have to make sure that we ensure compatibility.
OpenVPN is hard to update. People cannot migrate from a cipher to another one and not all versions support GCM.
A helpful feature for this is --ncp-ciphers where we have had also some discussions some time ago. In principle it is only a checkbox but choosing the ciphers is more work also if we want to have a separate encryption section in the WUI.
Do we have any implementation of this somewhere?
Right now this feature is enabled and will default to what ever the OpenVPN project thinks is right, but the option on the web UI does not really matter any more. The cipher selected here is only being used when you have an old client which does not know about ncp-ciphers, yet.
Another point which matches this topic i think is the DH-parameter which is, i think, for updated systems (OpenVPN-2.4.x) useless since mostly key exchanges are meanwhile managed via ECDH. We tested this with 'dh none' --> https://forum.ipfire.org/viewtopic.php?f=50&t=22664
When you say most, how many is that? One is enough to have the DH params.
. But this is again another encryption setting which is also in my opinion an advanced one in his specifics but a good candidate for a default. We could also spare then the DH-parameter while PKI generation (which needs really lot´s of time and can causes also troubles for weak machines and long paramters). An DH-upload possiblity can still be there for example to keep the possibility for backwards compatibility). Did also some work on this but my time is currently really really rare!
Yes, I think we can safely move to EC crypto for modern clients. The question is only how we can keep to support older clients. OpenVPN makes this very very very very difficult.
-Michael
I will wait for Erik to ack this, too.
I think we have two kinds of "weak" then. The 64bit block ciphers do have also some technical disadvantage since Sweet32 a renegotiation is forced after 64MB which can be fast reached. So we have a kind of "very weak" and "weak" then?
In essence you are right. But isn’t weak just another word for broken? And is something either broken or not? I think it does not matter how weak something is really. The message we want to get across to users is to not use these ciphers any more. Having something as “weak” next to “very weak” might make it sound a bit softer and that it might be a little bit acceptable to use the weak cipher.
-Michael
Thanks, and best regards, Peter Müller -- The road to Hades is easy to travel. -- Bion of Borysthenes
Some thoughts from here.
Best,
Erik
-
Michael Tremer -
Peter Müller -
ummeegge