Hi,

I am probably with Erik on this.

I agree that 1024 bits are not enough any more. It is better to use longer keys and DH params if possible. However we have the same argument here that we had on the Apache thread. It is pretty much not feasible to generate these keys on many systems.

I am also not sure if labeling key sizes of 1024 bit as "insecure" is the best idea. I would prefer something like "recommended" for all higher key sizes. This is however in conflict with the argument above.

Best, -Michael

On Tue, 2015-11-24 at 15:14 +0100, ue wrote:

Hi Timmothy Wilson, we left the 1024 bit choice at this time in cause it provides a shortened time for the whole X509 generation. On slow boards or systems with less entropy the DH generation can take also with 2048 bit DH-parameter a long time (measured at this time up to 10 minutes with 2048 bits) . We´ve made at development time a short list which you can find here --> http://wiki.ipfire.org/en/configuration/servic es/openvpn/extensions/zertkonvert where you can find also the needed time for DH-parameter generation. May 10 Minutes for an e.g. ALIX board is a lot and may too much ? Nevertheless you can upload external generated DH-parameter over the WUI --> http://wiki.ipfire.o rg/en/configuration/services/openvpn/config/upload_gen so a prepackaged DH-parameter can also be uploaded but the generation time can be left short too.

Another thing is, could you may provide more informations about the insecurity of 2048 bit DH-parameters ? On OpenVPN hardening side they called it "Use of 2048-bit is a good minimum." --> https://community.openvpn.net/openvpn/wiki/Hardening . Shurley a longer parameter increases security but needs also lots of more time to generate and with the usage of the upload function may a better way by only hint the 1024 parameter as insecure so both is possible ?

May an "insecure" hint in the flip menu is enough ? A possible "insecure" hint could also be placed for the "Hash algorithm" in "Cryptographic options" for SHA1 --> https://www.schneier.com/blog/archives/2005/02/sha1_broken.html <-- from 2005 :-( .

Some suggestions from here.

Greetings,

Erik

Am 23.11.2015 um 15:18 schrieb IT Superhack:

...

The OpenVPN CGI offers to create a DH param. The patch below disables the generation of 1024 bit params and marks 2048 bit params as weak/insecure.

It is recommended to use DH params with at least 3072 bits, shorter ones are considered as insecure. The patch does not affect systems where already DH params were created.

Sorry for the crappy line breaks by my mail agent, but it cannot switch this off and git send-email does not work on my system (starttls issues).

Signed-off-by: Timmothy Wilson itsuperhack@web.de

html/cgi-bin/ovpnmain.cgi | 3 +-- langs/de/cgi-bin/de.pl | 1 + 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 62af54e..4813128 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1313,8 +1313,7 @@ END <form method='post'><input type='hidden' name='AREUSURE' value='yes' /> <input type='hidden' name='KEY' value='$cgiparams{'KEY'}' /> <select name='DHLENGHT'>

• 		<option value='1024'
  

$selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option>

• 		<option value='2048'
  

$selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option>

• 		<option value='2048'
  

$selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'} ($Lang::tr{'insecure'})</option> <option value='3072' $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option> <option value='4096' $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option> </select> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..bfed92b 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1291,6 +1291,7 @@ 'incorrect password' => 'Fehlerhaftes Passwort', 'info' => 'Info', 'init string' => 'Initialisierung:', +'insecure' => 'unsicher', 'insert floppy' => 'Legen Sie eine formatierte Diskette in das Floppy-Laufwerk in IPFire und klicken auf <i>Datensicherung auf Diskette</i>, um die Systemeinstellungen zu sichern. Überprüfen Sie das Ergebnis sorgfältig, um sicher zu sein, dass die Datensicherung vollständig und erfolgreich abgeschlossen wurde.', 'install' => 'Installieren', 'install new update' => 'Installiere neues Update:',

Hello,

I agree that we should indeed do something here.

But frankly the usual case would be that people will stick with the algorithms they picked at the start and that is it. This is nothing that I would like to defend, but we have many people with hundreds or even thousands of OpenVPN connections and replacing them is not feasible for them. I should be done though, but they won't do it.

Hence I think that a big warning message on the front page is not the right thing to do. A warning on the OpenVPN page would be something that I would find better.

On Wed, 2015-12-02 at 10:07 +0100, IT Superhack wrote:

Hello Michael,

Michael Tremer:

...

Hi,

I am probably with Erik on this.

I agree that 1024 bits are not enough any more. It is better to use longer keys and DH params if possible. However we have the same argument here that we had on the Apache thread. It is pretty much not feasible to generate these keys on many systems.

Speaking about the DH params, I agree with that, since the generation of those takes ages on older systems and they can be easily generated on a fast workstation and updated later. Maybe it would be an idea to display a notification on the WebIF page (similar to the "fireinfo is disabled" one), which spells like "The DH parameter is not strong enough. Please update a stronger one to the OpenVPN page, if possible", what do you think?

...

I am also not sure if labeling key sizes of 1024 bit as "insecure" is the best idea. I would prefer something like "recommended" for all higher key sizes. This is however in conflict with the argument above.

