4 ms·

@agl, it looks to me as if the timing differences they are measuring would be a complete wash in any realistic scenario? The original "good enough" timing fix

by moxie 14y ago

@agl, it looks to me as if the timing differences they are measuring would be a complete wash in any realistic scenario? The original "good enough" timing fix (in response to Vaudenay) was based on the assumption that an attacker would not realistically be able to measure the small remaining timing differences. This paper has demonstrated that it is possible to measure the small remaining timing differences, but it seems as if that requires: 1) The server not to be doing anything else or processing any other TLS sessions. 2) The attacker to be in a hyper-controlled networking environment with extremely low latency to the server and zero interference. Do you see this attack ever being possible in a practical situation?

agl 14y ago
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 :)
- moxie 14y ago
  Interesting. And beyond network position, do you think it's possible to measure these micro timing differences effectively against a server that experiences the type of load patterns Google's servers do? (And yeah, I have little faith in DTLS generally).
  - agl 14y ago
    Scheduling jitter on a loaded server is going to make this attack much harder for sure. If you have a sufficiently good position against the server, you can just delay all other traffic going into it but, except for that, such jitter may well make the number of connections needed very high - such that it takes weeks or months to pull off. That might well be infeasible, yes. However, many large sites have several serving locations, testing servers etc. If a location is drained of frontend traffic, or the testing server isn't being used all the time then you may well be able to find an idle server. After all, the attacker gets to choose where the traffic goes.
JoachimSchipper 14y ago
Assuming that jitter will hide the signal seems optimistic to me - "attacks always get better", and e.g. Figure 5 seems to suggest that just throwing more measurements at the problem is fairly effective. Of course, more measurements means that the attack takes longer, but note that the bruteforcing of the initial two bytes dominates the time the attack takes. If those bytes are partially or fully known, e.g. because you know some headers and can manipulate the length of certain fields, the attack becomes comparatively fast. Of course, you do need a victim which automatically reconnects or uses DTLS, both of which are somewhat questionable.

by moxie 14y ago

agl 14y ago

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 :)

moxie 14y ago
Interesting. And beyond network position, do you think it's possible to measure these micro timing differences effectively against a server that experiences the type of load patterns Google's servers do? (And yeah, I have little faith in DTLS generally).
- agl 14y ago
  Scheduling jitter on a loaded server is going to make this attack much harder for sure. If you have a sufficiently good position against the server, you can just delay all other traffic going into it but, except for that, such jitter may well make the number of connections needed very high - such that it takes weeks or months to pull off. That might well be infeasible, yes. However, many large sites have several serving locations, testing servers etc. If a location is drained of frontend traffic, or the testing server isn't being used all the time then you may well be able to find an idle server. After all, the attacker gets to choose where the traffic goes.

JoachimSchipper 14y ago

Assuming that jitter will hide the signal seems optimistic to me - "attacks always get better", and e.g. Figure 5 seems to suggest that just throwing more measurements at the problem is fairly effective. Of course, more measurements means that the attack takes longer, but note that the bruteforcing of the initial two bytes dominates the time the attack takes. If those bytes are partially or fully known, e.g. because you know some headers and can manipulate the length of certain fields, the attack becomes comparatively fast. Of course, you do need a victim which automatically reconnects or uses DTLS, both of which are somewhat questionable.