Security Overview of Wowza Streaming Engine®

In this article I am going to give you a brief overview of the various stream protection / stream security tools and technologies that I know about. When I was first trying to add protection to my first online video streams, I was a bit confused of the various levels and approaches offered by the different streaming protocols, Wowza addons (like DRM) and Wowza modules (like ModuleRefererValidate) and other authentication mechanisms (like SecureToken).

First off I would like to state something that might be a bit disappointing: there is no perfect way to protect your video content from being re-streamed or stolen. There are ways to protect yourself against some trivial abuses, like hotlinking, embedding your stream in external sites, sniffing video frames from the wire, but as you have no control over what your client eventually does with the received content. As a brute-force solution he or she might just simple re-stream/record your content using a mobile phone's camera and UStream.

What is "Wowza security" then?

Definietly "wowza security" is a popular keyword that people Google for. I am wondering what they want actually. Theoretically they might want to prevent people from doing one of these things:

  • Prevent people from embedding their live or video-on-demand (vod) streams into other websites, by pointing to their own Wowza server instance. This is bad, because people would not visit their own, dedicated website, not click on their advertisements, etc.

  • Prevent people from being able to watch the stream if they did not log into their site / register / pay / whatever. In this case the connection comes from their own site in a sense, but they want to set extra rules before anyone can watch the stream.

  • Protect video streams on transport level, so anyone who is sniffing network traffic, should not be able to capture and display the video

  • Prevent people from publishing streams with their Wowza instance (only with password / only from whitelisted domain or IP)

  • Blacklist or whitelist player IP addresses

If one searches for solutions for the above scenarios, the following solutions are available:

  • Wowza StreamLock AddOn Network Security
  • Wowza MediaSecurity AddOn: this used to be a separate add-on until version 3.1.2, later this has been incorporated into Wowza Streaming Engine®.
  • Wowza StreamNameAlias: URL Security: I mention it here for completeness only, however I don't see any security provided by this module
  • Configuration options available out-of-the box in Application.xml, such as <RTP>/<Authenticate>
  • Wowza Wrench: a Wowza module which on one hand enables you to flexibly integrate your Wowza application into your website's authentication and authorization mechanism, on the other hand offers features like pay-per-minute or pay-per-view
  • ModuleRefererValidation: This is part of the free module collection supported by Wowza. It is said to give you domain based restriction (see Vulnerabilities)
  • [ModuleHotlinkDenial]: this module allowed you to restrict only Flash based players to a given domain. As Flash based players are declining, this module lost a lot of its importance
  • ModuleSecureToken aka. SecureToken: its a challenge based security mechanism that you can use together with Flash-based players to prevent other players from connecting to your stream. Its vulnerable because the shared secret has to be compiled into or delivered along the swf file. (see Vulnerabilities). The SecureToken mechanism is described here.
  • STi Streaming Protection for Wowza: this is a 3rd party product developed by Solid Thinking Interactive. It generates tokens into a database for your streams, giving you a mapping between your streams and those tokens. These tokens are then used to construct masked, protected URLs for each stream, with the option to make any of these tokens invalidated after one use.
Core Wowza (MediaSecurity AddOn) StreamLock (RTMPE/RTMPS or HDS/HLS over HTTPS) Module Referer Validation Module Secure Token Module HotlinkDenial Wrench
Network traffic sniffing Yes No No No No No
HTTP players connecting from other domains No No Yes No No Yes
Flash players connecting from other domains No No No No Yes Yes
Foreign flash players connecting No No No Yes No Yes
Black or whitelist players by IP Yes No No No No No
Black or whitelist publishers by IP Yes No No No No No
Authenticate players No No No No No Yes
Authorize players No No No No No Yes
Restream with screen capture No No No No No No

Security and Streaming Technologies

'Yes' means that the module is applicable for the technology, however you need to consider each security scenario separately.

Module / Tool RTMP (Flash) RTP HTTP-based streamers (Cupertino, San Jose, Smooth) MPEG-DASH
Wrench Yes Yes Yes Yes
StreamLock AddOn Yes Yes Yes Yes
ModuleSecureToken Yes No No No
ModuleHotlinkDenial Yes No No No
ModuleRefererValidation No No Yes No

Known vulnerabilities

  • SecureToken: the shared secret is hardcoded into the SWF file, which is fairly easy to decompile and the secret is compromised. It is considered as security-by-obscurity. This fragile approach is said to be secure by the documentation of JW Player and Flowplayer. This official article says that "To get more security (compared to configuring the token in clear-text Javascript - wtb) you can compile the token value into the plugin SWF." Question: do you think that hardcoding a value into a binary file makes it any more secure?

  • ModuleRefererValidate: this module relies on the HTTP referer header sent by the browser when a particular 1 pixel image is loaded by the webpage. This event makes the session valid for a configurable period of time, if the HTTP header contains one of the allowed domains. This is a very fragile security mechanism, which can be spoofed by proxy servers and free browser extensions. Using referer field for authentication or authorization is not recommended by the Open Web Application Security Project

  • Wrench: the tokens are best transferred to the client using a secured transport, e.g. use HTTPS. This prevents people from sniffing your token and use that before you would. For sites without transport level security, the token checking mechanism can offer IP checking and token expiration, but these still leave attack surface in certain conditions, e.g. token being compromised over the wire behind the same router.

This article is under construction. Corrections, questions, comments are very welcome.


Update (2014.09.29): Wrench now allows you to black and whitelist clients based on their User-Agent strings. This is obviously not a serious security measure measure, but gives some protection against the basic restream attempts.

Hi I want to user wrench box to protect my video from download, but i am confused to implement wrench box tool in php so plz help me.

Is it possible to use wowza streamlock addon and wrench in conjunction?

I need to look into that. Can you contact me via email?

How do I prevent people from viewing unauthorized content. Eg,

User1 has access to file k234klk234k3243243.mp4
user2 has access to file 234kmml324kjlk32432.mp4

User1 plays his file, look over user2 and copy the filename and use his own secure token. How do we really limited each token to a particular filename??

You can store token-filename associations in your database and use the "wrench.connect.authorization.sql" to check that the intended stream (file) matches the token. You can also use this without database, by using "wrench.connect.authorization.url".

Write new comment