In my opinion, this is kind of a general discussion. Having in mind the patch Larsen submitted a while ago, which marked required fields with a star and not the not-required ones, the question here is the same: Should we mark the secure or the insecure options?

This was a bit different since the entire web did it the way that we didn't do it before. This is just consistent with the rest and just a change in user-experience.

Of course, both is possible, but I think it would be better to settle that for the WebIF in general to avoid inconsistent "insecure" or "recommended" tags.

Of course this should be consistent.

Another point is the use of SHA1 and (3)DES, as well as other algorithms. In my opinion, the following ciphers/algorithms are insecure:

OpenVPN page: DES-EDE3-CBC DESX-CBC DES-EDE-CBC

I have never seen any evidence that 3DES is broken. It may not be as secure as AES, but it is not generally considered weak - as far as I know.

DH Params with sizes 1024 and 2048 bits.

OpenVPN page - advanced options: SHA1

IPSec page - advanced connection options: SHA1

SHA1 is getting weaker and weaker, that is true. However it is the best thing that many systems can do.

In IPsec we do not allow MODP-768 or even lower to be selected. Many other appliances (especially Lancom routers are really really really really bad when it comes to encryption) require MODP-512, MD5 and DES.

And this is not just old hardware that people use. Cisco seems to default to 3DES and MD5 for their IPsec VPNs as well (at least that is what you get when you set up an IPsec connection with someone who is using their stuff).

So my point is: These appliances are out there. And allowing our users to set up a VPN connection with that is still better than nothing. It is very common that weak cryptography is used. Therefore I would like to point out that we should at best have a recommendation and show subtle warnings instead of big red error messages or preventing the users from choosing bad cryptography at all.

I don't really like what I am writing here, but if IPFire should play its role in the industry, this must be possible.

Concerning OpenVPN, some of those algorithms are necessary because of older devices (Cisco ASA appliances, for example), so it would not make sense to drop them at all, as well as the 1024-DH-param.

What would you think of a patch which marks those alltogether as "insecure" (or recommends only stronger ones such as AES, CAMELLIA and SHA2)? Maybe this would be an improvement.

If you want to mark the "bad" cryptography, how about the term "weak" instead of "insecure". These are two very different things for me.

And what do we do with all the old certificates? If you have migrated an IPFire installation from IPFire 2.1 to now, you will use MD5 for your certificates and you will have key lengths of 1024. If we get warnings, I think we should have these too and make a guide on the wiki how to regenerate the certificates.

Is anybody up for doing this?

Best, -Michael

Best regards, Timmothy Wilson

...

Best, -Michael

On Tue, 2015-11-24 at 15:14 +0100, ue wrote:

...

Hi Timmothy Wilson, we left the 1024 bit choice at this time in cause it provides a shortened time for the whole X509 generation. On slow boards or systems with less entropy the DH generation can take also with 2048 bit DH-parameter a long time (measured at this time up to 10 minutes with 2048 bits) . We´ve made at development time a short list which you can find here --> http://wiki.ipfire.org/en/configuration/servic es/openvpn/extensions/zertkonvert where you can find also the needed time for DH-parameter generation. May 10 Minutes for an e.g. ALIX board is a lot and may too much ? Nevertheless you can upload external generated DH-parameter over the WUI --> http://wiki.ipfire.o rg/en/configuration/services/openvpn/config/upload_gen so a prepackaged DH-parameter can also be uploaded but the generation time can be left short too.

Another thing is, could you may provide more informations about the insecurity of 2048 bit DH-parameters ? On OpenVPN hardening side they called it "Use of 2048-bit is a good minimum." --> https://community.openvpn.net/openvpn/wiki/Hardening . Shurley a longer parameter increases security but needs also lots of more time to generate and with the usage of the upload function may a better way by only hint the 1024 parameter as insecure so both is possible ?

May an "insecure" hint in the flip menu is enough ? A possible "insecure" hint could also be placed for the "Hash algorithm" in "Cryptographic options" for SHA1 --> https://www.schneier.com/blog/archives/2005/02/sha1_broken.html < -- from 2005 :-( .

Some suggestions from here.

Greetings,

Erik

Am 23.11.2015 um 15:18 schrieb IT Superhack:

...

The OpenVPN CGI offers to create a DH param. The patch below disables the generation of 1024 bit params and marks 2048 bit params as weak/insecure.

It is recommended to use DH params with at least 3072 bits, shorter ones are considered as insecure. The patch does not affect systems where already DH params were created.

Sorry for the crappy line breaks by my mail agent, but it cannot switch this off and git send-email does not work on my system (starttls issues).

Signed-off-by: Timmothy Wilson itsuperhack@web.de

html/cgi-bin/ovpnmain.cgi | 3 +-- langs/de/cgi-bin/de.pl | 1 + 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi -bin/ovpnmain.cgi index 62af54e..4813128 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1313,8 +1313,7 @@ END <form method='post'><input type='hidden' name='AREUSURE' value='yes' /> <input type='hidden' name='KEY' value='$cgiparams{'KEY'}' /> <select name='DHLENGHT'>

• 		<option value='1024'
  

$selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option>

• 		<option value='2048'
  

$selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option>

• 		<option value='2048'
  

$selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'} ($Lang::tr{'insecure'})</option> <option value='3072' $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option> <option value='4096' $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option> </select> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..bfed92b 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1291,6 +1291,7 @@ 'incorrect password' => 'Fehlerhaftes Passwort', 'info' => 'Info', 'init string' => 'Initialisierung:', +'insecure' => 'unsicher', 'insert floppy' => 'Legen Sie eine formatierte Diskette in das Floppy-Laufwerk in IPFire und klicken auf <i>Datensicherung auf Diskette</i>, um die Systemeinstellungen zu sichern. Überprüfen Sie das Ergebnis sorgfältig, um sicher zu sein, dass die Datensicherung vollständig und erfolgreich abgeschlossen wurde.', 'install' => 'Installieren', 'install new update' => 'Installiere neues Update:',

Signed-off-by: Timmothy Wilson itsuperhack@web.de --- diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 62af54e..15385f1 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1316,7 +1316,7 @@ END <option value='1024' $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option> <option value='2048' $selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option> <option value='3072' $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option> - <option value='4096' $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option> + <option value='4096' $selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> </select> </td> </tr> @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <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-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}, $Lang::tr{'recommended'})</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='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'})</option> @@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> <td><select name='DAUTH'> <option value='whirlpool' $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 $Lang::tr{'bit'})</option> - <option value='SHA512' $selected{'DAUTH'}{'SHA512'}>SHA2 (512 $Lang::tr{'bit'})</option> + <option value='SHA512' $selected{'DAUTH'}{'SHA512'}>SHA2 (512 $Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> <option value='SHA384' $selected{'DAUTH'}{'SHA384'}>SHA2 (384 $Lang::tr{'bit'})</option> <option value='SHA256' $selected{'DAUTH'}{'SHA256'}>SHA2 (256 $Lang::tr{'bit'})</option> <option value='SHA1' $selected{'DAUTH'}{'SHA1'}>SHA1 (160 $Lang::tr{'bit'} Default)</option> diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi index f1cffb8..9aa50f5 100644 --- a/html/cgi-bin/vpnmain.cgi +++ b/html/cgi-bin/vpnmain.cgi @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td>$Lang::tr{'vpn keyexchange'}:</td> <td> <select name='IKE_VERSION'> - <option value='ikev2' $selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option> + <option value='ikev2' $selected{'IKE_VERSION'}{'ikev2'}>IKEv2 ($Lang::tr{'recommended'})</option> <option value='ikev1' $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> </select> </td> @@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'encryption'}</td> <td class='boldbase'> <select name='IKE_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'> - <option value='aes256gcm128' $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option> + <option value='aes256gcm128' $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'IKE_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option> @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'> - <option value='aes256gcm128' $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option> + <option value='aes256gcm128' $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'ESP_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option> @@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'integrity'}</td> <td class='boldbase'> <select name='IKE_INTEGRITY' multiple='multiple' size='6' style='width: 100%'> - <option value='sha2_512' $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> + <option value='sha2_512' $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES XCBC</option> @@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_INTEGRITY' multiple='multiple' size='6' style='width: 100%'> - <option value='sha2_512' $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> + <option value='sha2_512' $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES XCBC</option> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..b18cace 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1914,6 +1914,7 @@ 'rebooting ipfire' => 'Starte IPFire neu', 'reconnect' => 'Neu Verbinden', 'reconnection' => 'Wiederverbindung', +'recommended' => 'empfohlen', 'red' => 'Internet', 'red1' => 'ROT', 'references' => 'Referenzen',

Hello Michael,

Michael Tremer:

Hello,

this patch was line-wrapped and cannot be merged, but nevertheless, here are my thoughts:

I am unable to submit patches at the moment, since git send-email keeps crashing on every machine I own - sometimes starttls issues, sometimes segfault - and TB seems to line-wrap.

On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote:

...

Signed-off-by: Timmothy Wilson itsuperhack@web.de

diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 62af54e..15385f1 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1316,7 +1316,7 @@ END <option value='1024' $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option> <option value='2048' $selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option> <option value='3072' $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option>

• 		<option value='4096'
  

$selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option>

• 		<option value='4096'
  

$selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> </select> </td>

</tr>

I agree, that it is desirable to use longer keys. However, I am not sure if it is a good idea to go all the way for 4096 bit and not only for e.g. 2048 bit. Why not 8192 even?

Since the SSLTest server page treats 2048 DH primes as "weak", I guess 3072 or better is suitable here.

I would like to read some justification for the values that are picked.

Here is one, for example: https://netzpolitik.org/2015/kryptographie-open-source-und-gesellschaft/ (german, please see "8."). In this article is also mentioned that 512 bit hash algorithms should be used.

Furthermore, I think that we the upper bound should be something that the average IPFire box is able to handle.

I agree with that. Maybe 3072 bits is a good deal between speed and security, what do you think?

...

@@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <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-256-CBC' 	
  

$selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}, $Lang::tr{'recommended'})</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='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'})</option>

I can agree with that since it is already selected by default. This makes it just more explicit.

I would have merged this if this was an independent patch in a patch set.

