SoylentNews is people
SoylentNews
from the when-does-a-video-stream-become-a-river? dept.
Ars Technica reports that Netflix is about to encrypt all its video streams with HTTPS. The feature will be rolled out in the coming year. This comes after one failed attempt six months ago.
Netflix's entry into the HTTPS party comes as privacy and security advocates are calling on all websites to encrypt all their traffic. The rationale behind the request is that continuous and complete HTTPS protection thwarts state-sponsored attacks that countries like the US and China launch from the Internet backbone. Web encryption is also useful against man-in-the-middle attacks that hijack huge chunks of Internet traffic. In both cases, HTTPS prevents the attacker from surreptitiously injecting malicious packets into the targeted data stream.
According to El Reg, this change will increase costs considerably for Netflix:
Netflix has battled with the overheads HTTPS incurs; Watson estimated a capacity hit between 30 to 53 percent thanks to encryption computational overheads and a lack of optimisations to avoid data copies to and from user space.
Such a hit would cost Netflix potentially hundreds of millions of dollars a year.
Tweaks could cut that overhead by a third while speculative advancements in the next several years could crush it by up to 80 percent.
Do we really need encrypted video streams?
(Score: 2) by doublerot13 on Sunday April 19 2015, @02:30PM
AES instructions on right there on the chip now a days. Why does the CPU hit have to be so dramatic?
(Score: 0) by Anonymous Coward on Sunday April 19 2015, @02:57PM
Maybe it's a DRM abstraction thing?
(Score: 2) by Wootery on Wednesday April 22 2015, @11:00PM
Meaning what?
(Score: 4, Funny) by Anonymous Coward on Sunday April 19 2015, @03:02PM
Look, he believes brogrammers take advantage of hardware features!
(Score: 4, Interesting) by tynin on Sunday April 19 2015, @03:05PM
I suspect it is because it will be encrypted, it won't be cacheable in any meaningful sense. All the work that the cache would have saved handling tons of concurrent users doing largely similar actions is likely right in that 30 to 53 percent number.
(Score: 2) by frojack on Sunday April 19 2015, @10:51PM
But Netflix has their own servers parked on the head end controllers of most big ISPs, don't they?
If So caching has already been pushed far down the tree.
And given that, they have a lot more engines doing the stream encryption very close to the customer.
Also, a question: Is AES efficient at encrypting long running streaming video? I was under the impression there were other ciphers that were better for that.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by tempest on Monday April 20 2015, @02:23PM
In TLS1.2 we're basically down to Camellia and AES (forgetting Ghost and Koren oddballs). Chacha20 would probably be the best option considering the range of devices connecting (Roku/PS3/phones/TV embedded/etc) which don't have AES acceleration, but is still in the process of being adapted. I think they'll be using special hardware for acceleration regardless.
(Score: 3, Informative) by frojack on Monday April 20 2015, @09:49PM
That fits with what I was remembering.
You might start with AES-128 or something for session initiation, but once you start a data stream you quickly switch to some more efficient cipher to handle the speed.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by Immerman on Sunday April 19 2015, @03:06PM
Perhaps because it's a lot more computationally expensive to use those instructions than to stream raw data straight off the hard drive to the network card? Which, assuming good CPU throttling, will translate directly to higher power consumption. And that's assuming the CPUs aren't stripped down models that would need to be upgraded for real-time encryption to begin with.
Plus there's the caching issue - without encryption if two people in a city are watching the same thing at about the same time Netflix's servers can potentially send the data across the country only once, and the local streaming media cache can feed the data to the second and subsequent viewers. With encryption every viewer has to get the data directly from the Netflix servers.
(Score: 5, Interesting) by tnt118 on Sunday April 19 2015, @05:45PM
I've always wondered if there was a viable model for a movie or show "starting" every 10 minutes, and users jump in on one of those streams to save bandwidth costs.
I think I like it here.
(Score: 2) by AnonTechie on Sunday April 19 2015, @08:38PM
Thats an interesting idea.
Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
(Score: 2) by nightsky30 on Wednesday April 22 2015, @08:57PM
If they don't add commercials in between, that would be great. Otherwise it would be too much like TV. It also kind of kills the instant factor, unless the multicast is optional. Say they have listings. If a show starts in 5 mins, ok. I'd wait for it. But if nobody is watching what I'd like to watch, let me start one right now. I'd hate to see listings of a show that is 3 hours long but only half way through, and has 0 viewers and no way to start a fresh show.
(Score: 2) by linuxrocks123 on Monday April 20 2015, @07:00AM
This is how in-flight movies work.
(Score: 2) by gnuman on Monday April 20 2015, @04:50PM
I've always wondered if there was a viable model for a movie or show "starting" every 10 minutes, and users jump in on one of those streams to save bandwidth costs.
What do you think that multicast thing was for?
http://en.wikipedia.org/wiki/Multicast [wikipedia.org]
(Score: 2) by Wootery on Wednesday April 22 2015, @11:08PM
The caching question seems like the elephant in the room.
Was Netflix previously using ordinary HTTP to deliver video content? If so, that would presumably have enabled caching by ISPs. I imagine some folks will not be happy about the increase in traffic if caching is no longer possible.
Steam moved to HTTP (away from their old proprietary protocol) for downloads [steampowered.com] in order to enable caching.
(Score: 2) by Jeremiah Cornelius on Sunday April 19 2015, @05:43PM
The AES encrypting of the HTTP stream is not the hit.
There's a LOT of compute used in session-key generation - occurring late in the hand-shake phase of the protocol. A few of these? no problem. Ten million? Ouch.
AFTER you have keys, "magic" instructions can use them to make the overhead almost transparent.
You're betting on the pantomime horse...
(Score: 1) by KiloByte on Monday April 20 2015, @12:48AM
When the streams are something as big as high-resolution videos, once-per-stream handshakes are not going to drag you down.
Ceterum censeo systemd esse delendam.
(Score: 2) by Jeremiah Cornelius on Monday April 20 2015, @01:44AM
There is SERVER SIDE work here! That guy does once per HTTPS session. The client? WFC!
You're betting on the pantomime horse...