Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netflix now supports TLS 1.3

netflixtechblog.com

Post reply on HN
Print view View original

21–30 of 141 posts

Re: Netflix now supports TLS 1.3

#21

Post by Klathmon »

MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

>I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details.

Because secure should be the default where we can do it.

If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching. Either because of advertising profiles or just because I don't want people knowing that I'm binge watching a specific show, or to go to an extreme, perhaps because what I'm watching isn't legal where I live.

If I'm watching a documentary or news show, I don't want the possibility that someone could modify my stream and change parts of it. Misinformation is a big deal, and if we have a simple solution to get rid of whole attack vectors (especially before they become common), why not use it?

And TLS gets rid of other attacks as well. token stealing is a lot harder if EVERYTHING is TLS encrypted vs if only some things are. It can also secure against vulnerabilities in the software that reads the streams. They no longer have to harden their systems as much against potentially hostile data, they can be behind well tested TLS termination that only allow verified data through to the "backend".

Everything should be encrypted in transit, zero exceptions. Just because you don't think it's important to hide doesn't mean that others don't. Just because you think your parsing is secure doesn't mean that another layer isn't useful for defense in depth. We have the technology. It's free, cheap to run, and doesn't hurt the user experience in any significant way, so why not use it?

Re: Netflix now supports TLS 1.3

#22

Post by middleclick »

georgyo wrote: post #10
daurnimator wrote: post #6

Earlier quoted context omitted.

Also to prevent traffic shaping: ISPs throttle traffic that contains netflix.com in the SNI. ESNI (encrypted SNI) comes with TLS 1.3.

ESNI was dropped from the TLS1.3 spec. It is currently a draft protocol. Almost nothing supports ESNI yet. Chrome does not have it yet. Firefox does but it very difficult to enable, there is a config flag but it does nothing on its own unless you also enable DNS over HTTP in Firefox. OpenSSL has no support for ESNI yet either. ESNI also never tells the user if it is working or not yet, making downgrades fairly easy.…

CloudFlare has ESNI enabled (and so do websites hosted by it, like medium.com) so it's not as if no one is doing it.

Re: Netflix now supports TLS 1.3

#23

Post by Tijdreiziger »

throwaway287391 wrote: post #18
MaxBarraclough wrote: post #14

Earlier quoted context omitted.

So ISPs could still impose traffic shaping on Netflix if they wanted to, I take it? I can't see how Netflix could prevent this. Ultimately, their servers ('OCAs') have easily detectable IP addresses, right?

Fast.com probably helps quite a bit. If ISPs throttle Netflix' traffic their fast.com measurements will look bad and customers will complain/sue. (AFAIK there's no way to distinguish between fast.com tests and actual Netflix video consumption since the former's traffic patterns are identical(?) to a Netflix video streaming client's.) Creating fast.com always seemed like a pretty brilliant move by Netflix to me.

I think that was the whole point of fast.com, right? Speeds to known 'speedtest' servers were manipulated by ISPs, and this was bad for Netflix's business because customers would ostensibly have good speeds yet have slow Netflix, so fast.com was created as a way to measure the 'real' speed to Netflix's servers.

Re: Netflix now supports TLS 1.3

#24

Post by saurik »

Klathmon wrote: post #21
MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

>I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. Because secure should be the default where we can do it. If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching. Either because…

> If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching.

Unless Netflix has also started padding their compressed video segments to a deterministic size, TLS doesn't really help with the "I don't want people to know what video I'm watching" problem, as the encrypted media segments are first compressed using a variable bitrate encoding that causes a unique pattern in their resulting chunk sizes; and so, with a little database of signatures--apparently even just at the TCP level, without caring at all about the HTTP and TLS layers... which surprised even me, and I'm quite cynical about this stuff--you can pretty rapidly fingerprint what movie someone is watching from a passive traffic dump.

https://dl.acm.org/doi/10.1145/3029806.3029821

> Identifying HTTPS-Protected Netflix Videos in Real-Time (2017)

> After more than a year of research and development, Netflix recently upgraded their infrastructure to provide HTTPS encryption of video streams in order to protect the privacy of their viewers. Despite this upgrade, we demonstrate that it is possible to accurately identify Netflix videos from passive traffic capture in real-time with very limited hardware requirements. Specifically, we developed a system that can report the Netflix video being delivered by a TCP connection using only the information provided by TCP/IP headers.

