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

131–140 of 141 posts

Re: Netflix now supports TLS 1.3

#131

Post by Aissen »

Aissen wrote: post #72
merb wrote: post #41

Earlier quoted context omitted.

yeah with a targeted attack. but I've meant big scale monitoring which person watches what. also eme basically solves this on the audo and video side. (maybe not the best solution tough)

I think you overestimate how complex this is to purpose-build once you have the basics of DPI in place. Also you don't need a precise measurement. Just measuring a random 10k users in 1M network daily will give you more precise viewership measurement than anything Netflix publishes.

Replying to self… I'm wondering if the recent per-country daily "Top 10" that Netflix is now exposing in its UI (now scraped by https://flixpatrol.com/) is not a response to ISPs already building this ? Like a way to kill two birds with one stone: reduce value of private measurements, and improve UX at the same time.

Re: Netflix now supports TLS 1.3

#132

Post by CydeWeys »

bostik wrote: post #127
CydeWeys wrote: post #77

Earlier quoted context omitted.

VoIP is a completely different use case though because it needs to be real-time. A latency of even 100ms is noticeable. By contrast, Netflix is streaming pre-recorded content, so any latency is not perceived at all so long as it is smaller than the buffer size. E.g. I could have a 5 minute buffer and suffer a 4 minute Internet outage and never so much as notice, whereas that would obliterate any VoIP use case.

I agree it's not exactly the same. I would also love to inhabit the parallel universe where Netflix hands out a 4-minute buffer, because in this one 20 seconds seems to be on the high end. However, I strongly suspect that Netflix's video and audio are sent in different streams. Occasionally video for some titles is missing but audio gets through, confusing our daughter to no end. So while you can't infer individual s…

This is why someone needs to do the research on it. Even a 20 second buffer, filled at a constant bitrate, may suffice to deter the vast majority of potential bitrate signatures that could be used to identify the stream. The status quo may already be sufficient defense.

Interesting data point on the separate AV streams. I can't say I've noticed that myself.

Re: Netflix now supports TLS 1.3

#133

Post by MaxBarraclough »

merb wrote: post #126
MaxBarraclough wrote: post #50

Earlier quoted context omitted.

How does EME change anything?

EME encodes the video content. i.e. without eme you can basically extract the video via tcpdump, with eme you can't since everything, even metadata is encrypted. the attack inside the pdf does basically mention the old technology which netflix used and not dash+eme inside video element (MPEG-CENC). i.e. widevine which is kinda funny because the browser drm is highly controversial, but in this case serves as additiona…

> EME encodes the video content

EME encrypts the video content, yes, but I don't see that this changes things. Netflix uses HTTPS (TLS) encryption over the top of the EME encryption, as this thread's title states.

> even metadata is encrypted.

I don't believe so. If you're delivering EME-encrypted blobs over insecure HTTP, an ISP will be able to see which blobs you are requesting, simply by their URL.

Aside: I recall reading that Netflix's CDN servers ('OCAs') store EME-encrypted blobs, so only the HTTPS encryption burdens the delivery server's CPU. Unsurprising, of course.

> without eme you can basically extract the video via tcpdump

Six years ago, sure. Today, no, as the stream is sent over HTTPS.

> in this case serves as additional privacy since video metadata and content get's encrypted, no matter which transport layer is used.

Perhaps unencrypted streams are still used to support legacy devices, but Netflix are committed to maximal use of HTTPS.

I don't see how EME's additional layer of encryption changes anything as far as privacy and unscrupulous ISPs are concerned.

Re: Netflix now supports TLS 1.3

#134

Post by MaxBarraclough »

bostik wrote: post #127
CydeWeys wrote: post #77

Earlier quoted context omitted.

VoIP is a completely different use case though because it needs to be real-time. A latency of even 100ms is noticeable. By contrast, Netflix is streaming pre-recorded content, so any latency is not perceived at all so long as it is smaller than the buffer size. E.g. I could have a 5 minute buffer and suffer a 4 minute Internet outage and never so much as notice, whereas that would obliterate any VoIP use case.

I agree it's not exactly the same. I would also love to inhabit the parallel universe where Netflix hands out a 4-minute buffer, because in this one 20 seconds seems to be on the high end. However, I strongly suspect that Netflix's video and audio are sent in different streams. Occasionally video for some titles is missing but audio gets through, confusing our daughter to no end. So while you can't infer individual s…

> I would also love to inhabit the parallel universe where Netflix hands out a 4-minute buffer, because in this one 20 seconds seems to be on the high end.

Presumably it depends on the device, but I vaguely recall testing this out on a Chromecast, and I found Netflix to buffer up for several minutes. Some other streaming providers, such as Rakuten, only buffered around 15 seconds.

