
OpenSSL Raccoon Attack (CVE-2020-1968) - yabones
https://www.openssl.org/news/secadv/20200909.txt
======
dan1234
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.

~~~
Aaronstotle
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?

~~~
asveikau
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.

~~~
mauvehaus
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.

~~~
asveikau
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)

~~~
mauvehaus
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.

------
DINKDINK
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](https://wikileaks.org/ciav7p1/cms/page_14587109.html)

~~~
1vuio0pswjnm7
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.

------
dependenttypes
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
secret reuse is not a timing attack. where do you see that?

~~~
dependenttypes
[https://raccoon-attack.com/](https://raccoon-attack.com/)

> Raccoon is a timing vulnerability ...

~~~
kryogen1c
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
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.

------
timeimp
TIL OpenSSL has premium customers!

~~~
mlindner
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.)

------
josephcsible
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.

~~~
ccktlmazeltov
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/](https://raccoon-attack.com/)

------
cordite
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)

~~~
edf13
Any reference info for this?

~~~
cordite
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](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...](https://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf)

------
rblatz
Does anyone know if LibreSSL is impacted by this?

------
hannob
The researcher's site is probably more informative: [https://raccoon-
attack.com/](https://raccoon-attack.com/)

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

~~~
comex
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.

