Bug 11186

Created attachment 467 [details]
Germn language patch

Created attachment 468 [details]
English language patch

If IPFire updates OpenVPN to version 2.3.13 this patch should not be needed anymore cause they limiting --reneg-bytes to 64MB per default if small block ciphers are used. --> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 .

Erik

If I may note something here: It seems like the cipher suite names on ovpnmain.cgi in the WebUI are not correct, especially when it comes to 3DES.

Further, I think the length of the DH param should be changed to 2048 bits, but both points are somewhat off-topic here. :-)

Hi Peter,
not sure what you mean with "not correct". Have looked over the 3DES ciphers which looks OK in my opinion -->

server.conf entry   |   WUI menu entry

cipher BF-CBC       =   BF-CBC (128 bit)
cipher CAST5-CBC    =   CAST5-CBC (128 bit)
cipher DES-EDE-CBC  =   DES-EDE-CBC (128 bit)
cipher DESX-CBC     =   DESX-CBC (192 bit)
cipher DES-EDE3-CBC =   DES-EDE3-CB (192 bit)

The server starts also with all listed ciphers.

Regarding the DH-parameter

it might be an idea to add a default to 2048 but as you mentioned this should be addressed to another topic.

Greetings,

UE

(In reply to Erik Kapfer from comment #5)
> Hi Peter,
> not sure what you mean with "not correct". Have looked over the 3DES ciphers
> which looks OK in my opinion -->
> 
> server.conf entry   |   WUI menu entry
> 
> cipher BF-CBC       =   BF-CBC (128 bit)
> cipher CAST5-CBC    =   CAST5-CBC (128 bit)
> cipher DES-EDE-CBC  =   DES-EDE-CBC (128 bit)
> cipher DESX-CBC     =   DESX-CBC (192 bit)
> cipher DES-EDE3-CBC =   DES-EDE3-CB (192 bit)
> 
> The server starts also with all listed ciphers.
All right, I thought something was messed up here.
> 
> Regarding the DH-parameter

(In reply to Erik Kapfer from comment #6)
> it might be an idea to add a default to 2048 but as you mentioned this
> should be addressed to another topic.
Yes, since we mark 1024 bits as "weak", we should suggest somethig secure (such as 2048 bits) by default. Would you like to have a look at it? I am not very familiar with the OpenVPN CGI script...
> 
> Greetings,
> 
> UE
Thanks and best regards,
Peter Müller

(In reply to Peter Müller from comment #7)
> (In reply to Erik Kapfer from comment #5)
> > cipher BF-CBC       =   BF-CBC (128 bit)
> > cipher CAST5-CBC    =   CAST5-CBC (128 bit)
> > cipher DES-EDE-CBC  =   DES-EDE-CBC (128 bit)
> > cipher DESX-CBC     =   DESX-CBC (192 bit)
> > cipher DES-EDE3-CBC =   DES-EDE3-CB (192 bit)

They indeed use some funny names here.

DES is just DES, but with 3DES you encrypt with one key, then decrypt with another key and then encrypt again with a third key. Therefore the EDE abbreviations after DES. However the keys are derived from the key that is being put in because the key length in DES is only 64 bit with an effective length of 56 bit.

> > The server starts also with all listed ciphers.
> All right, I thought something was messed up here.
> > 
> > Regarding the DH-parameter
> 
> (In reply to Erik Kapfer from comment #6)
> > it might be an idea to add a default to 2048 but as you mentioned this
> > should be addressed to another topic.
> Yes, since we mark 1024 bits as "weak", we should suggest somethig secure
> (such as 2048 bits) by default. Would you like to have a look at it? I am
> not very familiar with the OpenVPN CGI script...

I do not think that we can mark something as "secure" because we never know when it will break. And it depends on more things than just the cipher to make something secure.

But we can say that something is weak when the cipher is weak because on element in a chain of things is enough to weaken the entire chain.

Is any action required on this ticket or can we just close?

(In reply to Michael Tremer from comment #8)
> (In reply to Peter Müller from comment #7)
> > (In reply to Erik Kapfer from comment #5)
> > > [...]
> > (In reply to Erik Kapfer from comment #6)
> > > it might be an idea to add a default to 2048 but as you mentioned this
> > > should be addressed to another topic.
> > Yes, since we mark 1024 bits as "weak", we should suggest somethig secure
> > (such as 2048 bits) by default. Would you like to have a look at it? I am
> > not very familiar with the OpenVPN CGI script...
> 
> I do not think that we can mark something as "secure" because we never know
> when it will break. And it depends on more things than just the cipher to
> make something secure.
Certainly. My idea was to set the DH param lenght to 2048 bits by default since we marked 1024 bits as "insecure" and thereof should not propagate it as default setting.

I would not mark 2048 bits as "secure" either.
> 
> But we can say that something is weak when the cipher is weak because on
> element in a chain of things is enough to weaken the entire chain.
> 
> Is any action required on this ticket or can we just close?
As far as I am concerned, we should change
- the default DH param lenght to 2048 bits (see above)
- mark BF (Blowfish) as "broken" since it is vulnerable to Sweet32 and known plaintext attacks
- mark DES as "broken" since it is
- mark 3DES as "weak" as we did with IPsec
- mark DES-X as "weak" since it's actual strenght is ~119 bits and it heavily relies on DES.

Apart from that, I assume we can close this ticket.

(In reply to Peter Müller from comment #9)
 it depends on more things than just the cipher to
> > make something secure.
> Certainly. My idea was to set the DH param lenght to 2048 bits by default
> since we marked 1024 bits as "insecure" and thereof should not propagate it
> as default setting.
> 
> I would not mark 2048 bits as "secure" either.

I know that this does not sound very intuitive because it looks like 2048 is "double" the strength of 1024 which it of course isn't.

I guess this is a good default because all systems can handle this. Generating keys of 4096 bit length takes sometimes hours on some systems.

> > But we can say that something is weak when the cipher is weak because on
> > element in a chain of things is enough to weaken the entire chain.
> > 
> > Is any action required on this ticket or can we just close?
> As far as I am concerned, we should change
> - the default DH param lenght to 2048 bits (see above)
> - mark BF (Blowfish) as "broken" since it is vulnerable to Sweet32 and known
> plaintext attacks
> - mark DES as "broken" since it is
> - mark 3DES as "weak" as we did with IPsec
> - mark DES-X as "weak" since it's actual strenght is ~119 bits and it
> heavily relies on DES.
> 
> Apart from that, I assume we can close this ticket.

Who is doing these changes?

Hi,
have already a new patch for the ciphers (which also includes CAST5 also an 64 bit block cipher) with the mark 'weak' in the menu as Peter did it already for SHA1 and 1024 DH in here --> https://patchwork.ipfire.org/patch/1585/ . As we discussed it already --> https://lists.ipfire.org/pipermail/development/2018-January/003904.html i wanted to push this as a second patch (first one is meanwhile out).

Regarding the DH parameter. Should we may delete it completely from the menu ? In that case we should do the same with SHA1 in my opinion since both are kind of deprecated and 'weak/unsure' . If we delete the whole DH-parameter selection menus from ovpnmain.cgi and set the DH key length fixed to 2048 bit it is nevertheless the possibility to upload other DH parameters via WUI. Currently possible 1024 (can be changed/deleted), 2048 (won´t be needed anymore in the above scenario), 3072 and 4096 bit.

If we do work in this section i would also strongly suggest to also thinking about the X509 key size. An Enisa report from 2013 pointed out that for "future system near term use" or at least ten years, RSA keys of 3072 bits or more are recommended --> https://community.openvpn.net/openvpn/wiki/Hardening#X.509keysize . IPFires uses currently 2048 bit for the host and 4096 bit for the root certificate.

So an idea in that manner might be the usage of
- Fixed key length of 2048 bit for DH-parameter and deletion of the selection menus in the WUI (except the DH-parameter upload possibility).
- Fixed key length of 4096 bit for host and 4096 bit for root certificate.

The generation time for weak boards (like e.g. ALIX and similar hardware) might be considerably high i think but until there is no ECC for OpenVPN on IPFire available, we are forced to use higher key sizes to have a better stand in time.

Some thoughts from here.

If you would like to close this bug here no problem from my side, have opened it up especially to keep up the attention on this (Sweet32 problem at that time) which we did i think.

Greetings,

Erik

Have adapted Peter´s style of the HMAC description and have added them to the ciphers/DH-parameter for the OpenVPN-2.4.4 update which can be found in here --> https://patchwork.ipfire.org/patch/1636/ .

This do not touch the above mentioned DH-parameter or the key size of the host/root certificate issue. Might be an idea to address this separate ?

If this patch will be accepted, i think this bug/reminder can be closed anyways.

Greetings,

Erik

Looks like all has been merged.

Yes Core 120 do have it all.