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@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=70d48c26...
? 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