OpenSSL Raccoon Attack (CVE-2020-1968) | Hacker News Reader

OpenSSL Raccoon Attack (CVE-2020-1968)

openssl.org

90 pointsyabones42 comments

FTA:

Why is the attack called "Raccoon"?

Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

Just in case anyone was trying to workout the meaning.

A neighbor who was raising chickens told me her first flock was murdered by the the neighborhood raccoons. They can be cute, but they can also trash up a garden and kill all your chickens. Maybe the attack is called raccoon for the potential?

They are sneaky and crafty killers for sure.

We used to have three pet turtles that we kept outside. They had a bunch of grass and dirt to roam around in and then at night we would put them in a plastic container.

One day we woke up and only had two turtles. A thief has struck! I thought it might have been an raccoon so I added a window screen as a top and weighed it down with two large bricks to make sure it stayed on.

The next morning I woke up to find the top knocked off and now we were down to zero turtles. The raccoon simply figured out how to knock the bricks off and get the two remaining turtle snacks inside.

Very crafty indeed.

This podcast did a good deep dive on raccoon craftiness and mitigating it with engineering: https://99percentinvisible.org/episode/raccoon-resistance/

You need surprisingly large bricks and blocks to keep raccoons from pulling them aside if they think there is food on the other side.

Yeah in the country it's normal to kill raccoons on sight, just like groundhogs, muskrats, coyotes, etc. They're certainly cute but they destroy too much to be left alive.

I'm not a vegan or food/animal activist or whatever... But something that stands out about this comment is that humans kill a lot more chickens, and at scale, than raccoons.

Yes, but if you’re raising chickens with the express purpose of eating them later or collecting their eggs to eat, a raccoon attack that kills your flock is kind of a setback.

I’m also going to note that folks with a backyard flock aren’t really participating in the industrial scale operations you’re bringing up.

Disclaimer: we have a seven bird flock, though it’ll be six soon if the cock (one pair of chicks was unseeded) doesn’t stop attacking people in the very near future.

Relevant comic: https://pbfcomics.com/comics/billy-the-bunny/

I'm not castigating anyone for this action, and I eat chicken and eggs myself, I'm merely pointing out the irony of the actions of the species. (In particular since we didn't specify particular raccoons, just that "raccoons" do it. #NotAllRaccoons)

I understood that, and I didn’t take your comment negatively. Sorry if I phrased mine such that you think I did.

My point is only that at the industrial scale, raccoons are a non-issue. The cages that keep the chickens in probably do a fine job keeping the raccoons out.

Those of us muddling along with our backyard flocks with the intention of not supporting the industrial raising of chickens are the ones dealing with random predators.

You’re right that at a species level it looks ironic. Looking at it at an individual level, I think, revolves the irony.

Pretty much all raccoons, given the chance. It's sort of like saying that not all dogs pee wherever they feel compelled to when outside. Naturally, they do, it's only when some outside force forces change on their nature that they don't. Same with raccoons. They kill and eat chickens (specifically the chickens owned by people) because they can, and they can even when people thing they've secured them from raccoons. #AssholeRaccoons :)

> ... humans kill a lot more chickens ... than raccoons.

If you've ever ate raccoon, you'll understand why.

...is this a joke? Chickens aren't (usually) pets

Yeah it kind of was meant to be taken in a joking manner. Glad you caught on to that.

I woke up one morning to find raccoons eating out of my dogs dish. They had broken in and trashed everything between that spot and the dogs food.

The name seems fitting to me. They aren't just cute animals.

Yep, raccoons can be mean. There was a raccoon in my neighborhood a few years back that was eating out of the cat dishes and killing the cat if it was anywhere near. They are smart and mean.

Trash pandas

The most upvoted comment, and the comment with the most amount of responses, is this one, which doesn't provide any insight to the story posted.

Racoon aka "trash bandits", things that steal from your trash. In a physical security context this would be literal dumpster diving. In an electronic security context this is likely reference to a back channel involving how a system deletes data, or leveraging data that was thought to have no value.

raccoon's are not cute animals. they kept tearing large holes in my garage roof to get in. I trapped a few, then trimmed all the trees that allowed them to climb. Once I did that, they moved to my neighbors house next door and tore a huge hole in the roof. nothing cute about a pest.

It doesn't help that "racoon" is an IKE daemon that uses OpenSSL.

"Racoon" has had its own security issues: https://nvd.nist.gov/vuln/detail/CVE-2012-3727

yelling "kill the racoon" across the office used to get me some funny looks

The CIA doesn't rely on TLS, do you?

"Development Tradecraft DOs and DON'Ts

[...]

(U) Networking

Directive Rationale

[...]

DO NOT solely rely on SSL/TLS to secure data in transit. Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol."

https://wikileaks.org/ciav7p1/cms/page_14587109.html

In their civilian lives I would bet most if not all government employees, including CIA, do rely on all the same scatterbrained work foisted upon us by tech company "engineers". SSL/TLS, not to mention cookies, came from Netscape, a.k.a., Netscum.

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)

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

https://raccoon-attack.com/

> Raccoon is a timing vulnerability ...

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.

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.

TIL OpenSSL has premium customers!

OpenSSL is de-facto standard for most everything. (LibreSSL and others have had development stall on OpenSSL's old API and aren't getting the new upcoming APIs.)

My reading of this is that it only affects old, weak cipher suites that don't support forward secrecy, so only hosts that have an insecure configuration anyway are affected by this.

Note that some implementations re-use ephemeral keys on DHE, this was one of the finding of LOGJAM, and I'm not sure if this has been fixed in every TLS libraries.

https://raccoon-attack.com/

Don't some IoT devices use static parameters?

Like while claiming an ephemeral ECDH key, it is actually only generated once when the device is provisioned? (Or worse, the same on every device of that series)

Any reference info for this?

Can't seem to find the original source I read that on.

But here's something that mentions semi-static 0 round trip session setup

https://www.cs.virginia.edu/dwu4/papers/PrivateIoT.pdf

as well as what goes wrong when you do reuse things

https://www.math.uwaterloo.ca/~ajmeneze/publications/ephemer...

Does anyone know if LibreSSL is impacted by this?

The researcher's site is probably more informative: https://raccoon-attack.com/

tl;dr cryptographically it's a neat attack, but practical risk is very small.

I like how this follows the trend of slick vulnerability websites with a name, logo, and layman’s explanation… but without the overhyped prose found in most of those websites. Instead it’s upfront about this being a low severity vulnerability.

> neat attack, but practical risk is very small

that's what Intel said!

sorry. i will see myself out...

Reply on news.ycombinator.com