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 d83a5f0

[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 (d83a5f0) 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.