[Cryptography] "[CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections."

[Paul Wouters]

On Mon, 9 Dec 2019, Jerry Leichter wrote:

> This is a neat attack.  It's based partly on data outside the encryption in TCP - e.g., sequence numbers; partly on using the lengths of encrypted messages to turn a remote party into an oracle.  It works against all of TLS, WireGuard, and IKEv2/IPSEC - the details of the encryption itself are unimportant.

Note that I do not believe Linux IPsec using XFRM is affected, as it
does not depend on routing and when an IPsec policy is installed,
plaintext of that policy is dropped by the XFRM hooks, independent
of routing or rp_filter settings. I plan to do some more testing
over the next week or so.

> I've commented before on this list that when we talk about semantic security, but neglect message length leakage, we are opening ourselves up to attacks.

We do have Traffic Flow Confidentiality support (tfc=1500 to pad to
max MTU or tfc=200 if you just want to mask these smaller packets
without more overhead).

That is still not good enough for all cases though, which
is why IETF is looking at the following draft for IPsec:
https://www.ietf.org/archive/id/draft-hopps-ipsecme-iptfs-01.txt

introducion slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-ipsecme-ip-traffic-flow-security

> It's probably time, in most contexts, to stop worrying about saving bits in network messages.

There are still some cases where it matters though. Imagine you are
watching a movie. Do you really want the traffic from client to server
to use up as much bandwidth as server to client to hide the fact that
you are mostly downloading? That would put a tremendous additional load
on the servers that have to receive all this "padding traffic" only to
drop it. Or do you want an idle ssh session to keep generating traffic
as if you are there?

> BTW, if you're going to fill out a large block with random noise ... maybe an encryption mode natural to that block size makes sense.  Such things have been built in the past, but have fallen out of favor.

Just filling up the blocksize is what TFC does, and it does not work
well. It still doesn't really pad a stream to hide the number of
packets, only the size. ESP/IPsec allows dummy packets but no one
sends those. The new iptfs proposal can combine / cut packets and
get better perfomance compared to stupidly adding full bogus packets.

> What exactly to do in cases where every bit still *is* important - particularly for low power devices - is an interesting question.

Thoughts & Prayers for those :)

Paul