1 Reply Latest reply on Aug 12, 2010 11:26 PM by Michael Thornburgh

    Rendezvous security worries.


      Ok, so I've read up on the basic implementations for Stratus through RTMFP.  I was really worrying about the security vulnerabilities of the rendezvous implementation.


      From my understanding, as it stands right now the Stratus server does not validate the user ID and developer key provided from the client.  What is preventing a malicious user from obtaining a proper developer key and user ID, mimicing any security transcoding of both, and then connecting to stratus while pretending to be the user who's credentials were comprimised?


      I looked through the forums rather quickly and haven't seen any posts discussing any sercurity related issues for the stratus server.  From what I can tell, it appears that the stratus server relies on the client alone to provide userID validation.


      If the stratus server does not provide user ID validation, does anyone have any useful client side implementations they would like to talk about?  Also, does Adboe plan to implement stratus server-side userID validation?


      Again, if Stratus does provide user validation, I apologize for not knowing.

        • 1. Re: Rendezvous security worries.
          Michael Thornburgh Adobe Employee

          Stratus doesn't know anything about "user IDs".  those are purely constructs of your application.  all Stratus knows about is a client's peerID, which is unforgeable (by which we mean it's computationally infeasible to appear to Stratus or another Flash Player with the existing peerID of any other peer).  and a peerID only has meaning for the lifetime of your NetConnection to an RTMFP server (such as Stratus); they cease to exist as soon as you disconnect and can't be recovered or re-used.


          the VideoPhoneLabs and reg.cgi examples are intended to be illustrative of the underlying concepts of P2P communication and mapping application-defined users to peerIDs.  they are explicitly not secure at the "user ID" level.


          i'm not sure what you mean by Stratus "not validat[ing] the ... developer key provided from the client" though.  Stratus *does* validate it, in the sense that the provided developer key must be *a* legitimate key issued by Adobe.


          RTMFP provides some interesting low-level hooks upon which you can build several kinds of sophisticated security.  as i mentioned, the peerID of a Flash Player is unforgeable.  you could register and look them up using a trusted and secure source (HTTPS and application-level username/password).  you can use the secure session nonces (exposed in NetStream.nearNonce and NetStream.farNonce), which are unguessable, unforgeable, can't be observed by a passive third party, and which can't be intercepted without changing them, along with local shared objects and a cryptographic hash function, to build an SSH-like identity continuity system which, while not initially authenticating a user, can be used to prove that "next time" you're talking to the same person as last time.