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

Jerry Leichter leichter at lrw.com
Mon Dec 9 12:24:41 EST 2019

"We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS,
iOS, and Android which allows a malicious access point, or an adjacent
user, to determine if a connected user is using a VPN, make positive
inferences about the websites they are visiting, and determine the
correct sequence and acknowledgement numbers in use, allowing the bad
actor to inject data into the TCP stream. This provides everything that
is needed for an attacker to hijack active connections inside the VPN
tunnel."  https://seclists.org/oss-sec/2019/q4/122

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.

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.  One basic feature of these attacks is that while the cryptography remains, in some sense, completely secure, its interaction with particular protocols makes the combination unsafe.  (Classic example:  Vocoded/compressed speech encrypted with a packet-length-revealing encryption mode allows pretty accurate guesses about the underlying phonemes simply based on the length of successive packets.)  Not only is it hard to make security assertions about the composition of security mechanisms - it can be hard to make such assertions about the composition of security mechanisms with apparently non-security-sensitive layers.

It's probably time, in most contexts, to stop worrying about saving bits in network messages.  Most networks today are fast enough and have enough capacity that rounding everything up to 1K or 2K packets won't have any noticeable effect.  These numbers are *total guesses*.  It would be useful to understand the actual data leakage rate for different packet sizes for different data sources - e.g., digital audio, video, Web sites.  We thought that modern cryptographic techniques would get us away from the old world where the safety was in the crypto, regardless of any characteristics of the underlying data.  Well ... it appears to be time to admit that's not true.

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.

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

                                                        -- Jerry

More information about the cryptography mailing list