3 ms·

>> This fact means that an attacker can determine the first correct character of the tag by submitting requests to a signed URL with a different first character

by jebblue 14y ago

>> This fact means that an attacker can determine the first correct character of the tag by submitting requests to a signed URL with a different first character in the tag each time, and stopping when the request takes a little longer than usual. After guessing the first character they can move onto the second, and so on until they’ve guessed the whole correct tag. Wouldn't this attack be eliminated by using iptables rate limiting to reduce the attack window of opportunity?

tptacek 14y ago
Wouldn't this attack be better eliminated by fixing the timing leak that is potentially allowing people to guess valid MACs on packets? The reality is that you probably can dick around with things in your deployment and your app to make timing attacks prohibitively expensive/annoying; if you understand that you're not eliminating the timing leak, but rather masking it, you can take advantage of the additional measurements required to unmask the leak to give your MAC enough of a buffer to last for its whole useful lifetime. But when you do this, you're really playing on the razor's edge of what we currently know about side channel attacks on crypto, and you're probably going to end up putting more effort into your workaround than you would in just fixing the underlying bug.
- CamperBob2 14y ago
  I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.
  - tptacek 14y ago
    The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.
    - jebblue 14y ago
      Are you saying ip rate limiting is a bad idea?
      - tptacek 14y ago
        I'm saying that trying to detect someone launching a timing attack on your application and then blocking their specific IP is a bad idea. As to the rest of it: just fix the damn timing leak.
        jebblue 14y ago
        I'm talking about iptables rate limiting (on Linux and I assume other OS's firewalls can implement this). Fixing bugs in isolated code is part of the scope we face but preventing the business and its customers from suffering due to a bug is also part of we get paid for. If you are still in school or work in the scientific area then perhaps you have not come across rate limiting? Fixing the leak today is admirable and difficult but challenging as the many comments have shown. The problem is that at any time regressions can and will happen. There was a problem on Ubuntu with SSH a couple of years ago, SSH had been fine then someone made a change (I don't recall the details) that went unnoticed for I think it was 2 or 3 years. That change made SSH vulnerable to I believe it was timing attacks and it could have been easily prevented. This was in SSH. SSH.
        tptacek 14y ago
        No, the change you're thinking of is when Debian's maintainers managed to comment out the "secure" part of it's cryptographic secure random number generator, thus ensuring that SSH would only generate keys from a trivially small range of possible values. That change had nothing to do with the fundamental difficulty of generating random numbers. The fix for not leaking timing from your comparison is trivial. Either double-hash, or use a timing-independent comparison function like the accumulator XOR function upthread. It does nobody any favors to spread drama and FUD over what is in fact a simple and easily fixable problem.
    - 14y ago
  - rlpb 14y ago
    Real attackers don't use the same IP. They have access to millions.
    - CamperBob2 14y ago
      Botnets haven't historically used timing attacks. Might be an interesting research problem, though...
jcoglan 14y ago
Possibly, although it depends on the lifetime of the link and the size of the tag (e.g. SHA-1 is 40 chars, each case requires mean of 8 guesses, so whole thing only requires 320 requests). Better to have resistance as baked into your crypto as you can, rather than relying on a firewall further up the stack. If the data itself is resilient, no implementation will be able to defeat it efficiently.

by jebblue 14y ago

tptacek 14y ago

Wouldn't this attack be better eliminated by fixing the timing leak that is potentially allowing people to guess valid MACs on packets? The reality is that you probably can dick around with things in your deployment and your app to make timing attacks prohibitively expensive/annoying; if you understand that you're not eliminating the timing leak, but rather masking it, you can take advantage of the additional measurements required to unmask the leak to give your MAC enough of a buffer to last for its whole useful lifetime. But when you do this, you're really playing on the razor's edge of what we currently know about side channel attacks on crypto, and you're probably going to end up putting more effort into your workaround than you would in just fixing the underlying bug.

CamperBob2 14y ago
I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.
- tptacek 14y ago
  The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.
  - jebblue 14y ago
    Are you saying ip rate limiting is a bad idea?
    - tptacek 14y ago
      I'm saying that trying to detect someone launching a timing attack on your application and then blocking their specific IP is a bad idea. As to the rest of it: just fix the damn timing leak.
      - jebblue 14y ago
        I'm talking about iptables rate limiting (on Linux and I assume other OS's firewalls can implement this). Fixing bugs in isolated code is part of the scope we face but preventing the business and its customers from suffering due to a bug is also part of we get paid for. If you are still in school or work in the scientific area then perhaps you have not come across rate limiting? Fixing the leak today is admirable and difficult but challenging as the many comments have shown. The problem is that at any time regressions can and will happen. There was a problem on Ubuntu with SSH a couple of years ago, SSH had been fine then someone made a change (I don't recall the details) that went unnoticed for I think it was 2 or 3 years. That change made SSH vulnerable to I believe it was timing attacks and it could have been easily prevented. This was in SSH. SSH.
        tptacek 14y ago
        No, the change you're thinking of is when Debian's maintainers managed to comment out the "secure" part of it's cryptographic secure random number generator, thus ensuring that SSH would only generate keys from a trivially small range of possible values. That change had nothing to do with the fundamental difficulty of generating random numbers. The fix for not leaking timing from your comparison is trivial. Either double-hash, or use a timing-independent comparison function like the accumulator XOR function upthread. It does nobody any favors to spread drama and FUD over what is in fact a simple and easily fixable problem.
  - 14y ago
- rlpb 14y ago
  Real attackers don't use the same IP. They have access to millions.
  - CamperBob2 14y ago
    Botnets haven't historically used timing attacks. Might be an interesting research problem, though...

jcoglan 14y ago

Possibly, although it depends on the lifetime of the link and the size of the tag (e.g. SHA-1 is 40 chars, each case requires mean of 8 guesses, so whole thing only requires 320 requests). Better to have resistance as baked into your crypto as you can, rather than relying on a firewall further up the stack. If the data itself is resilient, no implementation will be able to defeat it efficiently.