4 ms·

Before people panic and again try to claim that HTTPS does not help here, note that the leak here is not in HTTPS itself per-se: it's in DASH and VBR encodings.

by mholt 10y ago

Before people panic and again try to claim that HTTPS does not help here, note that the leak here is not in HTTPS itself per-se: it's in DASH and VBR encodings. Segment sizes can be predictable and are unique for each video. Higher variation in bitrate leaks more unique fingerprint information, and Netflix happens to support high variation in bitrates. HTTPS still does guarantee integrity and confidentiality. Stepping back a bit, although this paper is definitely valuable, it isn't that startling, because we already know that encrypted communications are vulnerable to passive attacks when the contents are predictable. It's a good reminder that "vanilla" encryption isn't necessarily the best way to protect privacy when the attacker can simply guess what we're transmitting because the search space is so small; in this case, it's easy to compare the length of what is being transmitted against a corpus -- and bam. There's only ~42k entries... Entropy entropy entropy. It is your friend. Just so happens that VBR and DASH weren't designed to increase entropy when transmitting segments.

loeg 10y ago
Re: Entropy: Note that just adding random padding to packets doesn't actually protect you from this kind of analysis. You'd want a constant bit-rate ("CBR") encoding instead. Even with CBR, the exact length of the video might give away the contents too. From a bandwidth perspective, such CBR encodings are either wasteful or low quality for high motion scenes—or both. So it makes sense that Netflix has chosen a VBR system, but does have this privacy caveat.
- notgood 10y ago
  > Even with CBR, the exact length of the video might give away the contents too. To avoid that issue you just artificially make multiple movies have the same length, meaning do some padding to round up to the next e.g. 10 minutes (so if the movie is 1:48:23 it becomes 1:50:00), to do so the movie keeps buffering in the background (some random audiovisual noise). Maybe netflix should have a "Fully safe" mode where it uses CBR instead of VBR so the user knows the trade off (slower/heavier buffering)
  - deleted 10y ago
    [deleted]
  - Franciscouzo 10y ago
    It wouldn't work, that sounds like adding sleep calls to prevent timing attacks, which doesn't works... Different bit rates on the random audiovisual noise (white noise would be uncompress-able, thus weight more, pure black would be too compress-able, etc).
    - aianus 10y ago
      Why wouldn't adding sleep calls help prevent timing attacks? Assuming you're padding all response times to the same total response time.
- MayeulC 10y ago
  I just want to point out that Signal, the encrypted messaging/voice chat app is using CBR for that reason: it should be possible to reconstruct the words spoken using the metadata that is leaked from a VBR. Of course, that means losing some bandwidth, so it is not the most bandwidth-efficient app. https://whispersystems.org/blog/signal-video-calls-beta/ https://whispersystems.org/blog/signal-video-calls-beta/
BinaryIdiot 10y ago
So I'm somewhat ignorant in how a lot of TLS works, but wouldn't this have been solved if all packets under TLS were forced to be the same size? Which, is my understanding, isn't part of the standard but wouldn't that essentially prevent these types of snooping?
- Maakuth 10y ago
  That might be true, but the number of transmitted packets per unit of time betray the bitrate of the video being watched. When an attacker is monitoring a transmission coming from Netflix CDN, the nature traffic is a given. edit: clarity
- rupellohn 10y ago
  The fingerprint is derived from the aggregate size of all packets that comprise a segment of video (what the researchers call an ADU), Some possible counter-measures are discussed in the conclusion: "To that end, we believe that Netflix could defend against passive traffic analysis by ensuring that the byte-range portion of the HTTP GETs sent by the browser do not perfectly align with individual video segment boundaries. For instance, the browser could average the size of several consecutive segments and send HTTP GETs for this average size. As an alternative approach, the browser could randomly combine consecutive segments and send HTTP GETs for the combined video data. Designing obfuscation techniques for VBR DASH streams that do not degrade video quality remains a potential area for future research."
