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
