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

121–130 of 141 posts

Re: Netflix now supports TLS 1.3

#121

Post by tialaramex »

SketchySeaBeast wrote: post #55
saurik wrote: post #36

Earlier quoted context omitted.

The way static "streaming" video works is that you divide the video into a number of small segments--maybe every 10 seconds or every 2 seconds or something--and then encode each of those segments at various quality levels and store all of those files on HTTP servers. There is then a "manifest" file that lets the client learn what qualities are available and what their URLs will be for various timestamps. The client t…

Doesn't this inspection of the manifest have a fairly limited scope in how it can be exploited though? I know the attacker will be able to see what someone is watching, but only for non-novel information, right? You can't use that technique to guess anything new, and had to have yourself already seen the video?

Well one of the things that paper does is they just go fetch the index.

Every Netflix client that is watching say 1080p Rick & Morty s1e2 fetches an index of the bits that make up that video, and then fetches the relevant chunks of data.

So if you just fetch that index, no need to "watch" the video, you know OK 1390450 bytes is the 1st chunk of data making up that video, and then 2046917 bytes is the 2nd chunk. When you see that somebody fetched 1390450 bytes of encrypted data from Netflix, they're probably watching s1e2 of Rick & Morty in 1080p. When they fetch 2046917 bytes of encrypted data that confirms it.

So it's "non-novel" but they don't need to (relatively expensively) actually watch the videos they want to match. It's likely any sophisticated adversary has an index of all the common videos from sites like Netflix, the Play Store, Disney+ and so on.

There is definitely more a client could do to make this harder, but there'd be a sharp trade-off where to make it impossible for passive eavesdroppers to know what you saw costs both you and the "broadcaster" a lot of bandwidth, and bandwidth ain't free.

I'd like to see Netflix at least gently stroll in that direction, maybe use some TLS padding to make it a bit harder to do this trick, but I don't expect them to set off at a sprint and ruin their profitability in pursuit of a non-goal.

Re: Netflix now supports TLS 1.3

#122

Post by berti »

shawnz wrote: post #54
georgyo wrote: post #25

Earlier quoted context omitted.

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

Firefox supports it, although currently only as a configurable. Users can test their ESNI support online here: https://www.cloudflare.com/ssl/encrypted-sni/

> Firefox supports it

Only if you use their built-in DoH resolver. The public keys for ESNI are distributed by DNS records and as I understand it there's a bunch of work to be done for Firefox to retrieve these records from classic DNS servers. That work has been classified P5 (we won't do it, but might accept patches)[0].

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

Re: Netflix now supports TLS 1.3

#123

Post by tialaramex »

tfigment wrote: post #71
KingMachiavelli wrote: post #65

Earlier quoted context omitted.

Agreed. I've been blocking HTTP (on port 80) accross my network and I reroute all DNS traffic to a pihole configured to use DoT. At this point in time there is really no reason to let anyone see plain text traffic. A few things are whitelisted but the handful of things that break aren't necessary anyway.

Genuine question: Do you not have issues with browsers and other security products and OCSP? At work they blocked all internet access and tools that forced use of CRL and OCSP lost their minds. Digicert and other CAs seem to to use port 80 for this. Firefox requires OCSP option to be disabled for me for GitHub to work with pauses.

OCSP has to be port 80 because of the chicken and egg problem.

Specifically, if you use HTTPS for OCSP then now you need OCSP for the certificate for the HTTPS connection you're doing to get OCSP, so you open another HTTPS connection, and you need OCSP for that certificate, and then you open another HTTPS connection and...

But most browsers don't do OCSP by default because realistically you need fail-open behaviour and if you have fail-open behaviour there's no meaningful security benefit so why bother?

Re: Netflix now supports TLS 1.3

#124

Post by toast0 »

tialaramex wrote: post #35
saurik wrote: post #24

Earlier quoted context omitted.

> 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…

Yup. One thing that I'm surprised to see hasn't happened already, but maybe has a better chance in QUIC than TLS 1.3 itself is making use of TLS 1.3 padding to exactly fill the MTU on typical 1500 byte (or so) links. The TLS 1.3 on-wire format is weird because it needs to pass rusted-in-place TLS 1.2 only middleboxes. One of the convenient side effects is that you can add one or more bytes of padding "free". Any 1499…

