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 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=70d48c264c1fb1987b52d190fecf870d00ceb148 >> ? >> 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 >