Wowza hotlinking re-publishing and re-streaming protection

When you are streaming some media data, you always have a risk of being re-published somewhere else via hot-linking. So if you have exclusive payed content, you're loosing money. WMSPanel has a core functionality for Wowza links re-publishing (or, hot-linking) protection. It's available as part of Paywall solution for Wowza and it supports all protocols which Wowza handles. This includes RTMP, RTSP, HLS, SmoothStreaming, HDS and DASH.

Having some small changes in UI part and Wowza agent installed on Wowza server you can protect your business from link re-publishing and complicate your content re-streaming including domain lock for hotlinking.

UPD: Read the full workflow description in our paywall hotlinking protection page.

Commonly you have some web pages with video links like this:

rtsp://ec2-test-ip.compute.amazonaws.com:1935/live/Stream1

Then your web server script calculates hash from IP, URL, server time, secret key, valid interval and adds this hash to initial URL. e.g.:

rtsp://ec2-test-ip.compute.amazonaws.com:1935/live/Stream1?wmsAuthSign=c2VydmVyX3RpbWU9NS80LzIwMTIgODozMzowNSBBTSZoYXNoX3ZhbHVlPXE3MjN6aEVmdGFUOUJoWjBQTmw1TVE9PSZ2YWxpZG1pbnV0ZXM9MjA=

So your valid customer will open the link and nothing will be different from non-protected URL. If somebody copies the link as passes it to anyone else, this 3rd party will not get any data.

WMSPanel platform handles all processing for you so all you see as a user is a big link. All mechanics are split by 2 parts and hidden away.


Server side

Our solution requires small changes within a code that generates your pages. Take a look at this PHP example below.

<?php
$today = gmdate("n/j/Y g:i:s A");
$initial_url = "rtsp://ec2-test-ip.compute.amazonaws.com:1935/live/Stream1";
$ip = $_SERVER['REMOTE_ADDR'];
$key = "defaultpassword"; //this is also set up in WMSPanel rule
$validminutes = 20;

$str2hash = $ip . $key . $today . $validminutes;
$md5raw = md5($str2hash, true);
$base64hash = base64_encode($md5raw);
$urlsignature = "server_time=" . $today ."&hash_value=" . $base64hash. "&validminutes=$validminutes";
$base64urlsignature = base64_encode($urlsignature);

$signedurlwithvalidinterval = "$initial_url?wmsAuthSign=$base64urlsignature";

?>

Here, $ip is a client IP address, $validminutes is a time while this link is still valid, $key is set by you (see WMSPanel part).
New variable may be used for writing an anchor link. But we recommend using techniques described in our blog post about hiding your links from automatic discovering.

All code snippets can be found in our github repo for Wowza code snippets. There you can also find a Java and C# snippets, along with sample for JWPlayer. Please note that RTMP protection requires a bit different solution. Check out RTMP protection example.

All you need to do after creating a server code is to set up protection settings on WMSPanel side.

Our authentication Wowza plugin will calculate hash from IP, URL, secret key etc of an incoming request, and compare it with hash value in the URL. If they match then everything is OK. If they don't then request will be rejected.

The "secret key" is a private element that guarantees that both web page and Wowza can generate the same hash, so even if a violator knows the basic hashing procedure elements (IP, URL etc.) he will not be able to generate the same hash.

WMSPanel side

WMSPanel provides a complete protection management on the WMSPanel side. You can set up any number of WMSAuth groups and each of those groups may be set up for different Wowza entities and protocols. So common procedure for adding Wowza support of re-publishing and re-streaming protection is to add WMSAuth group and then define a set of protection rules.

Please read this blog post describing general WMSAuth usage.

Once you want to define WMSAuth rule, you must define the following elements:

• Password - a secret key that would be known for both web server and Wowza.
• Time tolerance. Wowza server and web server may have different time. It may be differ by several seconds but that would be enough for this whole chain to be incorrect. So we've introduced this maximum time range that is allowed for both servers to be un-synchronized. Usually it's about 60-90 seconds.
• Protocols - which of Wowza supported protocols is this rule applied. You may want to protect particular protocol while other protocols might have another protection scheme.

Adding new hotlinking re-streaming protection rule.

Having the groups and the rules being set up, you get control over your content's links appearance. This is working for all Wowza client types with any browsers and media players.

Read more about integration of WMSAuth re-streaming protection solution for Wowza and domain lock for hotlinking.

WMSAuth is also a big part of Pay-per-view framework for Wowza Media Server.

So if you're interested in Wowza protection, you can sign up to try WMSPanel free of charge and contact us to enable WMSAuth functionality.

Please check FAQ and Troubleshooting section for any problems resolution or questions.

The hot-linking re-streaming protection is also available for Nimble Streamer, the light-weight HTTP streaming server for HLS, Smooth and progressive download. WMSPanel is an official GUI for Nimble Streamer. It may be controlled via WMSPanel GUI and it comes free of charge.

Related documentation

Paywall for Wowza and Nimble Streamer, Geo and IP range restriction for Wowza, Nimble Streamer HTTP hotlinking protection, Hotlinking protection with stream-based signature, Nimble Streamer geo-location restriction, Domain hotlinking protection, Integrating WMSAuth to your website RTMP protection example, Pay-per-view for Wowza Media Server, github code samples, Adding Dispersa server IP range to allow list