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


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