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