SoylentNews is people
SoylentNews
http://www.tomshardware.com/news/netflix-efficient-https-video-streams,32420.html
Netflix announced that it has implemented efficient HTTPS encryption for its video streams. To this point, the company has used only HTTPS to protect user information. Netflix has been reluctant to adopt HTTPS for its video streams so far because delivering video is already a bandwidth-heavy task, and adding encryption on top of that risked adding too much overhead. To solve this problem, the company searched for the ideal cipher and its fastest implementation.
Netflix eventually chose the the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), which is available only in TLS 1.2 and later. The company chose GCM over the Cipher Block Chaining (CBC) method because it can encrypt and authenticate the message simultaneously, whereas AES-CBC requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). The latter can still be used as fallback for older browsers and client software that don't support TLS 1.2. However, it shouldn't be too long until virtually all Netflix users can play video streams over TLS 1.2 or later.
The company also tested which were the fastest implementations of AES-GCM in various TLS libraries such as OpenSSL, Google's BoringSSL, and Intel's Intelligent Storage Acceleration Library (ISA-L). The implementations had to work best with AES-NI, the instruction set for Intel and AMD processors that significantly accelerates encryption and decryption. [...] Netflix then tested the BoringSSL and ISA-L AES-GCM implementations and compared them with a baseline OpenSSL implementation. Both managed to increase the performance over the baseline OpenSSL implementation by 30%. Ultimately, Netflix chose the ISA-L library for slightly better performance than BoringSSL. The company is now optimistic that it can add HTTPS encryption to all of its streaming clients without suffering too much of a performance hit compared to the unencrypted versions.
(Score: 2) by hamsterdan on Tuesday August 09 2016, @02:31PM
Wouldn't https for video streams consume even more bandwidth? some of us only have 60GB/month. ISPs are already making it hard to cut the cord in Canada with crappy low quotas.
I skimmed the article but couldn't find any info
(Score: 2) by Whoever on Tuesday August 09 2016, @02:37PM
Not significantly.
(Score: 0) by Anonymous Coward on Tuesday August 09 2016, @03:09PM
More specifically because after a session key is generated, the further traffic will be using symmetric encryption. It is only the initial handshake that uses extra bandwidth & processing power.
Some additional overhead might be due to the fact that https requires all packets usually, so you have to ensure that they all arrive in right sequence, unlike something that is best-efforts-delivery like UDP. But since most video already sues http, which has such a guarantee as well, since pages wouldn't load properly with errors.
(Score: 0) by Anonymous Coward on Tuesday August 09 2016, @05:41PM
specifically, https uses tcp (with all the windowing, ack packets, and connection oriented overhead) as opposed to UDP where data is simply pumped at the recipient with no additional overhead.
So, what am I missing ?
(Score: 2) by TheRaven on Wednesday August 10 2016, @11:00AM
sudo mod me up
(Score: 2) by WizardFusion on Tuesday August 09 2016, @04:37PM
OT: Here in the UK, I download between 300 and 400gb a month. My ISP doesn't care. We *mostly* have true "Unlimited" broadband here.
(Score: 2) by Gravis on Wednesday August 10 2016, @01:13PM
no. the overhead is about a kilobyte for each video stream.
(Score: 1) by deroby on Thursday August 11 2016, @10:16AM
I'm actually wondering if it would consume (noticeably) more battery?
I'm pretty sure most (modern) phones/tablets have hardware capabilities for decoding the video-stream but I'm pretty sure the extra encryption will have to be dealt with by the measly CPU that's in there.