Hi Sorry for the late reply. We can consider updating to the 3.3.30, but I suggest you first check how easy it is to backport it.
Best regards // Ola On Mon, 1 Oct 2018 at 20:07, Antoine Beaupré <anar...@orangeseeds.org> wrote: > I contacted three parties to try and settle this: > > * the original authors of the paper > * the GnuTLS upstream > * the RedHat security team > > The original authors "still stand behind what is written in the paper" > and believe only a constant-time implementation is the proper fix. They > point to BoringSSL, OpenSSL and WolfSSL as properly implementing this > now, but acknowledge such a fix might impose API breakage, at least in > the low-level hash functions. > > Upstream GnuTLS replied the following: > > https://gitlab.com/gnutls/gnutls/issues/456#note_105621260 > > > The solution applied in gnutls 3.3.30 is a mitigation against the > > attack published by the authors. As such these CVEs are > > addressed. What the authors claim is that these mitigations may not be > > sufficient to address a future attack similar in principle to that > > one; they indeed have a point but I guess that's with all attacks one > > way or another. So backporting these mitigations (or preferably by > > updating to 3.3.30) is sufficient to address that vulnerability. A > > more general solution is tracked at #503. > > In other words: that's the solution we got now, use it or wait (possibly > for months) for a longer term fix. > > RedHat security hasn't answered yet, but GnuTLS upstream also replied > there: > > https://bugzilla.redhat.com/show_bug.cgi?id=1582571#c12 > > > That is, the existing counter-measures present were improved to > > protect against this attack. Indeed the paper authors mention that > > this may not be sufficient to counter other future attacks, and they > > are correct in that. How critical however would be such future > > attacks? For that one must note what is the actual impact of this > > attack. This type of attacks does only affect the legacy HMAC-based > > ciphersuites and only when the gnutls peer does not implement the > > encrypt-then-mac construction. That's why the majority of HMAC > > ciphersuites are now disabled by default keeping HMAC-SHA1 for > > compatibility only. > > In other words: yes, an attack is still possible, but it's not critical > because the impact is smaller. > > I agree with this analysis: the fix is imperfect, but it's all we > got. So I'll be looking at backporting this shortly. > > Or should we update jessie to 3.3.30 as recommended upstream? There > *were* API/ABI changes since 3.3.8, but only new symbols were added - no > signatures were changed or removed... > > A. > -- > Music gives a soul to the universe, wings to the mind, flight to the > imagination and life to everything > - Plato > -- --- Inguza Technology AB --- MSc in Information Technology ---- / o...@inguza.com Folkebogatan 26 \ | o...@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 / ---------------------------------------------------------------
