Gnutls investigation and request for advice for Jessie
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 ----
/ ola@inguza.com Folkebogatan 26 \
| opal@debian.org 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 /
---------------------------------------------------------------
Reply to: