[PATCH] Disallow OpenVPN DH params less than 1024 bits

[PATCH] Disallow OpenVPN DH params less than 1024 bits

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

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(a)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:',
-- 
1.8.4.5



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Disallow OpenVPN DH params less than 1024 bits

[ue]

[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]

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/services/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.org/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(a)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:',
> -- 
> 1.8.4.5
> 
> 

Re: [PATCH] Disallow OpenVPN DH params less than 1024 bits

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]

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(a)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:',

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Disallow OpenVPN DH params less than 1024 bits

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 6391 bytes --]

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?

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.

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

DH Params with sizes 1024 and 2048 bits.

OpenVPN page - advanced options:
SHA1

IPSec page - advanced connection options:
SHA1

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.

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(a)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:',



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Disallow OpenVPN DH params less than 1024 bits

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 9589 bytes --]

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(a)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:',
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Disallow OpenVPN DH params less than 1024 bits

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 12435 bytes --]

Hello Michael,

Michael Tremer:
> 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.
I agree with that.
> 
> 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.
Personally, I don't know a method to crack 3DES with normal time effort,
either. But since the effective strength of 3DES is 80 bits only, it
should be considered at least as "weak" in my point of view. (Source:
http://www.differencebetween.net/technology/difference-between-aes-and-3des/)

For example, Ivan Ristic recommends in his book "Bulletproof SSL and
TLS" not to use ciphers with a strength less than 128 bits.

I guess in the next few years we'll see the breakdown of 3DES...
> 
>>
>> 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.
Regrettably, this is true. Even if you turn off SHA1 & Co. in IPFire,
users just will set up another firewall software that still supports
those ciphers. In the end, nothing is won by that.

However, I'm still happy that IPFire does not support RC4 and MD5 in VPN
connections and the internal Apache webserver.

By the way: What about SHA1-suites in Apache? I disabled them recently
on my local machine, and nobody has ever complaint about not getting a
TLS connection to the firewall in my company.
But disabling SHA1 effectively turns off TLS 1.0 in HTTPS, because
SHA2/SHA3 is only supported in TLS 1.2 suites. In IPFire, this might
cause problems (especially with the Internet Exploder), but it would
certainly improve transport security.
> 
>>
>> 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.
Being an cryptography expert, yes.

In my opinion (= a normal, a bit paranoid user), "weak" and "insecure"
match. If a cipher is considered weak, it usually takes a short time
until it is "insecure" (see RC4 for example). So, if I want to protect a
secret, I'd use neither "weak" nor "insecure" ciphers - in ten years, it
has the same effect.

Another thought to this topic: How long should we assume the transmitted
contents of a VPN connection or a HTTPS connection to Apache to be
secure at least?
In most scenarios, you pick your algorithms (if you are serious about
them) from the answer of that question. For example, if you want a
protection of five years, AES128 is plenty (3DES fits in here, too).
If you are looking for 30 years or more (including quantum computers),
3DES and AES128 are wrong choices.
> 
> 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.
Yes, indeed. I was not thinking about certificates, but they are
important, too.

Speaking about certificates: At the moment, IPFire uses RSA-2048 and
RSA-4096 for them. How about ECDSA?
(I am not sure if OpenVPN and StrongSwan support ECDSA keys yet, but
Apache certainly does so.)
ECDSA is my personal favorite because it is fast and secure. An
ECDSA-256 private key is equal to an RSA-2048 private key, talking about
security. The generation and use of ECDSA, however, is much faster,
which might be comfortable for VPN connections.
> 
> Is anybody up for doing this?
I could take care of those certificate issue, yes. Submitting a patch
which adds "weak" to ciphers mentioned above (I'll leave out 3DES for
this time) should also be easy, that is, if I can get send-email
working. :-(

Best regards,
Timmothy Wilson
> 
> 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(a)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:',
>>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH] Mark recommended ciphers/algorithms

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 6536 bytes --]

Signed-off-by: Timmothy Wilson <itsuperhack(a)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',



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8186 bytes --]

Hello,

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

On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote:
> Signed-off-by: Timmothy Wilson <itsuperhack(a)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?

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.

> @@ -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.

> @@ -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.

> 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.

Best,
-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 9551 bytes --]

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(a)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



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

On Sun, 13 Dec 2015 16:10:13 +0100, IT Superhack <itsuperhack(a)web.de>  
wrote:

> 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.

https://addons.mozilla.org/en-US/thunderbird/addon/toggle-word-wrap/


hth,
Lars

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 12102 bytes --]

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(a)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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

>> > 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.

Is there a way to present the users a message and let them decide which  
length they want to use?



