Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
The Netflix Open Connect team announced earlier this week that it would be using Transport Level Security. Here’s a look at its innovative approach to protecting viewing data at scale.
In a blog post earlier this week called “Protecting Netflix Viewing Privacy at Scale,” the Netflix Open Connect team detailed the innovative approach the company used to implement HTTPS to encrypt the transport of the video content to Netflix customers. Beyond the technical innovation described, the blog post reveals how video streaming services and other commercial sites must go beyond content DRM to truly secure viewer privacy.
Contents
TLS, SSL, and HTTPS
What is HTTPS and how does it relate to the Secure Sockets Layer (SSL) and and Transport Level Security (TLS)? Briefly, SSL is a technology originally developed by Netscape for establishing an encrypted link between a web server and browser. Because of trademark issues with Netscape, the version after SSL 3.1 was called TLS 1.0.
In 2014, a vulnerability called POODLE (Padding Oracle On Downgraded Legacy Encryption) was discovered that rendered SSL and even TLS 1.0 potentially ineffective against hackers. TLS 1.1 was introduced to avoid POODLE, but as a result, all versions of SSL and even TLS 1.0 are considered insecure. This started a major transition away from SSL and towards TLS 1.1. To complete the picture, HTTPS, or Hypertext Transfer Protocol Secure (HTTPS), is a technology that combines HTTP with SSL or TLS, though TLS 1.1 is obviously preferred over SSL or TLS 1.0 at this point.
Back to Netflix
To be clear, Netflix has long deployed DRM to prevent piracy, and it protects customer data during account login and any administration via HTTPS. However, the actual transfer of the movie data was not protected, so any information contained in the communications between the server and client could be accessed by hackers, or by network administrators or ISPs. This information could be used to determine which content the viewer was watching, and perhaps other details.
The industry has been moving towards protecting all information communicated on the web for precisely this reason. As stated on https.cio.gov, an HTTPS support forum for users with a .gov or .mil address, “Every unencrypted HTTP request reveals information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace. Today, there is no such thing as non-sensitive web traffic, and public services should not depend on the benevolence of network operators” (emphasis in original).
The problem for Netflix was scale. Over the last four years, the company has boosted throughput on their Open Connect Appliances that store and serve Netflix content from 8Gbps to 90 Gbps. A portion of this performance boost relates to the ability to transfer movie data directly from the file system to the network socket without routing the data through the application layer of the server. This is shown in Figure 1.
Figure 1. Transferring movie content directly to the network socket is more efficient than routing it through the application layer of the web server.
However, Netflix’s original implementation of HTTPS routed the data through the web server which performed the HTTPS level encryption (Figure 2). In an October 2014 email to W3C public listservs, Netflix director of streaming standards Mark Watson reported that initial trials showed a capacity hit “of between 30-53%.” Watson continued, “This is not a capacity hit we could absorb in the short term and we estimate the costs over time would be in the $10’s to $100’s of millions per year. Our current rough estimates indicate that, over the coming year we could implement additional software optimizations which could potentially reduce the size of this overhead by around 30%.” In other words, we’d like to implement HTTPS, but as things currently stand, it’s too expensive.
Figure 2. Performing HTTPS encryption in the web server was relatively inefficient.
As described in the latest blog post and accompanying papers, to restore operational efficiency Netflix created a hybrid scheme that encrypted the movie data during the transfer from the file system to the network socket (Figure 3). This eliminated the routing through the application layer of the server, “increasing performance by up to 30%,” and delivering on Watson’s promise. As a result of this improvement, Netflix plans to continue rolling out HTTPS to those clients that support it.
Figure 3. The technical workaround implemented by Netflix to restore operational efficiency
Industry Support for HTTPS
Netflix isn’t the only streaming video service protecting content delivery with HTTPS. On August 1, 2016, YouTube announced that over the previous two years, the company “rolled out encryption using HTTPS to 97 percent of YouTube’s traffic.” As with Netflix, Google reported that performance was an issue, but that with hardware acceleration for encryption, “we were able to encrypt virtually all video serving without adding machines.”
The YouTube announcement links to a page titled Is TLS Fast Yet, which discusses performance issues like CPU and latency and how to most efficiently deploy TLS and HTTPS. The YouTube post also links to the Google Transparency Report, which discusses how HTTPS/TLS is a priority for Google and reports that the company “has been working hard toward our objective of achieving 100% encryption across our products and services.”
The net/net is that if you’re a streaming publisher, protecting movie transfers to consumers via HTTPS is becoming table stakes for staying in the game. For example, in discussing Netflix’s move to HTTPS, Ars Technica reported that “The move now leaves Amazon as one of the most noticeable no-shows to the web encryption party.” If you’re a video consumer concerned about privacy, HTTPS for movie transfers should also be on your list of must-have features when considering which streaming services to sign on to, or retain.
