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

John-Mark Gurney jmg at funkthat.com
Tue Dec 10 16:44:05 EST 2019

Jerry Leichter wrote this message on Mon, Dec 09, 2019 at 12:24 -0500:
> 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.

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.

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

Getting the timing side of things will always be difficult, but this
came up again recently, but is old news:

There was the recent NetCAT bug:

That used Intel's DDIO to peak into what characters are pressed in the
ssh session.

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.

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

  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

More information about the cryptography mailing list