>> 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"?

Joe should know enough that "weak" is normally not what is wanted.  
Otherwise he should RTFM ;-)

You could recommend the strongest cipher that would take an attacker  
millions of years to break, but on the other hand force the hardware to  
burn its CPU, while another "not as strong as the recommended one" cipher  
would also take an attacker thousands of years, but not consume that much  
CPU. Would have to differentiate between "recommended for high performance  
CPU" and "recommended for your small box". So, that doesn't sound good.

Weak is weak for every kind of hardware. So +1 for "weak".


Lars

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]

On Tue, 2015-12-15 at 16:03 +0100, Larsen wrote:
> > > > 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.
> 
> Is there a way to present the users a message and let them decide
> which  
> length they want to use?

Yes, the user has to decide this at some occasions.

> 
> 
> 
> > > 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"?
> 
> Joe should know enough that "weak" is normally not what is wanted.  
> Otherwise he should RTFM ;-)
> 
> You could recommend the strongest cipher that would take an attacker 
> millions of years to break, but on the other hand force the hardware
> to  
> burn its CPU, while another "not as strong as the recommended one"
> cipher  
> would also take an attacker thousands of years, but not consume that
> much  
> CPU.

It is always about the tradeoffs. If we didn't have to do these we
wouldn't have AES. We would only use OTP.

> Would have to differentiate between "recommended for high performance
>   
> CPU" and "recommended for your small box". So, that doesn't sound
> good.

That doesn't sound good at all because it is not really the case that
there is such a big difference between the throughput of some of the
algorithms. The right thing would be to upgrade the hardware and keep
the strong security.

> 
> Weak is weak for every kind of hardware. So +1 for "weak".

If we have "weak". Should we have "broken", too? For example we have to
support MD5. I wouldn't say that MD5 is weak. It is more than that.

> 
> 
> Lars

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

>> Weak is weak for every kind of hardware. So +1 for "weak".
>
> If we have "weak". Should we have "broken", too? For example we have to
> support MD5. I wouldn't say that MD5 is weak. It is more than that.

If we need to support it, it should be "broken", yes.


Lars

[PATCH] Mark recommended ciphers/algorithms

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]

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(a)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',



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Hello Michael, hello Larsen,

sorry for not replying a while; xmas is always very busy

>>> 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"?
> 
> Joe should know enough that "weak" is normally not what is wanted.  
> Otherwise he should RTFM 
> 
> You could recommend the strongest cipher that would take an attacker 
> millions of years to break, but on the other hand force the hardware
> to  
> burn its CPU, while another "not as strong as the recommended one"
> cipher  
> would also take an attacker thousands of years, but not consume that
> much  
> CPU.
Maybe it is better to mark just the weak or broken entries. I agree,
"recommended" is not very specific here - maybe "strongest" would be
better. Especially to mark AES-256-CBC on the OpenVPN main page.

> 
> If we have "weak". Should we have "broken", too? For example we have to
> support MD5. I wouldn't say that MD5 is weak. It is more than that.
Okay, so we have:
MD5		"broken"
SHA1		"weak"
DH-1024-params	"broken" (? not sure about this)
DH-2048-params	"weak"
AES-256-CBC	"recommended"/"strongest" (on OpenVPN page only)

Do you think this is a good way to start? If yes, I could send in some
patches.

> 
> 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.
@Michael: That is correct, I did not RTFM. o:-)

Looking forward to hear from you. Happy new year!

Best regards,
Timmothy Wilson


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

Hello and happy new year,

On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote:
> Hello Michael, hello Larsen,
> 
> sorry for not replying a while; xmas is always very busy

Same.

> > > > 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"?
> > 
> > Joe should know enough that "weak" is normally not what is wanted. 
> > Otherwise he should RTFM 
> > 
> > You could recommend the strongest cipher that would take an
> > attacker 
> > millions of years to break, but on the other hand force the
> > hardware
> > to  
> > burn its CPU, while another "not as strong as the recommended one"
> > cipher  
> > would also take an attacker thousands of years, but not consume
> > that
> > much  
> > CPU.
> Maybe it is better to mark just the weak or broken entries. I agree,
> "recommended" is not very specific here - maybe "strongest" would be
> better. Especially to mark AES-256-CBC on the OpenVPN main page.

Using "strongest" is a very good idea. As mentioned earlier it is hard
to tell if an algorithm is good or bad, but we can rank them based on
key sizes, etc. And in the end there will be a "strongest" cipher.

That is still as subjective as "weak" is, but I think it is easy to
understand for every user.

