Re: [PATCH] OpenVPN: Introduce Negotiable Crypto Parameters for roadwarriors

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

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

On Tue, 2018-08-28 at 21:35 +0200, ummeegge wrote:
> Am Dienstag, den 28.08.2018, 11:21 +0100 schrieb Michael Tremer:
> > Hi,
> > 
> > On Mon, 2018-08-27 at 18:21 +0200, ummeegge wrote:
> > > Hi Michael,
> > > 
> > > Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > > > > > 
> > > > > 
> > > > > I think this is also the reason why Fedora did used 256-CBC in
> > > > > second
> > > > > place in their list. If --ncp-ciphers is activated and the
> > > > > client
> > > > > is
> > > > > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > > > > should
> > > > > match in mostly cases but uses also the longest possible
> > > > > keysize.
> > > > 
> > > > So I had a little thought about all of this and I guess I have
> > > > figured out what
> > > > my problem is with the current approach:
> > > > 
> > > > * NCP generally is a good idea. We should *encourage* people to
> > > > use/activate it
> > > > and make sure that they use the strongest cipher possible.+
> > > 
> > > Think so.
> > > 
> > > > 
> > > > * Hardcoding is, however, a very bad idea. I would agree that
> > > > AES-
> > > > 256-GCM/CBC is
> > > > good enough for everyone right now. But we don't know what is
> > > > happening further
> > > > down the line.
> > > 
> > > That´s true but a good point in there is that this configuration is
> > > only presant on server side so the old problem to make changes on
> > > client and server side do not appears anymore which is different to
> > > mostly other directives.
> > 
> > Now it is, but it wasn't in the past.
> 
> Yes.
> 
> > 
> > > > So my suggestion is to add a menu just like we have in the
> > > > "advanced"
> > > > section of
> > > > every IPsec connection. A dropdown where you can select multiple
> > > > ciphers at the
> > > > same time. That should be the ncp-ciphers list.
> > > 
> > > Since OpenVPN have the reputation of an easy to use VPN i´ am not
> > > sure
> > > if this is a good idea. People with not that background knowledge 
> > > (e.g. what is the difference between CBC and GCM) might have there
> > > a
> > > problem with a good decision. As outlined before, the first Cipher
> > > if
> > > it is a Galois/counter mode should be used meanwhile in possibly
> > > more
> > > than 50% of the machines out there, the second one, if CBC, is a
> > > 99%er
> > > so the whole selection like for IPSec becomes overkill in my
> > > opinion
> > > even there is also no possiblity to select integrity, or
> > > Grouptypes.
> > 
> > OpenVPN isn't easy. People with too little knowledge should better
> > not touch
> > anything here.
> > 
> > Therefore we put the cipher selection into the advanced section. If
> > you have no
> > idea what you are doing, don't touch it and go with the default. If
> > you want to
> > change things, you have all the freedom that there is.
> > 
> > There is no need for integrity and group types. We have those options
> > somewhere
> > else and OpenVPN only supports one at a time. This will only be for
> > the cihers.
> 
> OK, Will need longer time for this one then.
> 
> > 
> > > >  And there should be an extra
> > > > dropdown for the legacy "cipher" option.
> > > 
> > > The old cipher drop down is still presant and is also needed to
> > > deliver
> > > a cipher for those clients which do not understand --ncp-cipher
> > > (all
> > > clients below 2.4).
> > > 
> > > > 
> > > > Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher
> > > > option
> > > > should be
> > > > empty if possible 
> > > 
> > > Won´t leave it empty othewise all clients below 2.4 won´t work
> > > anymore.
> > > The NCP stuff comes with v2.4.
> > 
> > Okay.
> > 
> > > 
> > > > or AES-256-GCM for new setups.
> > > 
> > > We can become there also problems if older OpenSSL libs are in
> > > usage.
> > > As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
> > > 100% sure with this) so we would strip all systems below out (if no
> > > internal OpenSSL are in usage via e.g. a OpenVPN client software).
> > > AES-
> > > 256-CBC is the current default value for the "legacy" cipher drop
> > > down
> > > which should match all the old ones out there too and should also
> > > provide a good state of security.
> > 
> > Okay, AES-256-CBC is fine, too when there is better interoperability.
> > 
> > > 
> > > > 
> > > > * That would allow loads of flexibility to the users and they
> > > > would
> > > > be able to
> > > > deselect certain things. So if CBC gets broken (hypothetically),
> > > > people can
> > > > deselect those and they are done. That's better than having an
> > > > option
> > > > called
> > > > "strong" that is hardcoded to AES-256-* and "fast" that is AES-
> > > > 128-*
> > > > or so.
> > > 
> > > I guess i would do it in that way. If (hypothetically) CBC gets
> > > broken,
> > > we can change this settings centrally via updates since the server
> > > pushes this directives and the clients do not see that in their
> > > configuration.
> > 
> > We cannot touch any configuration ever. We never do that.
> > 
> > Even *if* a cipher is utterly broken, we have to leave it in there to
> > not break
> > any existing setups.
> 
> OK, this makes sense.
> 
> > 
> > > IPFire is and was always fast to fix seriouse problems ;-) and such
> > > problem can be fixed via ovpnmain.cgi for all existing clients
> > > which
> > > uses NCP.
> > > 
> > > > 
> > > > I thought we would get around it to implement this, because it
> > > > probably is a
> > > > little bit more to write (especially checking for valid input).
> > > > But I
> > > > guess
> > > > there is ultimately no easy option.
> > > 
> > > I think there is one. Currently i´d have only a checkbox to switch
> > > this
> > > one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other
> > > side do
> > > supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it
> > > for
> > > them.
> > 
> > It is not acceptable to hard-code the ciphers here.
> > 
> > > I think it is nice to have a little menu with 2 or 3 different
> > > selection possibilities (strong, fast, legacy) but like in IPSec
> > > advanced settings would sprinkle the frame in my opinion. Let´s
> > > start
> > > with this if we have ECC fully implemented and TLS1.3 arives in
> > > OpenVPN
> > > :D .
> > 
> > If you want one dropdown with multiple options, then that leaves you
> > with a lot
> > of combinations to implement. It also requires extra documentation to
> > make clear
> > what "fast" is supposed to mean. This is not a good solution.
> 
> I see.
> 
> > 
> > > 
> > > > 
> > > > > > Should we have blowfish enabled? That's a good question.
> > > > > > Should
> > > > > > the
> > > > > > last option rather not be what the user has selected on the
> > > > > > web
> > > > > > UI?
> > > > > 
> > > > > BF-CBC on that place is also shown as an example configuration
> > > > > on
> > > > > OpenVPN itself
> > > > > 
> > > > 
> > > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remo
> > > > valo
> > > > finsecureciphers:Cipherswithcipherblock-
> > > > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > > > > whereby it seems that this is only a temporary solution for
> > > > > very
> > > > > old
> > > > > clients to migrate also via the help of --ncp-ciphers step by
> > > > > step
> > > > > to
> > > > > other configurations without to change the whole at once.
> > > > > I think there might be rare cases that the last cipher in the
> > > > > list
> > > > > will
> > > > > be used especially if AES-CBC comes before which mostly systems
> > > > > should
> > > > > have. 
> > > > > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > > > > problem)
> > > > > and is meanwhile deprecated but OpenVPN will also remove it
> > > > > with
> > > > > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
> > > > 
> > > > LOL. Great idea. There are tons of deployments out there that
> > > > will
> > > > just break
> > > > because of no way for the client to negotiate a cipher.
> > > 
> > > Yes, rough days ahead :D. Here is the official one --> 
> > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Remova
> > > lofinsecureciphers:Cipherswithcipherblock-
> > > sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > >  .
> > > 
> > 
> > I cannot believe my eyes what I am reading on that page.
> 
> Yes, needed also some braingoo for all that and it seems that it is not
> finished at all...

Just because this is quite topical today: Alex just told me how long it took him
to replace 20 N2N connections and 80 RW connections. Poor him.

There is a very good reason why we don't have OpenVPN in IPFire 3.

> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratin
> > gawayfromdeprecatedciphers
> > 
> > Basically, people are already using something else than what they
> > have selected
> > with the ciphers option. *Everyone* is using AES-256-GCM now. No
> > matter what is
> > being selected.
> > 
> > > 
> > > > 
> > > > Not sure when ncp-ciphers was introduced, but I have never seen
> > > > that
> > > > anywhere.
> > > 
> > > NCP comes with v2.4
> > 
> > No I means it being configured somewhere.Ah OK.
> 
> OK.
> 
> Best,
> 
> Erik