Against DTLS it appears to practical, both because the connection isn't destroyed and because the difference can be amplified by the researcher's Heartbeat tric

Against DTLS it appears to practical, both because the connection isn't destroyed and because the difference can be amplified by the researcher's Heartbeat trick from http://www.isg.rhul.ac.uk/~kp/dtls.pdf http://www.isg.rhul.ac.uk/~kp/dtls.pdf. Against TLS it's tougher. The paper is suggesting a difference of ~10000 cycles, which may be ~5us. So, yes, you need to have a good connection to the server to be able to measure that difference, but that's not unthinkable to me. I know that you could get such a connection to a Google server if you were willing to pay some money to get a machine hosted in the right place. But it also appears that it's fairly easy to get a process instantiated on the same EC2 host as a target application. Or maybe your server is running on a small ARM device and so the difference is much larger. Don't get me wrong - this is a trivial issue compared to, say, the Java vulnerabilities that we've seen recently. But it's huge compared to the level of security that plain TLS should be providing. Saying that it's secure as long as you don't allow the attacker to be close by, or you don't run it on a slow machine isn't good enough for me. But I admit that it's unlikely to anyone will ever actually perform this attack in anger. Although I would have said the same about MD5 collisions at the beginning of 2012 :)