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