Secure pseudo-streaming flv files

Question

We use RTMP to secure stream media content through Wowza and it works like a charm. Wowza is really strong and robust media-server for a business purpose.

But we met a problem, it's getting bigger every day for us. A lot of new customers can't use RTMP by their firewall rules, and it's a problem to deliver a business media content for them. But everybody has no problems with http pseudo-streaming or just progressive, like it does youtube or vimeo. So we should do the same, but provide secure links to pseudo-streaming traffic, to prevent a direct download by stealing the links.

We use few servers, one for Rails app, the second for DB, and third as Wowza media server. My thinking is to setup nginx on Wowza media server and configure to pseudo-stream media originally files (in the same filesystem that Wowza uses to stream through webcam capture).

Can you suggest to use nginx with http_secure_link_module and http_flv_module modules? Another idea by my colleague is to build a tiny application on Wowza side to get encrypted links and translate it to local file system, then get access to files through X-Accel-Redirect and check authentication via direct connection to DB.

Thanks a lot

Answer 1

I have found a solution, let me share with anyone interested in it.

First of all, my constraints was to use the minimum tools as possible, so ideally to have built-in module in web-server only, no upstream backend scripts. And I have a solution now.

  server {
      listen       8080 ssl;
      server_name  your_server.com;

      location /video/ {
        rewrite /video/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.flv$ /flv/$3.flv?st=$1&e=$2;
      }

      location /flv/ {
        internal;
        secure_link $arg_st,$arg_e;
        secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri;

        if ($secure_link = "") { return 403; }
        if ($secure_link = "0") { return 403; }

        root /var/www/;
        flv;

        add_header  Cache-Control             'private, max-age=0, must-revalidate';
        add_header  Strict-Transport-Security 'max-age=16070400; includeSubdomains';
      }
}

The real flv files located into "/var/www/flv" directory. To encrypt the URL on Ruby side, you can use that script:

expiration_time = (Time.now + 2.hours).to_i   # 1326559618
s = "#{YOUR_SECRET_PASSWORD_HERE}#{expiration_time}/flv/video1.flv"
a = Base64.encode64(Digest::MD5.digest(s))
b = a.tr("+/", "-_").sub('==', '').chomp    # HLz1px_YzSNcbcaskzA6nQ
# => "http://your_server.com:8080/video/#{b}/#{expiration_time}/video1.flv"

So the secured 2-hours URL (you can put it into flash-player) looks like:

"http://your_server.com:8080/video/HLz1px_YzSNcbcaskzA6nQ/1326559618/video1.flv"

P.S. Nginx should be compiled with following options --with-http_secure_link_module --with-http_flv_module

$ cd /usr/src
$ wget http://nginx.org/download/nginx-1.2.2.tar.gz
$ tar xzvf ./nginx-1.2.2.tar.gz && rm -f ./nginx-1.2.2.tar.gz

$ wget http://zlib.net/zlib127.zip
$ unzip zlib127.zip && rm -f zlib127.zip

$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.30.tar.gz
$ tar xzvf pcre-8.30.tar.gz && rm -f ./pcre-8.30.tar.gz

$ wget http://www.openssl.org/source/openssl-1.0.1c.tar.gz
$ tar xzvf openssl-1.0.1c.tar.gz && rm -f openssl-1.0.1c.tar.gz

$ cd nginx-1.2.2 && ./configure --prefix=/opt/nginx --with-pcre=/usr/src/pcre-8.30 --with-zlib=/usr/src/zlib-1.2.7 --with-openssl-opt=no-krb5 --with-openssl=/usr/src/openssl-1.0.1c --with-http_ssl_module --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --with-http_stub_status_module --with-http_secure_link_module --with-http_flv_module
$ make && make install

Answer 2

JW player and Flowplayer will automatically fall back to RTMPT (over HTTP) when an RTMP connection is unsuccessful, and Wowza makes both available. I've encountered port 1935 blocked at several locations, and the fallback to RTMPT over port 80 generally works. The caveat there, of course, is that you have to have Wowza listening on port 80 (in the VHost.xml where 1935 is defined, change it to 80,1935), and that precludes having any kind of web server listening on the same port.

Answer 3

We use Wowza with port 80 with our clients