js2 10y ago
Even speech can be reconstructed by packet length and timing. A paper from 6 years ago "Phonotactic Reconstruction of Encrypted VoIP Conversations": http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf edit: this paper is referenced in fact by the paper submitted here.
mholt 10y ago
Too late to edit my comment, but: TLS 1.3 and HTTP/2 have padding frames: https://tlswg.github.io/tls13-spec/#rfc.section.5.4 https://tlswg.github.io/tls13-spec/#rfc.section.5.4 - applications that use padding will likely prevent these attacks.

by mholt 10y ago

loeg 10y ago

Re: Entropy: Note that just adding random padding to packets doesn't actually protect you from this kind of analysis. You'd want a constant bit-rate ("CBR") encoding instead. Even with CBR, the exact length of the video might give away the contents too. From a bandwidth perspective, such CBR encodings are either wasteful or low quality for high motion scenes—or both. So it makes sense that Netflix has chosen a VBR system, but does have this privacy caveat.

notgood 10y ago
> Even with CBR, the exact length of the video might give away the contents too. To avoid that issue you just artificially make multiple movies have the same length, meaning do some padding to round up to the next e.g. 10 minutes (so if the movie is 1:48:23 it becomes 1:50:00), to do so the movie keeps buffering in the background (some random audiovisual noise). Maybe netflix should have a "Fully safe" mode where it uses CBR instead of VBR so the user knows the trade off (slower/heavier buffering)
- deleted 10y ago
  [deleted]
- Franciscouzo 10y ago
  It wouldn't work, that sounds like adding sleep calls to prevent timing attacks, which doesn't works... Different bit rates on the random audiovisual noise (white noise would be uncompress-able, thus weight more, pure black would be too compress-able, etc).
  - aianus 10y ago
    Why wouldn't adding sleep calls help prevent timing attacks? Assuming you're padding all response times to the same total response time.
MayeulC 10y ago
I just want to point out that Signal, the encrypted messaging/voice chat app is using CBR for that reason: it should be possible to reconstruct the words spoken using the metadata that is leaked from a VBR. Of course, that means losing some bandwidth, so it is not the most bandwidth-efficient app. https://whispersystems.org/blog/signal-video-calls-beta/ https://whispersystems.org/blog/signal-video-calls-beta/

BinaryIdiot 10y ago

So I'm somewhat ignorant in how a lot of TLS works, but wouldn't this have been solved if all packets under TLS were forced to be the same size? Which, is my understanding, isn't part of the standard but wouldn't that essentially prevent these types of snooping?

Maakuth 10y ago
That might be true, but the number of transmitted packets per unit of time betray the bitrate of the video being watched. When an attacker is monitoring a transmission coming from Netflix CDN, the nature traffic is a given. edit: clarity
rupellohn 10y ago
The fingerprint is derived from the aggregate size of all packets that comprise a segment of video (what the researchers call an ADU), Some possible counter-measures are discussed in the conclusion: "To that end, we believe that Netflix could defend against passive traffic analysis by ensuring that the byte-range portion of the HTTP GETs sent by the browser do not perfectly align with individual video segment boundaries. For instance, the browser could average the size of several consecutive segments and send HTTP GETs for this average size. As an alternative approach, the browser could randomly combine consecutive segments and send HTTP GETs for the combined video data. Designing obfuscation techniques for VBR DASH streams that do not degrade video quality remains a potential area for future research."

js2 10y ago

Even speech can be reconstructed by packet length and timing. A paper from 6 years ago "Phonotactic Reconstruction of Encrypted VoIP Conversations": http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf edit: this paper is referenced in fact by the paper submitted here.

mholt 10y ago

Too late to edit my comment, but: TLS 1.3 and HTTP/2 have padding frames: https://tlswg.github.io/tls13-spec/#rfc.section.5.4 https://tlswg.github.io/tls13-spec/#rfc.section.5.4 - applications that use padding will likely prevent these attacks.