Thanks, but at the moment, i cannot hand in a patch without wrapped lines.

...

@@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> <td><select name='DAUTH'> <option value='whirlpool' $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 $Lang::tr{'bit'})</option>

• 		<option value='SHA512'		
  

  $selected{'DAUTH'}{'SHA512'}>SHA2 (512

$Lang::tr{'bit'})</option>

• 		<option value='SHA512'		
  

  $selected{'DAUTH'}{'SHA512'}>SHA2 (512

$Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> <option value='SHA384' $selected{'DAUTH'}{'SHA384'}>SHA2 (384 $Lang::tr{'bit'})</option> <option value='SHA256' $selected{'DAUTH'}{'SHA256'}>SHA2 (256 $Lang::tr{'bit'})</option> <option value='SHA1' $selected{'DAUTH'}{'SHA1'}>SHA1 (160 $Lang::tr{'bit'} Default)</option>

Same as above. SHA2 is considered to be "secure enough for now". Why is 256 bit not enough? This has also a rather huge performance impact. Things like these should also be mentioned in the commit message.

...

diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi index f1cffb8..9aa50f5 100644 --- a/html/cgi-bin/vpnmain.cgi +++ b/html/cgi-bin/vpnmain.cgi @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td>$Lang::tr{'vpn keyexchange'}:</td> <td> <select name='IKE_VERSION'>

• 			<option value='ikev2'
  

$selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option>

• 			<option value='ikev2'
  

$selected{'IKE_VERSION'}{'ikev2'}>IKEv2 ($Lang::tr{'recommended'})</option> <option value='ikev1' $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> </select> </td>

Why should IKEv2 be recommended? AFAIK there are no known design issues with IKEv1. Some algorithms might not be available, but this is not an issue for now since AES, SHA2, (AKA the strong ones) are supported.

...

@@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'encryption'}</td> <td class='boldbase'> <select name='IKE_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='aes256gcm128'
  

$checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option>

• 			<option value='aes256gcm128'
  

$checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'IKE_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option> @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='aes256gcm128'
  

$checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option>

• 			<option value='aes256gcm128'
  

$checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'ESP_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option>

Why are the AES-GCM cipher suites with smaller IVs not recommended?

...

@@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'integrity'}</td> <td class='boldbase'> <select name='IKE_INTEGRITY' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='sha2_512'
  

$checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option>

• 			<option value='sha2_512'
  

$checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES XCBC</option>

Same as above.

...

@@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_INTEGRITY' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='sha2_512'
  

$checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option>

• 			<option value='sha2_512'
  

$checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES XCBC</option>

Same again.

There seems to be a problem with the word "recommended". In the patches submitted, I recommended always the most strongest cipher. However, as you said, some of them are simply one step too much. Should then both be recommended? In my opinion, this has to be clarified, but since it is a very subjective thing, it might be difficult.

...

diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..b18cace 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1914,6 +1914,7 @@ 'rebooting ipfire' => 'Starte IPFire neu', 'reconnect' => 'Neu Verbinden', 'reconnection' => 'Wiederverbindung', +'recommended' => 'empfohlen', 'red' => 'Internet', 'red1' => 'ROT', 'references' => 'Referenzen',

The English translation is missing.

Oh, sorry, I forgot.

Best, -Michael

Best regards, Timmothy Wilson

On Sun, 2015-12-13 at 16:10 +0100, IT Superhack wrote:

Hello Michael,

Michael Tremer:

...

Hello,

this patch was line-wrapped and cannot be merged, but nevertheless, here are my thoughts:

I am unable to submit patches at the moment, since git send-email keeps crashing on every machine I own - sometimes starttls issues, sometimes segfault - and TB seems to line-wrap.

Weird that that happens. If you are using git on IPFire and experiencing these issues, please open a bug report.

...

On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote:

...

Signed-off-by: Timmothy Wilson itsuperhack@web.de

diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi -bin/ovpnmain.cgi index 62af54e..15385f1 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1316,7 +1316,7 @@ END <option value='1024' $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option> <option value='2048' $selected{'DHLENGHT'}{'2048'}>2048 $Lang::tr{'bit'}</option> <option value='3072' $selected{'DHLENGHT'}{'3072'}>3072 $Lang::tr{'bit'}</option>

• 		<option value='4096'
  

$selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'}</option>

• 		<option value='4096'
  

$selected{'DHLENGHT'}{'4096'}>4096 $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> </select> </td>

</tr>

I agree, that it is desirable to use longer keys. However, I am not sure if it is a good idea to go all the way for 4096 bit and not only for e.g. 2048 bit. Why not 8192 even?

Since the SSLTest server page treats 2048 DH primes as "weak", I guess 3072 or better is suitable here.

...

I would like to read some justification for the values that are picked.

Here is one, for example: https://netzpolitik.org/2015/kryptographie-open-source-und-gesellscha ft/ (german, please see "8."). In this article is also mentioned that 512 bit hash algorithms should be used.

...

Furthermore, I think that we the upper bound should be something that the average IPFire box is able to handle.

I agree with that. Maybe 3072 bits is a good deal between speed and security, what do you think?