> I strongly suspect that Netflix's video and audio are sent in different streams

I think this might be right. They presumably want to support lots of different combinations of audio codecs and video codecs, so keeping them separate would make sense. Pure guesswork on my part though.

Re: Netflix now supports TLS 1.3

#135

Post by MaxBarraclough »

rechristened wrote: post #94
MaxBarraclough wrote: post #49

Earlier quoted context omitted.

It's possible to distribute large binary blobs over unencrypted HTTP, and to provide security using hash checks. I believe apt no longer does this due to a flaw in their implementation that would not have been an issue if they'd used HTTPS. I'm unsure if Steam still uses insecure HTTP, but they certainly used to. [0] [1] I'm all for HTTPS everywhere, but for Netflix and YouTube, that means encrypting exabytes of data…

How are you distributing the hashes?

Either over HTTPS or by signing the manifest files using a well-known public key, and ensuring that stale manifests are never used (otherwise it's possible for an attacker to cause installation of old, vulnerable software).

apt used to be 100% HTTP based. I believe they've changed course recently though. Unsure about Steam.

Steam were clear that the reason they adopted insecure HTTP (previously they used a proprietary protocol) was to enable web caching, by ISPs and other organisations. I can imagine that being very beneficial at a commercial LAN party, for instance.

Related reading: https://wiki.debian.org/SecureApt

Re: Netflix now supports TLS 1.3

#136

Post by MaxBarraclough »

CydeWeys wrote: post #79
MaxBarraclough wrote: post #49

Earlier quoted context omitted.

It's possible to distribute large binary blobs over unencrypted HTTP, and to provide security using hash checks. I believe apt no longer does this due to a flaw in their implementation that would not have been an issue if they'd used HTTPS. I'm unsure if Steam still uses insecure HTTP, but they certainly used to. [0] [1] I'm all for HTTPS everywhere, but for Netflix and YouTube, that means encrypting exabytes of data…

Given that hardware encrypting/decrypting is omnipresent, is it really that much more expensive to stream content securely? I'd like to see the numbers, but I just don't think it's actually a meaningful increase in cost. Network traffic itself tends to be the dominating factor in cost, with encryption just upping your electric bill slightly. It seems like the benefits of transmitting your streaming securely (e.g. def…

It took a significant engineering effort at Netflix.

When people whine about the overheads of HTTPS, they're generally talking nonsense, as the overheads are typically marginal. Video streaming providers are the exception.

https://arstechnica.com/information-technology/2015/04/it-wa...

Re: Netflix now supports TLS 1.3

#137

Post by MaxBarraclough »

Rebelgecko wrote: post #93
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.

>given that the data they're dealing with is films and TV shows, rather than, say, payment details. I definitely have had to enter payment details on Netflix.com before

We're talking about why they encrypt their media streams.

Re: Netflix now supports TLS 1.3

#138

Post by [deleted] »

rmrfstar wrote: post #128
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 don't think this is a new feature? I run an out-of-band network tap and have seen only TLS 1.3 traffic for some time now.

[deleted]

Re: Netflix now supports TLS 1.3

#139

Post by Rebelgecko »

MaxBarraclough wrote: post #137
Rebelgecko wrote: post #93

Earlier quoted context omitted.

>given that the data they're dealing with is films and TV shows, rather than, say, payment details. I definitely have had to enter payment details on Netflix.com before

We're talking about why they encrypt their media streams.

I'm not super familiar with how the TLS handshake and sessions work, is it straightforward to mix and match like that? e.g. tell the client that this particular webpage (like with payment info) requires TLS 1.3, but less important pages (like a movie) can fall back to TLS 1.0 or SSL or whatever?

Re: Netflix now supports TLS 1.3

#140

Post by MaxBarraclough »

Ambroos wrote: post #76
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.

In browsers at least, DRM doesn't work if your full page doesn't use HTTPS. The encrypted media extensions (EME) are only available on secure contexts, which means the page needs to be HTTPS. Segments are typically fetched with standard XHR/fetch, which means they need to use HTTPS on secure origins as well. You really don't want to have to deal with mixed content. Unrelated to DRM, Apple's ATS on iOS kinda requires…

> encrypted media extensions (EME) are only available on secure contexts, which means the page needs to be HTTPS

I didn't know that, but you're right. [0] There was a time Netflix didn't use HTTPS. [1] I guess they must not have supported HTML5 at that time, and must have been using Silverlight for in-browser viewing.

[0] https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

[1] https://arstechnica.com/information-technology/2015/04/it-wa...

Post reply on HN