[Red5] Blue5 Bridge

Tue Jun 16 09:16:04 PDT 2009

Yes

Try publisher demo.

23:14:21:689 - Using Adobe Windows Flash Player 10,0,22,87
23:14:26:950 - Connecting to rtmp://localhost
23:14:26:595 - NetConnection.Connect.Success
23:14:28:891 - Can't publish stream, no input device(s) selected
23:14:32:329 - Started video device WebcamMax Capture
23:14:43:235 - Started audio device Virtual Cable 1
23:14:45:750 - Publish - NetStream.Publish.Start
23:14:47:641 - Playback - NetStream.Play.Reset
23:14:47:641 - Playback - NetStream.Play.Start
23:14:47:719 - Playback - NetStream.Buffer.Full
23:14:47:719 - Playback - NetStream.Buffer.Empty
23:14:49:781 - Playback - NetStream.Buffer.Full

From: Andy Shaules 
Sent: Tuesday, June 16, 2009 11:12 PM
To: red5 at osflash.org 
Subject: Re: [Red5] Blue5 Bridge

YES !!!!

EMERGENCY!!

TESTED MANY TIMES!

My hack works....

  ----- Original Message ----- 
  From: Dominick Accattato 
  To: red5 at osflash.org 
  Sent: Tuesday, June 16, 2009 9:09 AM
  Subject: Re: [Red5] Blue5 Bridge

  wait a minute... are you saying that a client can connect to the following address?

  rtmp://localhost/

  as compared to:

  rtmp://localhost/appName

  ???

  On Tue, Jun 16, 2009 at 12:03 PM, Andy Shaules <bowljoman at hotmail.com> wrote:

    Root scope... depth 0x00

    Security call backs are at app scope, depth 0x01.

    WHere would I put it? Do i need to make a bean for root? 

    Currently I have hacked rtmp handler to throw 'scope not found' exception when clients attempt to connect to root scope.

      ----- Original Message ----- 
      From: Dominick Accattato 
      To: red5 at osflash.org 
      Sent: Tuesday, June 16, 2009 8:48 AM
      Subject: Re: [Red5] Blue5 Bridge

      Andy, why would one not use the existing streaming security callbacks to lock that down?

      On Tue, Jun 16, 2009 at 11:41 AM, Andy Shaules <bowljoman at hotmail.com> wrote:

        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

        _______________________________________________
        Red5 mailing list
        Red5 at osflash.org
        http://osflash.org/mailman/listinfo/red5_osflash.org

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

      _______________________________________________
      Red5 mailing list
      Red5 at osflash.org
      http://osflash.org/mailman/listinfo/red5_osflash.org

    _______________________________________________
    Red5 mailing list
    Red5 at osflash.org
    http://osflash.org/mailman/listinfo/red5_osflash.org

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

  _______________________________________________
  Red5 mailing list
  Red5 at osflash.org
  http://osflash.org/mailman/listinfo/red5_osflash.org

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

_______________________________________________
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/a3a52801/attachment.html>