Netflix's aproach of doing TLS in the (FreeBSD) kernel may make it easier to do this. In most stacks, the TLS segmentation is too far away from the TCP segmentation to make this practical, especially since MTU/MSS can change during a connection.

Re: Netflix now supports TLS 1.3

#125

Post by toast0 »

gok wrote: post #74

This is cool, and I'm glad to see that A/B testing confirms that TLS 1.3 is actually faster at startup in the real world. That said, I find most annoying Netflix perf problems are in the middle of a stream, not the start. I wonder how much they're getting hit by TCP congestion control troubles, and if QUIC/HTTP3 might help.

If TCP congestion control is an issue for Netflix, it would be addressable on the server side, and I'm guessing they would address it in the FreeBSD kernel. Looking through the congestion control directory, there's not a lot of changes coming from Netflix; although, the TCP_STATS one [1] looks interesting, and some of the others indicate they're probably doing some testing (bug fixes and code cleanup).

Switching from TCP to TCP over UDP in order to run congestion control (and other things, such as segmentation) in userspace instead of kernel space makes more sense if you don't control the kernel; but Netflix controls the kernel on the content appliances. Netflix has also put a lot of effort into moving more of the processing into the kernel to avoid copying data and context switches between the kernel and userspace; moving congestion control into userspace would most likely have a large negative impact on their serving bandwidth per appliance.

[1] https://reviews.freebsd.org/D20655

Re: Netflix now supports TLS 1.3

#126

Post by merb »

MaxBarraclough wrote: post #50
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)

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 additional privacy since video metadata and content get's encrypted, no matter which transport layer is used.

Re: Netflix now supports TLS 1.3

#127

Post by bostik »

CydeWeys wrote: post #77
bostik wrote: post #38

Earlier quoted context omitted.

The attack is known from VoIP systems: https://www.researchgate.net/publication/321888273_Classific... Adapting the research to other non-CBR streams doesn't sound far-fetched.

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 syllables from the audio stream (as you would from VoIP), the audio streams should have varying enough size and chunking characteristics that allow to identify them.

Re: Netflix now supports TLS 1.3

#128

Post by rmrfstar »

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.

Re: Netflix now supports TLS 1.3

#129

Post by MaxBarraclough »

tialaramex wrote: post #121
SketchySeaBeast wrote: post #55

Earlier quoted context omitted.

Doesn't this inspection of the manifest have a fairly limited scope in how it can be exploited though? I know the attacker will be able to see what someone is watching, but only for non-novel information, right? You can't use that technique to guess anything new, and had to have yourself already seen the video?

Well one of the things that paper does is they just go fetch the index. Every Netflix client that is watching say 1080p Rick & Morty s1e2 fetches an index of the bits that make up that video, and then fetches the relevant chunks of data. So if you just fetch that index, no need to "watch" the video, you know OK 1390450 bytes is the 1st chunk of data making up that video, and then 2046917 bytes is the 2nd chunk. When…

> there'd be a sharp trade-off where to make it impossible for passive eavesdroppers to know what you saw costs both you and the "broadcaster" a lot of bandwidth, and bandwidth ain't free

Off the top of my head: if you took a live streaming approach along the lines of live TV, or indeed Google Stadia/GeForce Now/OnLive, then you could presumably make the traffic patterns invariant over what was being watched. You'd need to ensure the bitrate didn't drop during low-detail scenes, I suppose, similar to what you mentioned re. Skype below.

That approach would of course be far more intensive on server resources, but I'm sure a similar level of privacy could be achieved without such inefficiency.

Re: Netflix now supports TLS 1.3

#130

Post by lclarkmichalek »

v7p1Qbt1im wrote: post #9
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.

Networking noob here. Can‘t the ISP see Netflix‘s ASN/commonly used IP‘s and shape that way?

Both the replies here miss the fact that the relationship between Netflix and ISPs is often pretty cooperative. Specifically, Netflix will provide ISPs with devices to do caching. The ISPs need to install and run these devices, configure the routes to send traffic to them, etc etc. Details: https://openconnect.netflix.com/en/. Because of that (and various other things), it's very easy for ISPs to attribute traffic to Netflix.
Post reply on HN