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