[Red5] Blue5 Bridge
bowljoman at hotmail.com
Tue Jun 16 08:41:37 PDT 2009
Speaking of security....
WHat is the plan to secure the root scope?
As it is now, every red5 server is wide open to abuse because, any one can publish video and shared objects to the root scope without restrictions.
----- Original Message -----
From: Dominick Accattato
To: Red 5 mail List
Sent: Tuesday, June 16, 2009 8:15 AM
Subject: [Red5] Blue5 Bridge
Since the RTMP specification's release, we feel it is necessary to branch out in regards to "securing content". This is mentioned on the RTMP specification page here (http://www.adobe.com/devnet/rtmp/) "developers will be free to use their own technological measures to secure content". However, due to the spec's ambiguous restrictions, I am asking any developers who wish to work on such protocols to not download and or read the specification.
That said, has anyone here heard of Blue5? (http://blue5.googlecode.com)
Now you have :). It's been quite a while since discussions of rtmpe and rtmfp have come up on the list. During that time, these protocols have entered the public arena through several third parties. Now, for the first time, these are being actively developed as a bridge between Red5 and the use of these encryption protocols.
That said, we need some support from the community. These protocols and others should be standardized and we're looking for valid arguments on why they should be. In fact, opening these protocols and building security stacks on top of these should be the goal of both media servers and the Flash Player.
Here is my first argument for the cause:
RTMPS can be used but it incurrs the overhead of typical encyrpted http
traffic. That's why RTMPE is so important because it is encrypted at the
RTMP level and doesn't incur the cost of http traffic overhead.
A much better solution would require the following.
1. The client authenticates with a server
2. The server generates a public/private key based on a valid session and
associates it with the client
3. The server sends down a private key through ssl based on a valid
4. The client uses this private key to connect to the server
5. The server validates the key
6. The server starts streaming using the public key's encryption which
can only be decrypted by the private key
I first mentioned this on the FMS mailing list in hopes to reach out to Adobe and work on a spec for this type of functionality. Hopefully with community support and open letters and standards, we may be able to extend the security stack.
Comments, thoughts, suggestions?
CTO & Senior Engineer
Red5 mailing list
Red5 at osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Red5