Skip to main content
Known Participant
December 27, 2011
Question

How to protect hls stream? (from others serving "my" m3u8's on their site...)

  • December 27, 2011
  • 2 replies
  • 7258 views

Situation: live hls multi-bitrate, livepkgr, m3u8 served on "my" website

(iOS user gets on "my" page, clicks on the m3u8 link and views the live content - no problem there...)

What is stopping other to use my playlist on their website and offer the same service with "my" infrastructure?

Nothing?

If i use protected hls - i still will be giving keys to all the viewers - both those who came through my website and also all others - so not much help there with this particular question - right?

This topic has been closed for replies.

2 replies

pleqtron
Inspiring
May 21, 2015

Hej there, I have the same situation right now and need some help as well. Unfortunately adobe does not share any further informations regarding their server architecture or any non-out of the box features, which is really annoying. Does anybody has a solution for that so far? Help would be really appreciated! If I will find a solution, I will post it here as well! Thanks

Adobe Employee
January 2, 2012

Currently protected HLS only garuntee (flexible feature) that only valid ios devices can play the stream. But yes, that doesn't solve your problem. You may like to add some sort of authentication  in key delivery part. For example, you may write ios-application to re-write key delivery URL and add some query token to it in NSURLProtocol class. And on apache side, you may check validity of URL sender before request is picked up by the hls module.

This is just a direction.. Though we are looking for some inherent solutions in this direction..

nnmkAuthor
Known Participant
January 2, 2012

Hi, thank you for your reply, can you please be more specific on this:
"...on apache side, you may check validity of URL sender before request is picked up by the hls module..."

(how?)

Thank you in advance.

Adobe Employee
January 3, 2012

Though it is easily discoverable the hackers but still a direction:

1. For example, in you client app inside NSURLProtocol you may change the key URL from https://example.com/hls-key/liveevent.key to https://example.com/my-app-hsl-key/liveevent.key

Now, inside apache conf, you may change the location directive hls-key to my-app-hls-key.. In this way any key request that comes as former URL will be reected by the module, while later will be passed.

Since later key requests will only from your client app (which re-write key url inside app using ios NSURLProtocol class) they will succeed as apache confs are configured to accept them while former once are failed.

However this can be traced and replicated by others too..

If you want more secure way then, you may like to send some cookies with the key url as query parameter (again you will have to write your custome app to do that).. On apache side you may write your own module which first authenticate the cookie then redirect the "query parameter stripped key url" to the mod_hlshttp.so..

Why am I only talking about authenticating the key URL not the m3u8 or ts because key url is on https which should always hit the origin.. m3u8 or ts are normal http and can be served from the cache..