padding oracle attack and lucky thirteen

[hannesm]

problem: server leaks information if distinguishing between padding failure and mac failure

solution: don't ever send a padding failure alert

references

• bleichenbachers original paper http://link.springer.com/chapter/10.1007%2FBFb0055716?LI=true
• http://en.wikipedia.org/wiki/Padding_oracle_attack
• https://en.wikipedia.org/wiki/Lucky_Thirteen_attack
• http://www.isg.rhul.ac.uk/tls/Lucky13.html
• lucky thirteen research paper http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

[hannesm]

to be slightly more precise, don't bail in crypto.ml:123 when padding is incorrect, but use a random premastersecret for further communication [which obviously will fail once enc/dec is used]. otherwise bleichenbacher's attack can be done.

[hannesm]

here's a first defense measure against bleichenbacher d83a5f02f5e89aa10595c5ce0a6157c4e9914907

[hannesm]

CBC decoding must be constant time... which is rather intricate, https://www.imperialviolet.org/2013/02/04/luckythirteen.html describes the countermeasures introduced by OpenSSL (and I believe we've to do it in a similar way)! the memory access pattern for invalid and valid padded data needs to be exactly the same...

[hannesm]

some further thoughts on this: we need to get rid of data-dependent branches and allocation -- or runs of the garbage collector. maybe we need to take the GC lock (do a gc minor before) and turn interrupts off to get rid of all the timing issues imposed by high-level runtime.

[hannesm]

see also discussion in #49

[eras]

This kind of attack has been found to be relevant once again in other implementations: https://robotattack.org/

[hannesm]

@eras uhm, how is "robot" related to "lucky13"? IMHO "this kind of attack" isn't true.

AFAIU "robot" attack, this behaviour was fixed on 12th March 2014 (https://github.com/mirleft/ocaml-tls/commit/d83a5f02f5e89aa10595c5ce0a6157c4e9914907) which was before the initial release (0.1.0) of OCaml-TLS. The current code is still in the same shape https://github.com/mirleft/ocaml-tls/blob/0.8.0/lib/handshake_server.ml#L94 . Please take a look into #20 and #23 where we discussed and fixed this Bleichenbacher attack (again thanks to @gram for his code review back then).

This was also mentioned in our blog post announcing this library - https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitigation#Attacks-on-TLS and look for "Bleichenbacher". Please let me know if you've more questions about this (or a working attack). I'd prefer to discuss each attack in a separate issue.