> > If we have "weak". Should we have "broken", too? For example we
> > have to
> > support MD5. I wouldn't say that MD5 is weak. It is more than that.
> Okay, so we have:
> MD5		"broken"
> SHA1		"weak"
> DH-1024-params	"broken" (? not sure about this)
> DH-2048-params	"weak"
> AES-256-CBC	"recommended"/"strongest" (on OpenVPN page only)
> 
> Do you think this is a good way to start? If yes, I could send in
> some
> patches.

I can agree on this with all the labels except "broken" for DH-1024. It
works and it makes sense to use this for short-lived keys. It should be
avoided if we can, so I would suggest "very weak".

I think we can label AES-256-GCM as "strongest" on the IPsec page, too.

> 
> > 
> > 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.
> @Michael: That is correct, I did not RTFM. o:-)
> 
> Looking forward to hear from you. Happy new year!
> 
> Best regards,
> Timmothy Wilson

Best,
-Michael
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

Hi Michael,

Michael Tremer:
> Hello and happy new year,
> 
> On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote:
>> Hello Michael, hello Larsen,
>>
>> sorry for not replying a while; xmas is always very busy
> 
> Same.
> 
>>>>> 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"?
>>>
>>> Joe should know enough that "weak" is normally not what is wanted. 
>>> Otherwise he should RTFM 
>>>
>>> You could recommend the strongest cipher that would take an
>>> attacker 
>>> millions of years to break, but on the other hand force the
>>> hardware
>>> to  
>>> burn its CPU, while another "not as strong as the recommended one"
>>> cipher  
>>> would also take an attacker thousands of years, but not consume
>>> that
>>> much  
>>> CPU.
>> Maybe it is better to mark just the weak or broken entries. I agree,
>> "recommended" is not very specific here - maybe "strongest" would be
>> better. Especially to mark AES-256-CBC on the OpenVPN main page.
> 
> Using "strongest" is a very good idea. As mentioned earlier it is hard
> to tell if an algorithm is good or bad, but we can rank them based on
> key sizes, etc. And in the end there will be a "strongest" cipher.
Hmmm, what about CAMELLIA at the IPsec page? As far as I know, it is
not weaker or stronger than AES, but slower and there aren't any GCM
modes available.
> 
> That is still as subjective as "weak" is, but I think it is easy to
> understand for every user.
Yup.
> 
>>> If we have "weak". Should we have "broken", too? For example we
>>> have to
>>> support MD5. I wouldn't say that MD5 is weak. It is more than that.
>> Okay, so we have:
>> MD5		"broken"
>> SHA1		"weak"
>> DH-1024-params	"broken" (? not sure about this)
>> DH-2048-params	"weak"
>> AES-256-CBC	"recommended"/"strongest" (on OpenVPN page only)
>>
>> Do you think this is a good way to start? If yes, I could send in
>> some
>> patches.
> 
> I can agree on this with all the labels except "broken" for DH-1024. It
> works and it makes sense to use this for short-lived keys. It should be
> avoided if we can, so I would suggest "very weak".
Okay.
> 
> I think we can label AES-256-GCM as "strongest" on the IPsec page, too.
1. As above, what about CAMELLIA?
2. Which AES-256-GCM suite is the strongest one? (128/96/64 bits ICV?)
> 
>>
>>>
>>> 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.
>> @Michael: That is correct, I did not RTFM. o:-)
>>
>> Looking forward to hear from you. Happy new year!
>>
>> Best regards,
>> Timmothy Wilson
> 
> Best,
> -Michael
Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7919 bytes --]

Hi,

On Sun, 2016-01-10 at 17:29 +0100, IT Superhack wrote:
> Hi Michael,
> 
> Michael Tremer:
> > Hello and happy new year,
> > 
> > On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote:
> > > Hello Michael, hello Larsen,
> > > 
> > > sorry for not replying a while; xmas is always very busy
> > 
> > Same.
> > 
> > > > > > 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"?
> > > > 
> > > > Joe should know enough that "weak" is normally not what is
> > > > wanted. 
> > > > Otherwise he should RTFM 
> > > > 
> > > > You could recommend the strongest cipher that would take an
> > > > attacker 
> > > > millions of years to break, but on the other hand force the
> > > > hardware
> > > > to  
> > > > burn its CPU, while another "not as strong as the recommended
> > > > one"
> > > > cipher  
> > > > would also take an attacker thousands of years, but not consume
> > > > that
> > > > much  
> > > > CPU.
> > > Maybe it is better to mark just the weak or broken entries. I
> > > agree,
> > > "recommended" is not very specific here - maybe "strongest" would
> > > be
> > > better. Especially to mark AES-256-CBC on the OpenVPN main page.
> > 
> > Using "strongest" is a very good idea. As mentioned earlier it is
> > hard
> > to tell if an algorithm is good or bad, but we can rank them based
> > on
> > key sizes, etc. And in the end there will be a "strongest" cipher.
> Hmmm, what about CAMELLIA at the IPsec page? As far as I know, it is
> not weaker or stronger than AES, but slower and there aren't any GCM
> modes available.

