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
- 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|
|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|
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.