That depends entirely on the hardware. We cannot know what people are using. That makes it rather complicated to decide.

...

...

@@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <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-256-CBC' 	
  

$selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}, $Lang::tr{'recommended'})</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='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'})</option>

I can agree with that since it is already selected by default. This makes it just more explicit.

I would have merged this if this was an independent patch in a patch set.

Thanks, but at the moment, i cannot hand in a patch without wrapped lines.

For now you could push the git branch somewhere and I can pull that. Sending comments is difficult though, hence we do this on this list with patches.

...

...

@@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> <td><select name='DAUTH'> <option value='whirlpool' $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 $Lang::tr{'bit'})</option>

• 		<option value='SHA512'		
  

  $selected{'DAUTH'}{'SHA512'}>SHA2 (512

$Lang::tr{'bit'})</option>

• 		<option value='SHA512'		
  

  $selected{'DAUTH'}{'SHA512'}>SHA2 (512

$Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> <option value='SHA384' $selected{'DAUTH'}{'SHA384'}>SHA2 (384 $Lang::tr{'bit'})</option> <option value='SHA256' $selected{'DAUTH'}{'SHA256'}>SHA2 (256 $Lang::tr{'bit'})</option> <option value='SHA1'

$selected{'DAUTH'}{'SHA1'}>SHA1 (160 $Lang::tr{'bit'} Default)</option>

Same as above. SHA2 is considered to be "secure enough for now". Why is 256 bit not enough? This has also a rather huge performance impact. Things like these should also be mentioned in the commit message.

...

diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi index f1cffb8..9aa50f5 100644 --- a/html/cgi-bin/vpnmain.cgi +++ b/html/cgi-bin/vpnmain.cgi @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td>$Lang::tr{'vpn keyexchange'}:</td> <td> <select name='IKE_VERSION'>

• 			<option value='ikev2'
  

$selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option>

• 			<option value='ikev2'
  

$selected{'IKE_VERSION'}{'ikev2'}>IKEv2 ($Lang::tr{'recommended'})</option> <option value='ikev1' $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> </select> </td>

Why should IKEv2 be recommended? AFAIK there are no known design issues with IKEv1. Some algorithms might not be available, but this is not an issue for now since AES, SHA2, (AKA the strong ones) are supported.

...

@@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'encryption'}</td> <td class='boldbase'> <select name='IKE_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'>

• 			<option
  

value='aes256gcm128' $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option>

• 			<option
  

value='aes256gcm128' $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'IKE_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option> @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_ENCRYPTION' multiple='multiple' size='6' style='width: 100%'>

• 			<option
  

value='aes256gcm128' $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV</option>

• 			<option
  

value='aes256gcm128' $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit ICV ($Lang::tr{'recommended'})</option> <option value='aes256gcm96' $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit ICV</option> <option value='aes256gcm64' $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit ICV</option> <option value='aes256' $checked{'ESP_ENCRYPTION'}{'aes256'}>256 bit AES-CBC</option>

Why are the AES-GCM cipher suites with smaller IVs not recommended?

...

@@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <td class='boldbase' width="15%">$Lang::tr{'integrity'}</td> <td class='boldbase'> <select name='IKE_INTEGRITY' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='sha2_512'
  

$checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option>

• 			<option value='sha2_512'
  

$checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES XCBC</option>

Same as above.

...

@@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || </td> <td class='boldbase'> <select name='ESP_INTEGRITY' multiple='multiple' size='6' style='width: 100%'>

• 			<option value='sha2_512'
  

$checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option>

• 			<option value='sha2_512'
  

$checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit ($Lang::tr{'recommended'})</option> <option value='sha2_384' $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> <option value='sha2_256' $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> <option value='aesxcbc' $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES XCBC</option>

Same again.

There seems to be a problem with the word "recommended". In the patches submitted, I recommended always the most strongest cipher. However, as you said, some of them are simply one step too much. Should then both be recommended?

I am not sure. Can anyone come up with a more fitting expression? If we mark everything as "recommended" that is strong enough for now after our consideration, we will have most of them tagged with that word. In that case it would make more sense to mark the weak stuff as such to keep readability. Maybe that is the way to go. But does the average Joe know what is meant by "weak"?

In my opinion, this has to be clarified, but since it is a very subjective thing, it might be difficult.

It is not really just subjective. We can say for sure that some ciphers and hashes are broken. We can also say that some are weak and will be considered broken soon. That is pretty much objective since we have sources for that. If only enough people agree that X is broken or weak, that is pretty much a fact.

The recommendation though is more complicated because I would like to take into account how feasible it is to use a certain cipher/hash/etc. RSA with 8192 bits long keys is quite nice. We can assume that it is more secure than RSA with a 4096 bits long key if it was generated from true random numbers. However handshakes will take longer. Generating the key will take weeks on some systems. I want this to be reflected by this change. Please feel free to disagree with me on this :)

Can we get more people to send their thoughts on this?

...

...

diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..b18cace 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1914,6 +1914,7 @@ 'rebooting ipfire' => 'Starte IPFire neu', 'reconnect' => 'Neu Verbinden', 'reconnection' => 'Wiederverbindung', +'recommended' => 'empfohlen', 'red' => 'Internet', 'red1' => 'ROT', 'references' => 'Referenzen',

