First off, thanks to the authors for making it clear that this is a difficult attack vector to exploit. I'm tired of sites like these that make it seem like it's the end of the world.
As this is a timing based attack, I wonder what the feasibility would be in a real-world network environment. From a brief skim of the paper, it looks like they were getting a false positive rate of 10% between two VMs on a Gigabit connection. I wonder how quickly that would increase if the servers were in different buildings / cities / continents.
Real world webservers running tons of concurrent requests have a very variable processing times (if you get below 5ms you are very good!) purely due to queued up work and context switches.
The amount of extra time needed to sift through network jitter isn't really that huge. It's far less than what people imagine even with basic statistical techniques.
Maybe. My point was that even even network jitter won’t be important, since software processing latencies are much higher. If a server handles another request before your handshake that’s thousands more instructions which obfuscate the result. If it does another TLS handshake before it’s thread might be blocked for several ms before it gets to processing the next thing. That’s all orders of magnitudes higher than any „this tool longer because some bits are different“ measurements
Additionally, there's another factor of raccoons that seems serendipitously applicable here. Raccoons are cute, yes, but they are also potentially dangerous and can cause damage or injury if ignored or dealt with incorrectly. If raccoons are present, it's worth it to pay some attention to make sure they aren't the cause or symptom of a larger problem.
Racoons are also very clever and persistent. I have had several run in with them over the years, don't let their "cuteness" fool you, they are ruthless and very devious.
From what I've seen, raccoons don't eat the chickens. They attack at night while the chickens are roosting and just decapitate them. Then they just leave the bodies untouched.
>Prominent scrotums are an integral part of tanuki folklore, and they are shown and referred to throughout the film, and also used frequently in their shape-shifting. This remains unchanged in the DVD release, though the English dub (but not the subtitles) refers to them as "raccoon pouches". Also, in the English dub and subtitles, the animals are never referred to as "raccoon dogs", which is the more accurate English name for the tanuki, instead they are incorrectly referred to as just "raccoons".
>The Tanooki Suit, or Tanooki Costume, is a fairly uncommon item found in Super Mario Bros. 3 and its subsequent remakes in Super Mario All-Stars and Super Mario Advance 4: Super Mario Bros. 3. It is based on tanukis, Japanese creatures who, according to mythology, can use leaves to shape-shift and cause chaos. The suit is an add-on to the Raccoon form that allows Mario or Luigi to temporarily turn into a statue and become immune to enemies and obstacles, in addition to flying and attacking enemies with tail swipes.
>According to Shigeru Miyamoto in the Super Mario Bros. 3 entry of the 25th Anniversary Super Mario History Booklet, he was aware that most players outside Japan would be overall confused with the Tanooki Suit and the transformation, but he left it in because he was too excited to remove it.
I agree that it was amazing and super cool! Rather it's just a comment on the relevance of the name to the actual attack, contorted to the purpose of a cool acronym.
Just to stoke some fires, I think poodle is also in that bag.
The comment isn't wrong about the name, I'm just compelled to say how awesome DROWN is every time it's mentioned anywhere. It's really spectacular work.
I think more projects should have cute mascots like this. Really like the "Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)" line.
Is the top comment and most of the responses going to be about the "raccoon" in the name of the attack, or the first paragraph of the page (it's not really exploitable), and not on the actual content again? Only time will tell.
"BearSSL and BoringSSL are not affected because they do not support DH(E) cipher suites. GnuTLS, Wolfssl, Botan, Mbed TLS and s2n do not support static DH cipher suites. Their DHE cipher suites never reuse ephemeral keys."
The vulnerability is really hard to exploit and relies on very precise timing measurements and on a specific server configuration to be exploitable.
It's interesting that they emphasize this is a really hard problem to solve, and for 99% of use cases this really isn't an issue to worry about.
But if you work in national security or are sensitive to security threats from nation states, this would certainly be an absolutely critical item to address or understand.
National Security and nation states would absolutely use this as a target where billions of dollars or thousands of lives could be at stake.
I don't know why you assume this. It's true that state-level adversaries can undertake more expensive attacks, but it doesn't follow that all expensive attacks are useful. Here, the effort required to exploit this would probably buy so many Firefox and Juniper remotes, and offer so little payoff, that it's hard to imagine it ever being exploited.
Sometimes vulnerabilities are just valuable to science. The work that follows up from this could be valuable to CNE and SIGINT!
Almost everybody assigned the task of implementing this stuff (SSLv3, last century) didn't understand it, even for the old finite field DH where it's just about within the grasp of someone with high school mathematics if you insisted on having it explained before you implement. So it's just magic, and once one person does it wrong everybody else must do it wrong or lose interoperability.
And the "wrong" DH implementation works fine, except that it introduces a slightly larger side channel.
You mention a padding oracle, this isn't a padding oracle. It's an oracle because it provides the attacker with answers to questions they can't answer themselves, but there isn't any padding involved here.
And it's a pretty weak oracle, the insight you gain from asking the oracle questions is about a single pre-master secret, not the underlying DH private key or any long term authentication key.
There is a trend with TLS attacks and fancy websites and names. :)
Is there a reason for that? Not really following the scene, the same group of people finding these issues over the years and hence marketing is similar?
If this is a timing sidechannel, why is it considered s protocol vulnerability and not an implementation vulnerability? Could it be mitigated by using a time-constant implementation of the KDF?
nobody cares about an AES constant time implementation, but any specification about MACs and signing algorithms will specifically mention that you need to have constant-time operations
None of you have dealt with raccoons before. They are vicious. They are persistent. They will mess you up. You do not want to square up with a raccoon without the intent to walk away without causing massive harm. Because when a raccoon comes for you. It comes for keeps.
As this is a timing based attack, I wonder what the feasibility would be in a real-world network environment. From a brief skim of the paper, it looks like they were getting a false positive rate of 10% between two VMs on a Gigabit connection. I wonder how quickly that would increase if the servers were in different buildings / cities / continents.