Hacker News Reader

Comment by tw04 | 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. Other than the cost of switch ports (which are dirt cheap relatively speaking) they have absolutely 0 overhead beyond power and cooling for the netflix box which again with their user count is a rounding error.

I'm not sure if the lawmakers are ignorant, bought and paid for, or a little of both but it would be refreshing if one of them took 30 seconds and applied a little critical thinking to the situation.

View on HN

There would be a caching server inside SK Telecom's network if SK didn't demand payment from Netflix to provide SK the caching server.

"But SK Broadband demanded that Netflix pay network usage fees on top of installing those caches. The streaming service sued the telco, and that case is pending — Netflix told us that it would continue negotiations even as it made its case in court."

Alternatively, they would peer with SK Telecom but "SK was demanding large content providers money for peering with them."

https://www.medianama.com/2020/08/223-net-neutrality-south-k...

You’re assuming the over subscription is only occurring on the transit / peering side and not the last mile. I’m not so sure that’s entirely true.

it's SK, so there's a probably an element that the law-makers are paid for. SK is notorious for sending its past presidents to jail for corruption cases. but yeah with that netflix redbox, traffic shouldn't be taxin' the telco's pockets hard.

Is that actually because SK is corrupt, or because SK is really keen on rectitude in politicians? I think there are more than a few UK politicians who could definitely serve time for corruption, and it's even been occasionally (recently the health secretary) bourne out in court, but it's rarely even a political issue, let alone a criminal one.

Also, the less said about SK's neighbors (Japan, for instance) the better.

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

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.

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

I believe YouTube has the same type of program.

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.

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.

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.

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/

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