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.
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.
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?
The scraping and automated viewing in question pretty clearly violate Netflix's terms of use. As junior officers in the U.S. Army, the authors are more vulnerable than most to trivial but "correct" accusations of illegal activity, so I wonder if they were at all concerned about the government's sweeping interpretation of the Computer Fraud and Abuse Act.
> In order to generate these fingerprints, we first mapped every available video on Netflix. We took advantage of Netflix’s search feature to do this mapping by conducting iterative search queries to enumerate all of Netflix’s videos. This enumeration was done by visiting https://www.netflix.com/search/<value> where <value> was ‘a’, then ‘b’, etc. and then parsing the returned HTML into a list of videos with matching URLs.
This is not the same as but still in the same class of "unauthorized" use that Weev was charged with carrying out on AT&T endpoints. No privacy concern here, and in theory you are authorized to view this Netflix content but not to "use any robot, spider, scraper or other automated means to access the Netflix service; decompile, reverse engineer or disassemble any software or other products or processes accessible through the Netflix service; insert any code or product or manipulate the content of the Netflix service in any way; or use any data mining, data gathering or extraction method." Though Weev's conviction was vacated on appeal, that was only based on a venue problem so the prosecution's legal theory about violating terms of use still seems to be in play.
Not concern trolling here, I do this sort of scraping all the time and there's no reason to believe the authors are at any risk. It's just an interesting juxtaposition that illustrates how overly broad the DOJ's interpretation of CFAA is, and how selectively it can be pursued. As the EFF notes, one of the major impacts is that is puts security researchers in a legal gray area (https://www.eff.org/issues/cfaa).
Very interesting that they can get a video fingerprint without even downloading the video. So they can fingerprint 44k in 4 days (7 seconds each) instead of downloading each video which would be very demanding. I wonder if Netflix had any monitoring that noticed them initiating a stream of every single video. I wonder if they used multiple Netflix accounts.
They mention they used Silverlight. I wonder if this also works for videos when viewed with HTML5, and if the same fingerprints can be used.
The result of this is generalizable. Looking at your encrypted HTTPS traffic, people can still tell what you are browsing and downloading especially when they have a good idea of what you could browse or download.
For the rest, I am not sure how many people should be afraid to let people know what they are watching on Netflix.
Yep, people can infer a lot. I did a demo of this a couple of years ago for my employer at the time by creating a tool which, in a slightly contrived scenario, is able to figure out what one is looking at on Google Maps over SSL.
[+] [-] mholt|9 years ago|reply
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.
[+] [-] mholt|9 years ago|reply
[+] [-] js2|9 years ago|reply
http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf
edit: this paper is referenced in fact by the paper submitted here.
[+] [-] loeg|9 years ago|reply
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.
[+] [-] BinaryIdiot|9 years ago|reply
[+] [-] ims|9 years ago|reply
> In order to generate these fingerprints, we first mapped every available video on Netflix. We took advantage of Netflix’s search feature to do this mapping by conducting iterative search queries to enumerate all of Netflix’s videos. This enumeration was done by visiting https://www.netflix.com/search/<value> where <value> was ‘a’, then ‘b’, etc. and then parsing the returned HTML into a list of videos with matching URLs.
This is not the same as but still in the same class of "unauthorized" use that Weev was charged with carrying out on AT&T endpoints. No privacy concern here, and in theory you are authorized to view this Netflix content but not to "use any robot, spider, scraper or other automated means to access the Netflix service; decompile, reverse engineer or disassemble any software or other products or processes accessible through the Netflix service; insert any code or product or manipulate the content of the Netflix service in any way; or use any data mining, data gathering or extraction method." Though Weev's conviction was vacated on appeal, that was only based on a venue problem so the prosecution's legal theory about violating terms of use still seems to be in play.
Not concern trolling here, I do this sort of scraping all the time and there's no reason to believe the authors are at any risk. It's just an interesting juxtaposition that illustrates how overly broad the DOJ's interpretation of CFAA is, and how selectively it can be pursued. As the EFF notes, one of the major impacts is that is puts security researchers in a legal gray area (https://www.eff.org/issues/cfaa).
[+] [-] otterley|9 years ago|reply
[+] [-] Buge|9 years ago|reply
They mention they used Silverlight. I wonder if this also works for videos when viewed with HTML5, and if the same fingerprints can be used.
[+] [-] saurik|9 years ago|reply
I am very curious why this matters to you.
[+] [-] ChrisCinelli|9 years ago|reply
For the rest, I am not sure how many people should be afraid to let people know what they are watching on Netflix.
[+] [-] santaragolabs|9 years ago|reply
Blogpost (includes demo vid): http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...
[+] [-] dbg31415|9 years ago|reply
[+] [-] lbatx|9 years ago|reply
Note: not defending Netflix's position on VPNs, just pointing out that the user still has free will.
[+] [-] snthd|9 years ago|reply