The English translation is missing.

Oh, sorry, I forgot.

...

Best, -Michael

Best regards, Timmothy Wilson

-Michael

This marks AES-CBC (256 bits) as "recommended" on the OpenVPN main cgi, which is also set as default already. Furthermore, SHA1 is marked as "weak" on the "advanced options" page in the OpenVPN cgi.

All translations for "recommended" and "weak" are still missing, except the german one.

Signed-off-by: Timmothy Wilson itsuperhack@web.de --- diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index 62af54e..cd85a9e 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <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-256-CBC' $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, $Lang::tr{'default'}) ($Lang::tr{'recommended'})</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='DES-EDE3-CBC' $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 $Lang::tr{'bit'})</option> @@ -4705,7 +4705,7 @@ if ($cgiparams{'TYPE'} eq 'net') { <option value='SHA512' $selected{'DAUTH'}{'SHA512'}>SHA2 (512 $Lang::tr{'bit'})</option> <option value='SHA384' $selected{'DAUTH'}{'SHA384'}>SHA2 (384 $Lang::tr{'bit'})</option> <option value='SHA256' $selected{'DAUTH'}{'SHA256'}>SHA2 (256 $Lang::tr{'bit'})</option> - <option value='SHA1' $selected{'DAUTH'}{'SHA1'}>SHA1 (160 $Lang::tr{'bit'} Default)</option> + <option value='SHA1' $selected{'DAUTH'}{'SHA1'}>SHA1 (160 $Lang::tr{'bit'} Default) ($Lang::tr{'weak'})</option> </select> </td> </tr> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl index 2bca854..1d1705b 100644 --- a/langs/de/cgi-bin/de.pl +++ b/langs/de/cgi-bin/de.pl @@ -1912,6 +1912,7 @@ 'reboot sure' => 'Sind Sie sicher, dass Sie neustarten wollen?', 'rebooting' => 'Starte neu ...', 'rebooting ipfire' => 'Starte IPFire neu', +'recommended' => 'empfohlen', 'reconnect' => 'Neu Verbinden', 'reconnection' => 'Wiederverbindung', 'red' => 'Internet', @@ -2631,6 +2632,7 @@ 'warn when traffic reaches' => 'Warnen wenn Traffic x % erreicht', 'warning messages' => 'Warnhinweise', 'was deleted' => 'wurde gelöscht', +'weak' => 'schwach', 'web hits' => 'Gesamtanzahl der Websites zum ausgewählten Kriterium', 'web proxy' => 'Web-Proxy', 'web proxy configuration' => 'Web-Proxy-Konfiguration', diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl index 4c52392..32911a3 100644 --- a/langs/en/cgi-bin/en.pl +++ b/langs/en/cgi-bin/en.pl @@ -1945,6 +1945,7 @@ 'reboot sure' => 'Are you sure that you want to reboot?', 'rebooting' => 'Rebooting', 'rebooting ipfire' => 'Rebooting IPFire', +'recommended' => 'recommended', 'reconnect' => 'Reconnect', 'reconnection' => 'Reconnection', 'red' => 'Internet', @@ -2675,6 +2676,7 @@ 'warn when traffic reaches' => 'Warn when traffic reaches x %', 'warning messages' => 'Warning messages', 'was deleted' => 'was deleted', +'weak' => 'weak', 'web hits' => 'Total number of websites matching selected criteria for', 'web proxy' => 'Web Proxy', 'web proxy configuration' => 'Web proxy configuration',

EDIT:

The language files for DE and EN looks like this,

de.pl:

--- de.pl.orig 2015-12-29 07:36:00.703878690 +0100 +++ de.pl 2016-01-05 17:17:56.097055275 +0100 @@ -1753,6 +1753,8 @@ 'ovpn generating the root and host certificates' => 'Die Erzeugung der Root- und Host-Zertifikate kann lange Zeit dauern.', 'ovpn ha' => 'Hash-Algorithmus', 'ovpn hmac' => 'HMAC-Optionen', +'ovpn keylenghthost' => 'Host CA Schlüssellänge', +'ovpn keylenghtroot' => 'Root CA Schlüssellänge', 'ovpn log' => 'OVPN-Log', 'ovpn mgmt in root range' => 'Ein Port von 1024 oder höher ist erforderlich.', 'ovpn mtu-disc' => 'Path MTU Discovery',

en.pl like this:

--- en.pl.orig 2015-12-29 07:36:07.546247973 +0100 +++ en.pl 2016-01-05 17:18:28.312516302 +0100 @@ -1786,6 +1786,8 @@ 'ovpn ha' => 'Hash algorithm', 'ovpn hmac' => 'HMAC options', 'ovpn log' => 'OVPN-Log', +'ovpn keylenghthost' => 'Host CA keylenght', +'ovpn keylenghtroot' => 'Root CA keylenght', 'ovpn mgmt in root range' => 'A port number of 1024 or higher is required.', 'ovpn mtu-disc' => 'Path MTU Discovery', 'ovpn mtu-disc and mtu not 1500' => 'Path MTU Discovery requires a MTU of 1500.',

