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

[Michael Tremer <michael.tremer@ipfire.org>]

[-- 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 --]