4 ms·

Yet another timing attack. I remember reading not too long ago that the OpenSSL developers will consider side channel attacks an issue only if someone provides

Yet another timing attack. I remember reading not too long ago that the OpenSSL developers will consider side channel attacks an issue only if someone provides a way of exploiting them rather than consider them as ticking time bombs. The easiest solution would be to only enable the X25519 and X448 key exchanges by default. (and in the future a post-quantum one)

kryogen1c 6y ago
secret reuse is not a timing attack. where do you see that?
- dependenttypes 6y ago
  https://raccoon-attack.com/ https://raccoon-attack.com/ > Raccoon is a timing vulnerability ...
  - kryogen1c 6y ago
    interesting. so the timing attack is just a method of key discovery, which only seems to matter if you are reusing your keys? which the paper claims up to 4.4% of major websites do. > So is this really only a timing vulnerability? > Sadly no. [...] You should probably check that you are not running a vulnerable configuration (see CVE-2020-5929) since this allows mounting a direct attack without complex timing measurements.
    - tialaramex 6y ago
      Not key discovery per se. The attacker does not obtain a long term key. Running this attack gets them the premaster secret (now the main secret presumably in RFC8446bis?) for one particular TLS session they're attacking. Assuming that session has meanwhile concluded and the attacker has recorded the ciphertext, they can now decrypt and read it. I think in principle if it's still in progress when they complete the attack they could try to MITM the session from a suitable on-path position. This might also impact resumption. Because you (the server) use the same DH private key repeatedly the attacker gets to do a bunch of separate connections which fail, but they can measure the timing of those connections and use that to try to figure out the main secret for some particular TLS session they witnessed talking to the same server when it used the same DH private key. If clients never do an affected DH key agreement the attacker doesn't have anything to work with. If the server picks random ephemeral DH keys the attacker doesn't have anything to work with. If the server uses a better DH scheme which is less vulnerable to a timing attack (for example not stripping zeroes or ECDH instead of conventional DH) this attack gets much harder to do, maybe you need to be very much closer to your target, e.g. running on the same physical hardware to measure the time differences. But using ephemeral keys makes this whole concern moot, and was also necessary to Forward Secrecy, so everybody should already have been doing that.

kryogen1c 6y ago

secret reuse is not a timing attack. where do you see that?

dependenttypes 6y ago
https://raccoon-attack.com/ https://raccoon-attack.com/ > Raccoon is a timing vulnerability ...
- kryogen1c 6y ago
  interesting. so the timing attack is just a method of key discovery, which only seems to matter if you are reusing your keys? which the paper claims up to 4.4% of major websites do. > So is this really only a timing vulnerability? > Sadly no. [...] You should probably check that you are not running a vulnerable configuration (see CVE-2020-5929) since this allows mounting a direct attack without complex timing measurements.
  - tialaramex 6y ago
    Not key discovery per se. The attacker does not obtain a long term key. Running this attack gets them the premaster secret (now the main secret presumably in RFC8446bis?) for one particular TLS session they're attacking. Assuming that session has meanwhile concluded and the attacker has recorded the ciphertext, they can now decrypt and read it. I think in principle if it's still in progress when they complete the attack they could try to MITM the session from a suitable on-path position. This might also impact resumption. Because you (the server) use the same DH private key repeatedly the attacker gets to do a bunch of separate connections which fail, but they can measure the timing of those connections and use that to try to figure out the main secret for some particular TLS session they witnessed talking to the same server when it used the same DH private key. If clients never do an affected DH key agreement the attacker doesn't have anything to work with. If the server picks random ephemeral DH keys the attacker doesn't have anything to work with. If the server uses a better DH scheme which is less vulnerable to a timing attack (for example not stripping zeroes or ECDH instead of conventional DH) this attack gets much harder to do, maybe you need to be very much closer to your target, e.g. running on the same physical hardware to measure the time differences. But using ephemeral keys makes this whole concern moot, and was also necessary to Forward Secrecy, so everybody should already have been doing that.