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

[Jon Callas]

> On Dec 10, 2019, at 1:44 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> 
> 
> I'd argue that even for low power devices, you don't need to save every
> bit.  Adding a few extra bytes isn't a problem, and if you're properly
> encrypting packet lengths, you can just append noise, or add random
> noise packets that won't be decrypted to save the energy of encrypting
> the padding.

If there are two lengths, a packet length and a data length (note that looks a lot like a slice in Rust and good old-fashioned string descriptors) You can easily do the same thing, decrypt the head of the slice and then not decrypt the unused data. And of course, you need to at least clear the unused memory before encrypting.

> 
> The ideal protocol will look like random noise from start to finish.
> There is no banner announcing the service, there are no unencrypted
> packets.

Mayyyyyybeeee... In general, yes, but Gershwin's law ("It ain't necessarily so") applies. Note also, that this puts demands on your partner. If there are no hints in your initial handshake, then the decoder has more work to do. It also enables an adversary to play games that they couldn't otherwise play. Nothing here is a show stopper, merely that that goal introduces new considerations. One might ask which is better and not really have a decent answer.

> But doing simple metering, where 100 times a second you release the
> packets, or some other fixed interval can be a useful and simple
> mitigation attack.

Again, maybe.

A decade ago, Ricardo Bettati and others did traffic analysis on VPNs. They started by making a constant-traffic system and then they discovered they could attack their own system and others. They used timing -- just simply track each packet and the time it came in -- and discovered that it was often *easier* to peer into a constant-traffic network. They used their technique to be able to decompose a VPN flow. They could tell what portions of the VPN were web traffic, media traffic, and others. It was often easier to do the separation on a constant-traffic network.

The way Bettati described it to me, think of yourself sitting on a hill looking at a bunch of boxcars coming out of a warehouse. Some cars are full, some are empty. Even though they're coming out at a constant rate, it's still not an invariant. Inside the warehouse, you're sending out empty cars and then dropping in the full cars. Some work has to be done and it is very hard to do that in a way that has no side-channels. For example, you might notice that the inter-car distance between full cars is different than the distance between empty cars. The distances might glitch when you switch types and you can detect that glitch. They found all of those happening and could use it to categorize the traffic.

In short, constant-traffic networks give you a metronome, and if that ticking goes a bit rubato on you, that's a signal that a passive adversary can use. Perhaps even more counterintuitively, the better your clock the easier it is to tell when it wavers.

> 
> Simply adding a random delay is not enough in some cases, as using
> averaging can reduce any noise introduced.

Yeah. Blurring is always at the mercy of large numbers. That's kinda-sorta the message above even, though perhaps with the polarity reversed. 

	Jon