Hacker News Reader

Comment by gregable | Hacker News Reader

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.

View on HN

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