Re: [PATCH] OpenSSL_update: Update to version 1.1.1a

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 5361 bytes --]

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(a)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=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
>