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

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

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

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.

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

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

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

> 
> > 
> > > > 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#Removalo
> > 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#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
>  .
> 

I cannot believe my eyes what I am reading on that page.


https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Migratingawayfromdeprecatedciphers

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.

> 
> 
> Best,
> 
> 
> Erik