0

Are there any mechanisms in the TLS 1.2 protocol (not implementation) against timing attacks? For example, that the handshake response time should be padded to X milliseconds? Or should I implement such mechanisms manually ?

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Bleeding Alice
  • 29
  • 4
  • If I recall correctly, the way to mitigate side channel timing for padding oracle attacks is to generate a dummy key and use that if the padding is invalid, so the decryption will fail in a later stage. – J.A.K. Aug 08 '17 at 12:22

1 Answers1

2

Yes. See the RFC for TLS 1.2 (RFC5246) and note the MUST.

   Implementation note: Canvel et al. [CBCTIME] have demonstrated a
   timing attack on CBC padding based on the time required to compute
   the MAC.  In order to defend against this attack, implementations
   MUST ensure that record processing time is essentially the same
   whether or not the padding is correct.  In general, the best way to
   do this is to compute the MAC even if the padding is incorrect, and
   only then reject the packet.  For instance, if the pad appears to be
   incorrect, the implementation might assume a zero-length pad and then
   compute the MAC.  This leaves a small timing channel, since MAC
   performance depends to some extent on the size of the data fragment,
   but it is not believed to be large enough to be exploitable, due to
   the large block size of existing MACs and the small size of the
   timing signal.
Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • I meant time "padding", for example generation of keys 3 took 1.5 seconds, 1.2 and 1.6, so code will sleep for 0.5 seconds in first case and 0.8 and 0.4 respectively, before sending key so it will appear to mitm that all keys took 2 seconds to generate each key. is there such thing ? – Bleeding Alice Aug 08 '17 at 16:44
  • When doing cryptography, I agree yes you generally should be cognizant of doing constant time operations when possible. That said, when generating an asymmetric key it should be constant time. (Generating primes for RSA is another matter; but that isn't done live. For DH key exchange some information may be gathered through timing attacks, but if the server and client parameters are ephemeral it won't be enough for a sophisticated attack). – dr jimbob Aug 08 '17 at 21:59