From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: [PATCH] OpenSSL_update: Update to version 1.1.1a Date: Tue, 15 Jan 2019 15:48:06 +0100 Message-ID: <0e076727bb08db77e71af47fc3244e30a5bf8d63.camel@ipfire.org> In-Reply-To: <8cdbaef3-8573-176e-dee3-2c1b52c09edf@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2258103890765701150==" List-Id: --===============2258103890765701150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Peter, Am Montag, den 14.01.2019, 19:03 +0100 schrieb Peter M=C3=BCller: > Hello Erik, hello Michael, >=20 > sorry for replying late on this. >=20 > > > Hey, > > >=20 > > > Okay, I had a look at the differences between your two branches. > > > There are a few: > > >=20 > > > a) Update to openssl 1.1.1a. That=E2=80=99s fine. > > > b) Loads of rootfile changes. I think that is not because of > > > Peter > > > not updating it in his branch. Also fine. > >=20 > > It is also 1.1.1a and as far as i can see Peter used 1.1.1 may > > that=C2=B4s > > causes also some changes. >=20 > 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. > >=20 > > > c) Erik re-enabled ARIA, SEED and MD2. See below. > >=20 > > Will disable then ARIA and MD2. >=20 > 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. >=20 > 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. >=20 > Because of this, I suggest to disable ARIA and MDx. Did that now. > >=20 > > > d) The ciphersuites patch from Erik reverts Peter=E2=80=99s changes. I > > > suspect that Peter disagrees with this :) Please comment. > >=20 > > have seen that i used an old cipher patch from Peter and haven=C2=B4t > > 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. >=20 > @Erik: Are you referring to >=20 https://git.ipfire.org/?p=3Dpeople/pmueller/ipfire-2.x.git;a=3Dcommit;h=3D70d= 48c264c1fb1987b52d190fecf870d00ceb148 > ? > 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 ? > >=20 > > > e) Erik=E2=80=99s branch doesn=E2=80=99t have the changes for Apache th= at enable > > > using the TLSv1.3 ciphersuites. > >=20 > > Since Peter worked already on this i left this one out. >=20 > I will send this patch as a standalone one within the next hours, > hopefully it will make it into the same Core Update. > >=20 > > >=20 > > > Regarding the ciphers: > > >=20 > > > 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. > >=20 > > Please see above, will adapt it to the actual one then. >=20 > ACK. > >=20 > > >=20 > > > 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=E2=80=99t 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. > >=20 > > 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. >=20 > 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=C2=B4s. But as mentioned this might be better in a > > future > > release. >=20 > 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- > >=20 > > >=20 > > > 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. > >=20 > > 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 ? > >=20 > > Will wait now a little with the next commit may there comes some > > more... >=20 > Thanks, and best regards, > Peter M=C3=BCller Best, Erik --===============2258103890765701150==--