Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday August 09 2016, @08:56AM   Printer-friendly
from the I-can't-see-what-you-did-there dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Whoever on Tuesday August 09 2016, @02:37PM

    by Whoever (4524) on Tuesday August 09 2016, @02:37PM (#385766) Journal

    Wouldn't https for video streams consume even more bandwidth?

    Not significantly.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Tuesday August 09 2016, @03:09PM

    by Anonymous Coward on Tuesday August 09 2016, @03:09PM (#385785)

    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

    by Anonymous Coward on Tuesday August 09 2016, @05:41PM (#385871)

    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

      by TheRaven (270) on Wednesday August 10 2016, @11:00AM (#386215) Journal
      You're missing the fact that Netflix doesn't use UDP for anything, they use TCP (under HTTP) for fetching individual chunks and adaptively - from the client side - chose the next chunk to request based on the time it took to download the previous one (switching to lower bitrates if the buffer is getting too empty).
      --
      sudo mod me up