Please do not forget to execute a perl -e "require '/var/ipfire/lang.pl'; &Lang::BuildCacheLang" or similar ;-)

Greetings,

Erik

Am 05.01.2016 um 16:49 schrieb ue:

Hi Michael, have changed now the topic cause "Mark recommended ciphers/algorithms" do not match fully this topic.

Am 04.01.2016 um 17:36 schrieb Michael Tremer:

...

Hi,

On Sat, 2016-01-02 at 14:03 +0100, ue wrote:

...

Hi all, and for the first a good new year to you all.

...

I agree, that it is desirable to use longer keys. However, I am not sure if it is a good idea to go all the way for 4096 bit and not only for e.g. 2048 bit. Why not 8192 even?

I would like to read some justification for the values that are picked.

Furthermore, I think that we the upper bound should be something that the average IPFire box is able to handle.

tried that now with OpenVPN whereby i added a flip menu in the 'Generate Root/Host Certificate' section as it is for the Diffie -Hellman parameter so the keylengths aren´t hardcoded anymore and can be configured by the user. Added for the root CA 4096, 8192 and 16348 tit lengths selection possibilities and for the host CA 2048, 4096, 8192 and also 16348 bit. The configured keylength for the host CA was also used for the control channel.

Is it even possible to use arbitrary key lengths with OpenVPN?

Yes i have added some more keylenghts which should be in a current spectrum of a possible min. max. usage. Little example for between values of 4096 and 8192 --> https://wiki.strongswan.org/projects/1/wiki/PublicKeySpeed but there is shurley more.

...

16k is really really long.

Yes it´s a lot, nevertheless i tried currently to find out the thresholds of RSA generation to get some more knowledge behind the whole X509 generation over IPFires web interface. By searching a little around, i discovered that 32768 bit supposed to be the RSA max. keylenght (shurley too much for IPFire). I try that currently (just for interessting purposes). 16k keylenght is a kind of big but i think in conjunction with a 8192 bit host CA keylenght (control channel encryption) but also an 1024 bit DH prime (the upload check for 4096 + can also be modified without problems), the measured time of ~ 45 minutes are not that much as i expected.

...

...

The Root CA generation took 31 minutes for a 16348 bit keylength, the Host CA 12 minutes for 8192 bit and a 1024 bit DH-parameter needed 2 minutes which is in summary ~ 45 minutes. The generation time differs also on every generation. The creation of a new client PKCS#12 package for 8192 bit needed 3 minutes. The key exchange with a Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA needed 10 sec.

This sounds increadible fast to me. We had devices on which that took way longer.

I think so. One time waiting while the first generation of the whole PKI but all measured values after that (client PKCS#12 generation, connection build up, keyexchange) are barley recognizable related to IPFires current setup which aren´t in proportion to the security purposes in my opinion.

...

I have recently seen a talk about using /dev/urandom instead. This is probably worth a watch: https://www.youtube.com/watch?v=Q8JAlZ-HJQI

Nice talk. I think OpenSSL uses in any case /dev/urandom, only exception which uses /dev/random i have currently in mind is GPG, but may my picture is wrongregarding that topic ?

...

...

All tests was made with a JNC9C --> http://fireinfo.ipfire.org/profil e/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or PRNG .

If someone is interested in a ovpnmain.cgi diff and/or more testing results let it me know.

You can post it as a patch on here and add a note that this is for testing only and not (yet?) intended to be merged.

All right,

This patch is for testing purposes/results only, please do not merge that. May there are new ideas and corrections for that?

It includes two new menus for configuring the keysize of the root CA and the host CA. The configured keylenght for the host CA will automatically investigated from the serverkey.pem and will be set in 'newkey' section while PKCS#12 client generation and will be used for the control channel enrcyption too. Have added also some more keylenghts which should only support some more testing results and a look behind the curtain. Have find also some bugs which i may can fix in the next time. One directly regarding to this topic is --> If a X509 and already generated clients will be removed, a 'malformed header from script. Bad header=Wrapper for OpenVPN ipfire-2.2: ovpnmain.cgi,' appears with a 'internal server error' subsequently where a reload of the page brings back the ovpnmain.cgi. Have added also the '-rand' option which is possibly redundant since OpenSSL uses anyway /dev/urandom (tests can be made with an unpatched cgi with strace and the appropriate OpenSSL commands) .

I wanted also to suggest that OpenVPN-2.4.x will deliver EC crypto which might be also interessting to configure it via the WUI ?!

It may also be possible to deliver a flip menu for the Hashes but this should be for a first test o.k. i think.

--- ovpnmain.cgi.orig 2015-12-29 14:20:27.008228796 +0100 +++ ovpnmain.cgi 2016-01-05 12:48:09.014389131 +0100 @@ -1842,7 +1842,9 @@ } } else { # child unless (exec ('/usr/bin/openssl', 'req', '-x509', '-nodes',

• 	'-days', '999999', '-newkey', 'rsa:4096', '-sha512',
  

• 	'-days', '999999',
  

• 	'-newkey', "$cgiparams{'ROOTKEYLENGHT'}", '-sha512',
  

• 	'-rand', '/dev/urandom',
  '-keyout', "${General::swroot}/ovpn/ca/cakey.pem",
  '-out', "${General::swroot}/ovpn/ca/cacert.pem",
  '-config',"${General::swroot}/ovpn/openssl/ovpn.cnf")) {
  

@@ -1873,7 +1875,8 @@ } } else { # child unless (exec ('/usr/bin/openssl', 'req', '-nodes',

• 	'-newkey', 'rsa:2048',
  

• 	'-newkey', "$cgiparams{'HOSTKEYLENGHT'}",
  

• 	'-rand', '/dev/urandom',
  '-keyout', "${General::swroot}/ovpn/certs/serverkey.pem",
  '-out', "${General::swroot}/ovpn/certs/serverreq.pem",
  '-extensions', 'server',
  

@@ -1993,6 +1996,34 @@ } print <<END; </select></td>