I think that camellia is slower is just marketing or something like
that. On my machine it is actually *a lot* faster than AES.

This machine does not have AES-NI, but even on those machines CAMELLIA
benefits from AES-NI.

[ms(a)rice-oxley ~]$ openssl speed {aes,camellia}-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 14349124 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 3813409 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 969069 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 243184 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 8192 size blocks: 30436 aes-256 cbc's in 3.01s
Doing camellia-256 cbc for 3s on 16 size blocks: 16332000 camellia-256 cbc's in 3.00s
Doing camellia-256 cbc for 3s on 64 size blocks: 5406041 camellia-256 cbc's in 2.99s
Doing camellia-256 cbc for 3s on 256 size blocks: 1471399 camellia-256 cbc's in 3.00s
Doing camellia-256 cbc for 3s on 1024 size blocks: 376682 camellia-256 cbc's in 3.00s
Doing camellia-256 cbc for 3s on 8192 size blocks: 47506 camellia-256 cbc's in 3.00s
OpenSSL 1.0.1k-fips 8 Jan 2015
built on: Fri Dec  4 15:45:46 2015
options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      76784.61k    81352.73k    82693.89k    83006.81k    82834.46k
camellia-256 cbc    87104.00k   115714.59k   125559.38k   128574.12k   129723.05k

3DES is very slow though:

[ms(a)rice-oxley ~]$ openssl speed des-ede3
Doing des ede3 for 3s on 16 size blocks: 5230784 des ede3's in 3.00s
Doing des ede3 for 3s on 64 size blocks: 1328063 des ede3's in 3.00s
Doing des ede3 for 3s on 256 size blocks: 333500 des ede3's in 2.99s
Doing des ede3 for 3s on 1024 size blocks: 83474 des ede3's in 3.00s
Doing des ede3 for 3s on 8192 size blocks: 10474 des ede3's in 3.00s
OpenSSL 1.0.1k-fips 8 Jan 2015
built on: Fri Dec  4 15:45:46 2015
options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des ede3         27897.51k    28332.01k    28553.85k    28492.46k    28601.00k

> > 
> > That is still as subjective as "weak" is, but I think it is easy to
> > understand for every user.
> Yup.
> > 
> > > > If we have "weak". Should we have "broken", too? For example we
> > > > have to
> > > > support MD5. I wouldn't say that MD5 is weak. It is more than
> > > > that.
> > > Okay, so we have:
> > > MD5		"broken"
> > > SHA1		"weak"
> > > DH-1024-params	"broken" (? not sure about this)
> > > DH-2048-params	"weak"
> > > AES-256-CBC	"recommended"/"strongest" (on OpenVPN page
> > > only)
> > > 
> > > Do you think this is a good way to start? If yes, I could send in
> > > some
> > > patches.
> > 
> > I can agree on this with all the labels except "broken" for DH
> > -1024. It
> > works and it makes sense to use this for short-lived keys. It
> > should be
> > avoided if we can, so I would suggest "very weak".
> Okay.
> > 
> > I think we can label AES-256-GCM as "strongest" on the IPsec page,
> > too.
> 1. As above, what about CAMELLIA?

I consider CAMELLIA just as strong as AES. It might have benefits over
AES even. However I consider the GCM cipher mode to be safer (and
usually faster) than CBC which puts those into an order.

> 2. Which AES-256-GCM suite is the strongest one? (128/96/64 bits
> ICV?)

If you have good random numbers a longer IV should be better. I don't
think that that makes a huge difference though.

> > 
> > > 
> > > > 
> > > > 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.
> > > @Michael: That is correct, I did not RTFM. o:-)
> > > 
> > > Looking forward to hear from you. Happy new year!
> > > 
> > > Best regards,
> > > Timmothy Wilson
> > 
> > Best,
> > -Michael
> Best regards,
> Timmothy Wilson
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Mark recommended ciphers/algorithms

[ue]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

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.

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.

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

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


Greetings,

Erik

Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

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?

16k is really really long.

> 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 have recently seen a talk about using /dev/urandom instead. This is
probably worth a watch: https://www.youtube.com/watch?v=Q8JAlZ-HJQI

> 
> 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.

> 
> 
> Greetings,
> 
> Erik

Best,
-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]