Hey,
It is merged. It built (on ARM :D). Who wants to give it a try?
https://nightly.ipfire.org/next/2019-01-17%2019:24:46%20+0000-93d516bd/
-Michael
On 15 Jan 2019, at 14:48, ummeegge ummeegge@ipfire.org wrote:
Hi Peter,
Am Montag, den 14.01.2019, 19:03 +0100 schrieb Peter Müller:
Hello Erik, hello Michael,
sorry for replying late on this.
Hey,
Okay, I had a look at the differences between your two branches. There are a few:
a) Update to openssl 1.1.1a. That’s fine. b) Loads of rootfile changes. I think that is not because of Peter not updating it in his branch. Also fine.
It is also 1.1.1a and as far as i can see Peter used 1.1.1 may that´s causes also some changes.
Yes, my branch still uses 1.1.1 and the rootfiles usually do not like me, so I am glad Erik took care of these... :-)
May this causes the differences.
c) Erik re-enabled ARIA, SEED and MD2. See below.
Will disable then ARIA and MD2.
As far as I am aware, ARIA are some ciphers introduced more or less by South Korean entities (KISA), which disqualifies them for security purposes. MD2 to MD4 trace back to Chinese authorities.
This sounds a bit like racist cryptography - in fact I do not trust BSI/NIST either -, but they are very rarely used, and it is better to have a small but secure set of ciphers built-in.
Because of this, I suggest to disable ARIA and MDx.
Did that now.
d) The ciphersuites patch from Erik reverts Peter’s changes. I suspect that Peter disagrees with this :) Please comment.
have seen that i used an old cipher patch from Peter and haven´t recognized the update there. Took a fast look over it and it makes more sense with this patch, will adapt it to the actual one then.
@Erik: Are you referring to
https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=70d48c26...
? If yes, having this patch in OpenSSL would be great. Thank you.
Your welcome. Have acccidentially used another patch, have send now this one --> https://lists.ipfire.org/pipermail/development/2019-January/005226.html can you please check out if this is your mentioned one ?
e) Erik’s branch doesn’t have the changes for Apache that enable using the TLSv1.3 ciphersuites.
Since Peter worked already on this i left this one out.
I will send this patch as a standalone one within the next hours, hopefully it will make it into the same Core Update.
Regarding the ciphers:
I do not think that we are using MD2 or ARIA anywhere. I guess we can agree that we can disable this. They are old and not commonly used.
Please see above, will adapt it to the actual one then.
ACK.
About SEED: We cannot disable this because OpenVPN uses this. It is an option on the dropdown. I do not see any reason for removing it there because I am not aware that SEED might potentially be broken or dangerous to use. It doesn’t make any sense to use it because it is probably not very fast nor is it very commonly used. Are we okay with leaving it enabled for now? If not we must remove it from OpenVPN, too.
Disabling SEED should be announced via IPFire blog or somewhere else in my opinion since, as you mentioned it already, is SEED a part of OpenVPN and to disable it can break existing connections. It is also a 128 bit block cipher.
SEED is certainly not state-of-the-art cryptography anymore. For future releases (and IPFire 3.x), we should think about disabling it since there is little to no advantage compared with AES128.
But we can think about to drop 3DES in one of the upcoming updates. If we announce it via IPFire blog people out there which uses this are warned and are better prepared. May we can also introduce then also NCP for OpenVPN so possible affected poeple can switch easily via server configuration modification cause there is no need then to adapt also the client.ovpn´s. But as mentioned this might be better in a future release.
Tripe DES is weak, and should be avoided. Of course, there is some legacy stuff around which does not (reliably) support anything stronger. Possibly we can remove it some time before SEED-
Finally, have we spent any thought on dropping support for OpenSSL 1.0.2? We need to check and potentially re-ship anything that might be linked against it.
We spoke already about that this was the reason i dropped it but there is the need to check the openssl-compat depending addons and go for some intenser testings. May a spring clean for the lasting OpenSSL addon patches might also be an idea ?
Will wait now a little with the next commit may there comes some more...
Thanks, and best regards, Peter Müller
Best,
Erik