Hi all LTS contributors My question is whether removing default ciphers and introducing new options is acceptable so late in the release cyckle. My assumption is no, but let me know if you have another opinion. More details below.
If you have seen my email to ELTS then you may read faster. It is not identical as the Jessie version is significantly easier to port than the wheezy version. I think I need some advice. I have investigated the following issues for gnutls. CVE-2018-10844 CVE-2018-10845 CVE-2018-10846 I hope to spare you the time to read the full scientific paper on this matter. The overall problem is that by running some piece of software on the same CPU as the gnutls software is running it is possible to decrypt the plaintext by very smart techniques to deduce things from timing differences. OpenSSL has fully addressed this by always taking exactly the same time regardless of the input data but this was not properly done for gnutls. Upstream do in fact not even plan to do this as the problem only occur in the following cases: - CBC cipher - If Encrypt-then-MAC (RFC7366) is unsupported by the peer Instead upstream have done the following: 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) 2) Do a fix with SHA384 (for CVE-2018-10845) 3) Remove SHA256 and SHA384 from the default MAC ciphers (for CVE-2018-10844 and CVE-2018-10845) 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) 1: I do not think we can do 1 such late in the release cycle. I mean new options now would be rather pointless. I will mark CVE-2018-10846 as ignored due to this. Or do you think new options is ok also in Jessie? 2: 2 is easy to do but as SHA384 is not part of the default ciphers I see limited value. I do not think it is worth it on its own. 3: Should we remove SHA256 and SHA384 from the default MAC ciphers? It add some extra protection against this but it is a backwards compatibility problem and therefore may not be good from an availability perspective. I'm not sure how good it is to remove ciphers such late in the release cycle either. SHA256 and SHA384 is mostly deprecated now when AEAD cipher is available but still the peer could be an old version (for example AEAD was not supported in wheezy). 4: Will do this and I do not think the backporting work is that complicated. I will investigate a little more. I think I should do 2 and 4, but not 1 and 3. What do you think? If I do not hear any objections I'll do so. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology ---- / [email protected] Folkebogatan 26 \ | [email protected] 654 68 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
