1. 6
  1.  

  2. 5

    Quick recap, in order for this attack to be feasible the following conditions must be met:

    • A connection uses a 64-bit block size cipher (Blowfish, 3DES)
      • This requires both the browser and web server to choose these ciphers
      • Or a VPN client to choose these ciphers from a supported server, apparently OpenVPN defaults to this though (yikes)
    • The connection must not rekey after a LOT of traffic, maintaining the same connection for >30 hours (to recover a 16 byte plaintext for example)
    • The attacker must capture 2^32 blocks of ciphertext to recover those 16 bytes. With HTTPS traffic that’s over 700 GB during which the same TLS connection must be used

    Considering that most servers (Apache, Nginx) rekey the TLS session after a short time, and considering that only 0.6% of the Alexa Top 100K actually negotiate a vulnerable cipher with a modern version of Firefox, I’d say don’t concern yourself with the practicality of this attack.

    This won’t be feasible in a coffee shop scenario.

    Even more onerous is how the attacker must cause the victim browser to generate that much traffic in one session. In this case you need access to the victim browser, either through having the victim sit on a compromised website over a couple days, or by compromising their machine directly. At which point one would think you’d be busy with other post exploitation tasks :)

    All that said, this attack is cool and another reminder of vulnerabilities moving from historically theoretical to currently practical. Makes you wonder if NSA & Co. have had this attack developed in the past. I for one would be disappointed if they didn’t!

    1. 1

      Makes you wonder if NSA & Co. have had this attack developed in the past. I for one would be disappointed if they didn’t!

      My bet: They had thought about it, and then ran the calculations of deploying it as you did. I’d wager they figured it was unfeasible and decided to not further develop it.