On 8/21/06, Alex Thurlow <[EMAIL PROTECTED]> wrote: > I currently have a website that streams some flv files through an > swf using progressive http download. Basically, it seems impossible to > keep someone from just saving the flv files when using http streaming. > That's not a problem right now, but we're looking to start making some > copywrited and stream-only material available as flv. I've set up red5 > and had some successful tests, but I was curious as to the protection of > those files when streaming as rtmp through red5. > I have not found any instructions from anyone on the ability to > download flvs if they are streamed from Red5 or Flash media server, but > I was wondering if it was possible. I am also interested in even > protecting the full path to the stream. Our flash player loads it's > playlist from an xml file and I figured that I could use flash's built > in encryption to encrypt that file so only our player could decrypt it. > I'm curious if/how anyone else deals with these problems.
Using RTMP instead of HTTP is definitely going to make it significantly harder to capture the data, but only because there aren't yet readily available tools to do it. If some RTMP based service becomes popular enough then someone will write the tool to make it simple to save FLV streams out of an RTMP connection. Such a tool might be developed anyway for Red5 development as a debugging tool. You're not really going to be able to implement anything more than security by obscurity here. Any attacker has perfect knowledge because they can easily disassemble any of your SWFs and capture all network communication. Encrypting is somewhat silly because in order for the player to decrypt something the key would have to be accessible to the player, which means the attacker is going to be able to get to it. Also, they'll pretty easily be able to determine where to look given that they basically have your source code. Obfuscation helps a little, but only as a small deterrent... it won't stop a determined or experienced person for very long. Chances are you'll spend weeks of your time trying to implement (fundamentally flawed) countermeasures that will probably be broken with less effort than you spent constructing them. -bob _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
