
Netflix now supports TLS 1.3 - caution
https://netflixtechblog.com/how-netflix-brings-safer-and-faster-streaming-experience-to-the-living-room-on-crowded-networks-78b8de7f758c
======
MaxBarraclough
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.

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

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

~~~
gsnedders
Yes. The case where it's much more useful is traffic going in/out of major
CDNs to shared IP addresses. For Netflix or someone else running their own CDN
the gains are much smaller.

~~~
MaxBarraclough
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?

~~~
throwaway287391
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.

~~~
Tijdreiziger
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.

~~~
throwaway287391
Yeah, that's what I was saying (or at least trying to say).

------
dochtman
TLS 1.3 has been out for a while now, and always promised performance
improvements (for example, see this Cloudflare article from Sep 2016:
[https://blog.cloudflare.com/introducing-
tls-1-3/](https://blog.cloudflare.com/introducing-tls-1-3/)). I wonder why
Netflix is only getting to it now? Even if some clients didn't support it yet,
seems like they could still introduce support on the server side?

~~~
shanemhansen
Just guessing: it could be related to the fact that they have been reported to
use an unusual setup (kernel TLS on BSD).
[https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%...](https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%20hardware%20offload%20-%20Drew%20Gallatin.pdf)

------
erk__
I wonder if this is also done in-kernel on their edge machines. I know that
they used to do it in kernel with ktls(?) on FreeBSD which they themselves are
a developer of.

------
stuff4ben
While I really liked that they're moving to fully secure TLS 1.3, I was more
impressed by their A/B testing. I find it fascinating they can segment their
traffic by device AND then be able to deliver separate streams of content.
It's something I've wanted to do at many companies I've worked at but we never
had the data to begin with in order to do that. Always another fire to put
out...

------
saagarjha
It’s interesting to see daily variation in play delay; is this just related to
less network congestion during certain hours?

~~~
jakub_g
You have different audience mix around the world (and even within each
country) at different times of the day. At certain hours it's more mobile,
other hours it's more desktop; more US or more Asia etc. (unclear what data is
shown on the graph though)

------
vinay_ys
It is interesting to see the experiment results with 7%-8% improvements in
media rebuffers with just moving from 1-RTT to 0-RTT. Wonder if they ever
considered having only one layer of encryption instead of two (TLS and DRM).
Would that save more CPU and hence avoid media rebuffers lot more?

~~~
anchpop
DRM is required by the people they licence video from. I imagine that they
wouldn't do it if they didn't have to. (They might still do it to their own
content but I don't see what they gain by doing it for someone else's)

~~~
fosefx
By now I have only heared about (and experienced) the downsites of DRM. Are
there any good arguments for it / casestudies that show any reduction in
piracy?

~~~
the_pwner224
[https://news.ycombinator.com/item?id=15305476](https://news.ycombinator.com/item?id=15305476)

[https://news.ycombinator.com/item?id=15319476](https://news.ycombinator.com/item?id=15319476)

------
__s
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
into my streams

~~~
stronglikedan
> 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

~~~
oh_sigh
I'm fairly certain that neither Amazon nor Netflix promise you anything more
than best effort on their streaming quality or delivery time.

You can always cancel your contract with them if you don't like it.

~~~
jaywalk
Sure, but if I'm signed up for a 4K plan and Netflix has entirely disabled 4K,
they cannot possibly provide me what I'm paying for.

 _Note:_ I'm not even sure they have disabled 4K, it's just an example.

~~~
hunter2_
Seems a bit like when a congested campus has a "space not guaranteed" paid
parking program, and you opted for a tier that includes VIP spaces. The VIP
spaces near your building are currently being restriped so you can't use them.
Should you automatically get bumped to the non-VIP tier since it no longer
brings you value? No, you stay on that tier because theoretically it offers
you the VIP spaces at other buildings (like the 4K streams in places that
aren't collaborating with Netflix on decongestion strategies).

------
thanksforfish
Is there a good website listing all the sites that don't use HTTPS or use
really old TLS versions? I'm not seeing one.

As an example, the NVIDIA driver download pages switch to [http://](http://)
for the actual downloads although the rest of the site is HTTPS...

It's interesting to see which companies have difficulty keeping up.

~~~
1123581321
Keep in mind such a list wouldn’t necessarily be accurate, especially since
proxies like Cloudflare can accept 1.0 and 1.1 connections and convert them to
1.2+ Between the proxy and the server.

~~~
thanksforfish
Oh sure, you'd need to do some research. But for sites that openly use http or
old TLS, it would be obvious. I wonder what the top 1M would look like.

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

~~~
toast0
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](https://reviews.freebsd.org/D20655)

------
ncmncm
The elephant in the room is Youtube, which supports only (when last I checked)
TLS 1.0. My OpenSSL is configured to fail connections below 1.3, but evidently
Firefox bypasses that with its own TLS.

If they support TLS at all, why not 1.3? Do they have some dodgy hack that
avoids a performance cost in 1.3 that is not in 1.0? Or is it just sloth?

~~~
syntheticcorp
That’s not the case now. I see a TLSv1.3 connection to the googlevideo.com
server using Firefox, and a QUIC connection in Chrome

------
FpUser
I am curious why would I care about what do they do with their streams as long
as I get adequate playback quality.

