Wowza Community

Secure Streaming?

Hello,

I’m trying to figure out the best way to secure my rtmp streams. When I was trying Amazon Cloudfront, we were able to use signed urls which worked pretty well considering there was no way for a thief to access/steal our key pair.

The problem is, with our large member base, cloudfront simply does not have the performance we need.

So now we’re here with Wowza, which is working great. But I’m a bit confused on how to go about properly securing our vod rtmp streams.

So far, I have done the security token portion of securing our player (set up the token in wowza, compiled the token into the jw player swf) and it’s working well, but my concern is: what’s to keep a thief from simply downloading our player.swf and then using it on their own site?

We used to use red5 server as well, which had a security plugin that would allow only certain hosts/ip addresses to connect via rtmp, which would be another solution if it were possible to do in wowza.

I also looked at this guide: https://www.wowza.com/docs/how-to-protect-your-swf-files-by-loading-them-from-wowza-media-server which sounds nice on theory, but from where I stand, the documentation is incomplete as I’m not a flash/flex/whatever else developer so some steps are completely lost on me.

So I guess my overall question is, how would I go about actually protecting our vod streams? I’m not so concerned with protecting the content from being ripped as we provide downloadable media files as well… but moreso to keep the general public and pirates from being able to use/download/share our media.

I have dealt with many intelligent thieves.

If you compile(and encrypt) the Token inside JW/Flow, etc… it can still be decompiled+decrypted, in less than 2minutes, with a program freely available.

If you lock down by domain(s), this w/ your token can be circumvented/ripped with rtmpdump.

I have come to understand, there is no way to protect streams with Wowza.

Big sites seem to use Adobe and Flash Access to acheive succesful protection. I have experienced this first hand with NFL.com’s PreSeason games that I bought.

Example:

I loaded up stream on 2 PC’s on same network, WAN IP, etc…

Play on 1st one, ok. Go to 2nd PC, it plays fine. Then within 2mins, the stream on 1st PC dies. If I go to play again, then stream on 2nd would die.

Would be nice to have a ready to go package for securing the streams, tied together perhaps with a username.

I’ll give you an example of a working package.

One that I used in the past was the ‘KH’ branch of Icecast. I did live video streaming (encoded+player) w/ WinAmp+H.264, etc…

Users then watched with a URL like, icecast://hostname/mount&username=abc&pass=123

If they shared it with a friend, it would not work. Unless of course their 1st connection was disconnected.

For various reasons, we have moved on, but the protection was great. No tokens, no domain lock, simple & effective.

I have seen various “code” on these forums relating to authenticating to a MySQL DB, etc… but what would be great is a turn key package like the IceCast method.

Would love to have something like rtmp/rtsp/etc…://server/live/event&username=abc&pass=1234

That auth’s to a simple MySQL db w/ cleartext username+passwords to start. Then after could be developed for salted & doubled salted used in things like Wordpress, VBulletin, etc…

A system like this could be sold for $1k+ easy.

Oh and of course any stream can be screen captured. Some of mine are being captured, and restreamed to other places. No protection will stop that.

Anyway, thats my rant.

What am I doing ?

Summary, I’m moving to an IP based lock using FreeBSD’s pf. The script is already done.

Users are able to submit up to X (3 in my case) ip’s, stored in a MySQL db. This gets written to a file with 1 IP per line.

pf (or any firewall) then parses that for its allow list to :1935, etc… (every 1/2mins)

Wowza Edge’s do a fetch every 1min to get latest list, and same parse.

So while I love Wowza, I hope that some turn key applications/plugins come out. Since current method’s are all defeatable.

There is a certain point of view that the best security options are the creative custom solutions using varied implementations of concepts like tokens and expiring URLs.

Richard

Take a look at this example:

https://www.wowza.com/docs/how-to-limit-the-number-of-viewers-to-a-stream-modulelimitstreamviewers

Richard

There is no example exactly like that, but here is a starting place:

https://www.wowza.com/docs/how-to-override-play-to-control-access

This example shows how to use JDBC connection to a database and do authentication when user connects with RTMP client, which you will probably want.

The way to store data per connection in the onConnect handler that you can retrieve in the play command is like this:

in onConnect:

client.getAppInstance().getProperties().setProperty("var", "val");

Later in the play command

String var = stream.getClient().getAppInstance().getProperties().getPropertyStr("var");

Richard

One that I used in the past was the ‘KH’ branch of Icecast. I did live video streaming (encoded+player) w/ WinAmp+H.264, etc…

Users then watched with a URL like, icecast://hostname/mount&username=abc&pass=123

If they shared it with a friend, it would not work. Unless of course their 1st connection was disconnected.

For various reasons, we have moved on, but the protection was great. No tokens, no domain lock, simple & effective.

This is exactly what I’m looking for in the Wowza solution. I have also seen tutorials here on Wowza that show how to authenticate against MySQL DB but I wish they included a way to limit a user to 1 stream simultaneously.

Hi Richard,

Thank you for the link. However, what I’m looking for is a little different. I am looking to limit the user to 1 simultaneous stream, so that if viewer is watching a stream and then gives his credentials to someone else, I want to restrict that account (or IP address, for example) to only be able to view 1 stream at a time.

I hope I’m being clear in describing this.

Please let me know if something like adding username/password parameters (even if clear over the net) is possible.

Thank you!