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

71–80 of 141 posts

Re: Netflix now supports TLS 1.3

#71

Post by tfigment »

KingMachiavelli wrote: post #65
__s wrote: post #56

Can someone explain why this thread is full of people not caring about security? This article even goes over how TLS 1.3 is a perf improvement Have the anti privacy crowd come out in droves now that we have a public desire for contact tracing & there's a desire to scapegoat why netflix et al have reduced stream quality due to increased load? & HTTP is not an option. I for one enjoy my ISP not being able to inject ads…

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.

Re: Netflix now supports TLS 1.3

#72

Post by Aissen »

merb wrote: post #41
saurik wrote: post #37

Earlier quoted context omitted.

Why would the size of the network possibly matter?... You do know that you can just filter the packets by IP address, right? ;P

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.

Re: Netflix now supports TLS 1.3

#73

Post by user5994461 »

__s wrote: post #56

Can someone explain why this thread is full of people not caring about security? This article even goes over how TLS 1.3 is a perf improvement Have the anti privacy crowd come out in droves now that we have a public desire for contact tracing & there's a desire to scapegoat why netflix et al have reduced stream quality due to increased load? & HTTP is not an option. I for one enjoy my ISP not being able to inject ads…

Who cares about security in the real world? Have you tried googling "should I use SSL"?

The top answer is a stackoverflow answer saying no way. "Putting SSL everywhere is only a way to get a warm fuzzy feeling on security that is no good. It [SSL] is usually only used as a distraction allowing administrators to disregard actual security issues."

https://stackoverflow.com/questions/2177159/should-all-sites...

Re: Netflix now supports TLS 1.3

#74

Post by gok »

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.

Re: Netflix now supports TLS 1.3

#75

Post by user5994461 »

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 is broken by design. Should turn it off for server applications. Maybe even disable it entirely when compiling openssl if possible.

OCSP is to query random CA web servers when opening a SSL connection to verify if the certificate in use was revoked. It's broken by design because servers simply don't have internet access.

Re: Netflix now supports TLS 1.3

#76

Post by Ambroos »

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 developers to only use HTTPS origins in their apps.

At that point, you might as well just do HTTPS everywhere.

Re: Netflix now supports TLS 1.3

#77

Post by CydeWeys »

bostik wrote: post #38
CydeWeys wrote: post #30

Earlier quoted context omitted.

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?

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.

Re: Netflix now supports TLS 1.3

#78

Post by stronglikedan »

__s wrote: post #56

Can someone explain why this thread is full of people not caring about security? This article even goes over how TLS 1.3 is a perf improvement Have the anti privacy crowd come out in droves now that we have a public desire for contact tracing & there's a desire to scapegoat why netflix et al have reduced stream quality due to increased load? & HTTP is not an option. I for one enjoy my ISP not being able to inject ads…

> netflix et al have reduced stream quality due to increased load

OT, but why am I still paying full price for less-than-full quality? Same with Amazon - why am I paying for two-day Prime shipping even though it's impossible to get that level of service right now? /rant

Re: Netflix now supports TLS 1.3

#79

Post by CydeWeys »

MaxBarraclough wrote: post #49
CydeWeys wrote: post #32

Earlier quoted context omitted.

Are you hinting at something here, some threat maybe, that you think Netflix is responding to? Or do you just not think that more security is a good thing generally and should be done for its own sake?

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. defeating interloping ISPs) more than exceed the costs, hence why they're doing it.

Re: Netflix now supports TLS 1.3

#80

Post by throwaway287391 »

Tijdreiziger wrote: post #23
throwaway287391 wrote: post #18

Earlier quoted context omitted.

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.

Yeah, that's what I was saying (or at least trying to say).
Post reply on HN