> To support our analysis, we created a fingerprint database comprised of 42,027 Netflix videos. Given this collection of fingerprints, we show that our system can differentiate between videos with greater than 99.99% accuracy. Moreover, when tested against 200 random 20-minute video streams, our system identified 99.5% of the videos with the majority of the identifications occurring less than two and a half minutes into the video stream.

Note that this exact same kind of attack has been applied successfully to other places where a pattern of sizes can differentiate usage, including: Google Maps tiles (which are either variably-compressed fixed-dimension images or variably-dense fixed-region vectors), web pages (which are different sizes already but also link to images and other resources that are random sizes, which helps create the fingerprint), and non-personalized type-head search queries (where the result for each letter brings up some unknown set of titles and URLs; as you type each character the sequence of sizes for your intermediate results can expose the query, potentially even without needing any model of the likely keywords).

Maps: https://ioactive.com/ssl-traffic-analysis-on-google-maps/

Search: https://eprint.iacr.org/2014/959.pdf

(edit: I just realized it might be interesting for me to note that I am the lead developer of a new VPN protocol called Orchid and have "attempting to solve as many of these issues as generically and yet with as little required overhead as I can" on my todo list; to be very clear: I don't handle any of this stuff yet at all, but should get to it in the next few months... while the company behind Orchid that is paying me to work on the protocol talks a lot about itself already, I'm really intending to do my own "launch" of the product once I solve some of the stability issues and finish my traffic analysis mitigations.)

Re: Netflix now supports TLS 1.3

#25

Post by georgyo »

middleclick wrote: post #22
georgyo wrote: post #10

Earlier quoted context omitted.

ESNI was dropped from the TLS1.3 spec. It is currently a draft protocol. Almost nothing supports ESNI yet. Chrome does not have it yet. Firefox does but it very difficult to enable, there is a config flag but it does nothing on its own unless you also enable DNS over HTTP in Firefox. OpenSSL has no support for ESNI yet either. ESNI also never tells the user if it is working or not yet, making downgrades fairly easy.…

CloudFlare has ESNI enabled (and so do websites hosted by it, like medium.com) so it's not as if no one is doing it.

If no clients support it, and you can't tell as a user if it is working, then effectively no one is using it.

Re: Netflix now supports TLS 1.3

#26

Post by tialaramex »

MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

https://tools.ietf.org/html/bcp188

Pervasive Monitoring Is an Attack

Re: Netflix now supports TLS 1.3

#27

Post by Jestar342 »

Klathmon wrote: post #21
MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

>I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. Because secure should be the default where we can do it. If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching. Either because…

I think the point being implicitly made in the case of streaming, is it's to help fight against ISPs that are categorising and throttling/charging for channels of bandwidth.

Re: Netflix now supports TLS 1.3

#28

Post by Klathmon »

saurik wrote: post #24
Klathmon wrote: post #21

Earlier quoted context omitted.

>I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. Because secure should be the default where we can do it. If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching. Either because…

> If I'm watching a show, I don't necessarily want every single router along the way knowing what show i'm watching. Unless Netflix has also started padding their compressed video segments to a deterministic size, TLS doesn't really help with the "I don't want people to know what video I'm watching" problem, as the encrypted media segments are first compressed using a variable bitrate encoding that causes a unique pa…

That's really interesting, if i'm understanding this correctly it's basically another form of compression leaking information about the underlying data. Would they need to pad everything to a deterministic size or would they just need to change some early parameters during the encoding process to throw off the rest of the chain?

But in the end it still doesn't mean TLS isn't worth it for all the other benefits (not that you implied that).

Re: Netflix now supports TLS 1.3

#29

Post by londons_explore »

MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

ISPs can still datamine which shows each user is watching simply based on the bursts of data as shows have fast moving or slow moving scenes.

There are only a few tens of thousands of shows on Netflix, so it ought to be easy to identify.

Re: Netflix now supports TLS 1.3

#30

Post by CydeWeys »

londons_explore wrote: post #29
MaxBarraclough wrote: post #5

I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.

ISPs can still datamine which shows each user is watching simply based on the bursts of data as shows have fast moving or slow moving scenes. There are only a few tens of thousands of shows on Netflix, so it ought to be easy to identify.

Has anyone demonstrated that this attack is actually practical? It's super interesting.

One way to defeat it, that is already happening to some extent (though not for this reason), is buffering. Maintain a large enough local buffer, and fill it at a constant bitrate, rather than runrate, and you lose this attack vector, no?

Post reply on HN