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

[ummeegge <ummeegge@ipfire.org>]

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

Hi,

Am Freitag, den 18.01.2019, 15:09 +0000 schrieb Michael Tremer:
> Hey,
> 
> It is merged. It built (on ARM :D). Who wants to give it a try?
Great news :D . Michael, please don´t forget the del_rand patch -->
https://patchwork.ipfire.org/patch/2023/ since IPSec needs this with
the new OpenSSL lib. I need also to set the delete commands for the
.rnd files then in update.sh. Is Core 128 already open ?

> 
>   
> https://nightly.ipfire.org/next/2019-01-17%2019:24:46%20+0000-93d516bd/

Even i use the old patch i am a happy tester with 64 bit since one
month + :-).

The difference between old and new patch (from Peter) are not that vast
and they looks like this:

--- OpenSSL-1.1.1a_old_patch	2019-01-13 18:15:33.316651666 +0100
+++ OpenSSL-1.1.1a-new_patch	2019-01-13 18:16:22.008650232 +0100
@@ -1,31 +1,23 @@
-TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
 TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
+TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
 TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
-ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
 ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
-ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
-ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
+ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
 ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
-ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
-ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128) Mac=AEAD
 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
 ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(256) Mac=SHA384
 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
 ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(128) Mac=SHA256
-ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
+ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
 ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=Camellia(256) Mac=SHA384
 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
 ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=Camellia(128) Mac=SHA256
-DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
 DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
-DHE-RSA-AES256-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(256) Mac=AEAD
-DHE-RSA-AES256-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(256) Mac=AEAD
+DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
-DHE-RSA-AES128-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(128) Mac=AEAD
-DHE-RSA-AES128-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(128) Mac=AEAD
 DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
 DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA256
 DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
@@ -37,14 +29,9 @@
 DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
 DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
-DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
 AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
-AES256-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(256) Mac=AEAD
-AES256-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(256) Mac=AEAD
 AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
-AES128-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(128) Mac=AEAD
-AES128-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(128) Mac=AEAD
 AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
 CAMELLIA256-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA256
 AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256 

So mostly changes are causing by the disabled AES-CCM.

Best,

Erik


> 
> -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
> > 
> 
>