[Red5] Blue5 Bridge

[Andy Shaules]

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


  Community:

  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
       logiin
       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? 

     

    Dominick Accattato
    CTO & Senior Engineer
    www.infrared5.com
    315.717.2818 





------------------------------------------------------------------------------


  _______________________________________________
  Red5 mailing list
  Red5 at osflash.org
  http://osflash.org/mailman/listinfo/red5_osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090616/683a58bf/attachment-0001.html>