Hacker News Reader

Comment by piaste | Hacker News Reader

> The thing that's most ridiculous about this is that the bandwidth is essentially "free" for SK telecom. They sit a netflix caching server in their network and the traffic never leaves.

Wouldn't that require them to MITM the Netflix traffic, which I would hope is under TLS?

View on HN

No, Netflix's applications would have users of that ISP use the CDN server which they would locate within SK Telecom's network.

Netflix calls it their Open Connect Appliance: https://openconnect.netflix.com/en/appliances/

That server would, of course, have a connection to the Internet, they push logs to AWS and get updates from Netflix's authoritative servers in Netflix's other datacenters, but they also serve HTTPS connections to thousands of ISP users; the upstream traffic would be minimal.

It's not a caching server run by the ISP. It's a Netflix server embedded in ISP's datacenter/network. No MITM required

https://openconnect.netflix.com/en/

Netflix provides the ISP with the box, afaik the box contains a signed certificate for a Netflix subdomain specific to that box. The "real" Netflix servers direct the customer to that subdomain for the actual content.

Here's more information about the program: https://openconnect.netflix.com/en/

I believe YouTube has the same type of program.

My guess Netflix can guide that by handing back different IPs when the end user requests the netflix server name. They can also handle it in application the netflix application can look and see it is in a network that has a box and just goto that ip/host/proxy instead of the generic one. Netflix still controls the keys. No MITM needed.

Netflix ships them the box is they ask and sign a contract that they will plug it in and have a security guard it so.

Does this mean that Netflix has to have a private TLS key in the box? I wonder how the security of these keys is usually maintained. Interesting engineering/cryptography problem.

This problem might also be an interesting use case for Signed HTTP Exchanges. Sign the video files, then push them to the caching server. The caching server then never possesses the private keys for the connection and also cannot modify the content.

There’s nothing interesting here.

What are you going to achieve by stealing the certificate for edge0.sktelecom.geo.netflixcdn.com from the box you already have access to?

There’s no reason to put *.netflix.com certs on the edge caches.

Could be in a TPM as well.

TPMs are pretty slow; the LPC bus they sit off of is basically run at ISA bus speeds.

Maybe they used TPM when they meant HSM

Even then, it's probably too high of latency. These Netflix caching boxes are perennially the subject of "this is how you TLS at line rate and memory bandwidth limits" talks. When you combine this with the fact that these boxes aren't just installed anywhere, but deep inside ISP networks, and ostenisbly the certs aren't for *.netflix.com, but instead for either that specific ISP or even that specifc box, _and_ the certs need to be remotely updated anyway, so they can't just live in an HSM the whole time, I'd just store them on disk if I were Netflix.

Wouldn’t HSM only be needed for the private key though? Once it’s in memory it’s free

And you need the private key for every new TLS connection. And when you are running multiple 100Gb interfaces, that's a lot of TLS connections.

Versus, what's the attack? The ISP with physical access to the box can pull can screw with the cached video data somehow? Or MitM and know what Netflix videos their users are watching?

Slightly tangent: https://developers.cloudflare.com/ssl/keyless-ssl

Reply on news.ycombinator.com