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