• <tr><td>&nbsp;</td>

• <tr><td class='base'>$Lang::tr{'ovpn keylenghtroot'}:</td>

• <td class='base'><select name='ROOTKEYLENGHT'>
  

• 		<option value='4096' $selected{'ROOTKEYLENGHT'}{'rsa:4096'}>4096 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='6144' $selected{'ROOTKEYLENGHT'}{'rsa:6144'}>6144 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='8192' $selected{'HOSTKEYLENGHT'}{'rsa:8192'}>8192 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='12288' $selected{'HOSTKEYLENGHT'}{'rsa:12288'}>12288 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='16384' $selected{'ROOTKEYLENGHT'}{'rsa:16384'}>16384 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='32768' $selected{'ROOTKEYLENGHT'}{'rsa:32768'}>32768 $Lang::tr{'bit'} RSA</option>
  

• 	</select>
  

• </tr>

• <tr><td>&nbsp;</td>

• <tr><td class='base'>$Lang::tr{'ovpn keylenghthost'}:</td>

• <td class='base'>
  

• 	<select name='HOSTKEYLENGHT'>
  

• 		<option value='2048' $selected{'HOSTKEYLENGHT'}{'rsa:2048'}>2048 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='4096' $selected{'HOSTKEYLENGHT'}{'rsa:4096'}>4096 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='6144' $selected{'HOSTKEYLENGHT'}{'rsa:6144'}>6144 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='8192' $selected{'HOSTKEYLENGHT'}{'rsa:8192'}>8192 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='12288' $selected{'HOSTKEYLENGHT'}{'rsa:12288'}>12288 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='16384' $selected{'HOSTKEYLENGHT'}{'rsa:16384'}>16384 $Lang::tr{'bit'} RSA</option>
  

• 		<option value='32768' $selected{'ROOTKEYLENGHT'}{'rsa:32768'}>32768 $Lang::tr{'bit'} RSA</option>
  

• 	</select>
  

• </td>
  

• </tr>

• <tr><td>&nbsp;</td></select></td> <tr><td class='base'>$Lang::tr{'ovpn dh'}:</td> <td class='base'><select name='DHLENGHT'> <option value='1024' $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option>

@@ -2004,6 +2035,7 @@

</tr>

<tr><td>&nbsp;</td> + <tr><td>&nbsp;</td> <td><input type='submit' name='ACTION' value='$Lang::tr{'generate root/host certificates'}' /></td> <td>&nbsp;</td><td>&nbsp;</td></tr> <tr><td class='base' colspan='4' align='left'> @@ -4202,6 +4234,10 @@ (my $ou = $cgiparams{'CERT_OU'}) =~ s/^\s*$/\./; (my $city = $cgiparams{'CERT_CITY'}) =~ s/^\s*$/\./; (my $state = $cgiparams{'CERT_STATE'}) =~ s/^\s*$/\./; + # Investigate host serverkey lenght + my $keylenght = `/usr/bin/openssl rsa -text -noout -in "${General::swroot}/ovpn/certs/serverkey.pem"`; + $keylenght =~ m/(\d+)/; + $keylenght = $1;

   # Create the Host certificate request client
   my $pid = open(OPENSSL, "|-");

@@ -4219,13 +4255,14 @@ close (OPENSSL); if ($?) { $errormessage = "$Lang::tr{'openssl produced an error'}: $?";

•     unlink ("${General::swroot}ovpn/certs/$cgiparams{'NAME'}key.pem");
  

•     unlink ("${General::swroot}ovpn/certs/$cgiparams{'NAME'}req.pem");
  

•     unlink ("${General::swroot}/ovpn/certs/$cgiparams{'NAME'}key.pem");
  

•     unlink ("${General::swroot}/ovpn/certs/$cgiparams{'NAME'}req.pem");
  

  goto VPNCONF_ERROR; } } else { # child unless (exec ('/usr/bin/openssl', 'req', '-nodes',

• 	'-newkey', 'rsa:2048',
  

• 	'-newkey', "rsa:$keylenght",
  

• 	'-rand', '/dev/urandom',
  '-keyout', "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}key.pem",
  '-out', "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}req.pem",
  '-config',"${General::swroot}/ovpn/openssl/ovpn.cnf")) {
  
  
  
  

Greetings,

Erik