Strongly Connected Components

As software developers we should spend more time studying the (relatively few) examples of systems that are well built: elegant, robust, efficient, cleanly designed and implemented. It is not only a wonderful way to learn from the masters, but also a very gratifying experience and a source of intellectual pleasure and stimulation.

Last week we had some time on our hands and decided to spend it poking and studying the security model behind Netflix’s video-on-demand service (“Watch Instantly”). We wanted to learn about the constraints they enforce, the mechanisms they use, and the ways in which those constraints and mechanisms affect performance and the user experience. We were not surprised to discover that Netflix’s security framework is as robust and well designed as the developer APIs that they provide.

We share here what we learned, hoping that others can benefit from it as well. (But we also want to make it clear that what follows is simply our understanding of how things work, which does not necessarily map one-to-one to they way things actually work. We were meticulous in our study, but because we were basically reverse-engineering their process, there certainly will be some misunderstandings and things left out).

The full report is available in PDF format, along with a text file with a complete dump of the messages exchanged between the Netflix player and the Netflix servers. We include below a copy of the first two sections of the report, describing the methodology and providing a general overview of the problem and the solution.

A brief introduction and methodology

Netflix’s video-on-demand service offers its subscribers the possibility to watch over 12,000 titles online through their Internet connection. It works on a PC/Mac with a browser-based player created by Netflix (written in Microsoft’s Silverlight), or via a Netflix-ready external player such as a Roku Box, an Xbox 360, the Samsung Blu-ray player, or any other Netflix-enabled device.

Both kinds of players (browser-based and external) communicate with a set of Netflix servers that enforce security constraints, provide playback information, and stream the video files to the player. That communication is based on the HTTP and HTTPS protocols, and the message exchange can be observed at different times during playback and be used to make inferences about the kinds of mechanisms that Netflix must have in place in order to provide a secure video experience.

Our analysis was centered on the browser-based playback experience. We created a new Netflix account and observed the message exchange using Firefox and Tamper Data, a Firefox plug-in that traps HTTP and HTTPS requests and responses to/from the server and displays their content, headers, and other useful information.

We also briefly studied the behavior of external players. Precisely because those interactions occur outside of a web browser, we were unable to use any high-level tools such as Tamper Data to analyze the message exchanges. Instead, we had to rely on Unix packet sniffers (mainly tcpdump and Wireshark), which provide less detailed information and, in particular, make it much harder to decrypt HTTPS messages (especially since in these cases the key is locked inside the device!). Even though we were unable to analyze the messages as deeply as for the browser-based players, we still were able to detect many similarities and a few differences between browser-based and non-browser based players, and we detail them at the end of this report.

Security requirements, control mechanisms, and general architecture

Netflix concerns, from a security point of view, are:

• Only users with the correct (unlimited) plan can access content
• Users don’t share their account information with others
• Videos are only accessible from within the US, due to licensing restrictions
• Video content cannot be redistributed and played at a later time

Those restrictions are enforced by a set of coordinated mechanisms:

• Request user authentication before playing the video
• Allow a maximum of six playback devices (browsers, Roku, etc.) per account
• Reject requests that come from IP addresses outside of the US range
• Encrypt the video content
• Provide unique decryption keys per movie and device

The security checks take place over the duration of the playback experience, and are delegated to several different Netflix components and servers, each with distinct responsibilities. The following diagram shows the steps required to play a video on Netflix (slightly out of order, for clarity), the different servers involved in each process, and their respective responsibilities.

Security responsibilities are also distributed on the client side, between the browser (which stores and sends cookies), the Netflix player (which follows the playback and security protocols described above), the Microsoft Silverlight player in which the player is implemented (which prevents cross-site scripting and makes sure that the player only talks to Netflix servers), and a proprietary Microsoft DRM component (which gets an individualized key for each player and coordinates with the License server to acquire keys that are unique to the movie and the player).

This architecture provides several advantages:

• Because all playback devices are registered and associated with an account, Netflix can prevent abusive users from sharing their credentials with others; if they do so, their account will quickly run out of allowed devices. (Note that here a device corresponds to a user on a PC/Mac, or a Roku, Blu-ray, etc. external device. Two browsers on the same machine/user are one device, but two users on the same machine are considered to be two separate devices.)
• The encryption of video files ensures that only players with knowledge of the key and the decryption algorithm (proprietary Microsoft technology) can view them.
• If one of those decryption keys is compromised then the security threat is minor, because the keys are individualized and can only be used by one player.
• Thanks to this distribution of tasks, different servers and client components can focus on the particular constraints that they have to enforce, and assume that other constraints are checked somewhere else. At the same time, and because information is shared between the different servers (through cookies and extra headers in the HTTP requests), security on each of these components can be tightened as desired, if/when Netflix detects abuses or security breaches at a particular point.
• Because all communication takes place using well known HTTP and HTTPS protocols, Netflix has been able to easily provide their video-on-demand service to non-browser devices (such as Roku or Xbox 360) simply by implementing a player on the client side. All these non-browser players communicate with the same servers and follow more or less the same protocol as the browser-based player.
• Since all authentication and authorization checks are performed before playback begins, and since the content of files is encrypted, the streaming of the video files can be easily delegated to CDNs, increasing delivery speed without compromising security.
• Finally, because the playback experience is controlled through Netflix’s proprietary player, the enforcement of security constraints can be hidden almost completely from users. All they are required to do is log into the site using their account information. The registration and authentication of the device, and the acquisition of playback licenses, all happen behind the scenes.

For a step by step walkthrough of a typical playback session, you can download the full report (18 pages, skip the first two sections), and also get a text file with a complete dump of the messages exchanged (remove .doc extension, which WordPress forced us to use).