Add counter-measure to cache-based Lucky 13 The basis for the Lucky 13 family of attacks is for an attacker to be able to distinguish between (long) valid TLS-CBC padding and invalid TLS-CBC padding. Since our code sets padlen = 0 for invalid padding, the length of the input to the HMAC function, and the location where we read the MAC, give information about that. A local attacker could gain information about that by observing via a cache attack whether the bytes at the end of the record (at the location of would-be padding) have been read during MAC verification (computation + comparison). Let's make sure they're always read.

diff --git a/ChangeLog b/ChangeLog
index 0acb2c6..e6a5368 100644
--- a/ChangeLog
+++ b/ChangeLog

@@ -23,6 +23,14 @@
      a cache attack targetting an internal MD/SHA buffer. Connections using
      GCM or CCM instead of CBC or using Encrypt-then-Mac (RFC 7366) were not
      affected. Found by Kenny Paterson, Eyal Ronen and Adi Shamir.
+   * Add a counter-measure against a vulnerability in TLS ciphersuites based
+     on CBC, in (D)TLS 1.0 to 1.2, that allowed a local attacker, able to
+     execute code on the local machine as well as manipulate network packets,
+     to partially recover the plaintext of messages under some conditions (see
+     previous entry) by using a cache attack targeting the SSL input record
+     buffer. Connections using GCM or CCM instead of CBC or using
+     Encrypt-then-Mac (RFC 7366) were not affected. Found by Kenny Paterson,
+     Eyal Ronen and Adi Shamir.
 
 API Changes
    * Extend the platform module with a util component that contains