The 2 Fatal Security Flaws in Polycom RealPresence CloudAXIS

Polycom RealPresence CloudAXISEarly last quarter, Polycom made some exciting announcements about its newest product — RealPresence CloudAXIS, which will be available March 2013. What makes CloudAXIS so exciting is that it allows you to video conference with others without bothering about which service they normally use. As GigaOm tech blogger Stacey Higginbotham explains in one of her articles “someone can now connect people who use Skype, with those on FaceTime or even Facebook all in a browser window.” Furthermore, she adds, “once connected, those users can talk, provide a video and share screens, links and chat.” This is pure brilliance if you are constantly working with people on all different video conferencing services.

Is Polycom RealPresence CloudAXIS Secure?

One of the key sales points, according to Polycom, is that it allows secure communication with Skype, GoogleTalk, and many other popular video calling services. Unfortunately, security simply isn’t possible if it’s not end-to-end.

Endpoint to endpoint security

The problem with Polycom and most other video conferencing vendors is that they lack end-to-end security. All the common products including Google Hangouts, Vidyo, Blue Jeans, WebEx, Lync, Adobe Connect etc. have servers in the middle that listen to your traffic. What I mean is their encryption only goes from the initial endpoint to the server, and from the server to the remote endpoint. The server in the middle has full access to everything you say and do.

Polycom’s Fatal Security Flaws

client-server security holes

RealPresence CloudAXIS has 2 fatal security flaws. The first is the server-in-the-middle issue mentioned above. CloudAXIS servers have full access to your conversation since the servers must decrypt your raw audio, video, screen share, before sending to the other systems. Thus the servers are security holes waiting to be exploited.

The second flaw has to do with the security of the outside video conferencing product. In order for a system to be secure all of its parts must be secure.  If CloudAXIS connects to an insecure system such as Skype or Google Hangout then the entire system cannot be secure. Let me illustrate: If there are 2 doors to your home, and you lock up one door, but leave the other wide open, is your house secure? If there are 2 pipes under your sink leaking water, and you fix one leak, but not the other, is your leak problem fixed?

If you want security, where your conversations are always private and off-the-record, your only choice is VSee!  VSee creates an encrypted tunnel between the caller and callee, using FIPS 140-2 certified 256-bit AES encryption.  We use public private RSA keys to exchange the AES session key such that VSee servers never have access to the AES session keys – and this allows your conversation to be always off-the-record.

Related articles

Follow us on Twitter (@VSee) and Like us on Facebook to hear about the latest from VSee!

Comments ( 2 )
  • milton
    Chirag Katudia says:

    Hi Milton,

    Nice to read your blog and I really got impressed by knowing fatal security flaws in CloudAxis.
    The first point makes little sense that the server is in middle of two entity and nothing can bypass the server but the server is propriety for enterprise and has rights of control (enterprise product’s license agreement). In fact that itself is more secure rather than keeping two end entities in zombie security zone.

    The second point about CloudAxis connecting Skype or Google Hangout, is really invalid statement. Cloud Axis never gets connected to Skype or Google Hangout, it allows Skype or Google users to be invited and connected to Cloud Axis.

    Regarding last pera, if caller and callee as two separate end entities exchanges private – public key and does media encryption then who provides private key to end entities. Does it provided by Server, if yes, then server still holds total control of decrypting media. If not, then I would really love to know the keypare generation and storage in protected environment that too outside the server. That is first violation of FIPS 🙂

    To add more, using FIPS certified library and algorithms makes product FIPS compliant, not FIPS certified. There is long way to go to get product FIPS certified (by SAIC).

    Being in security domain, would always love to read your blogs, clicking on facebook “Like” now.

    Chirag Katudia

  • milton
    milton says:

    hi Chirag,

    thanks for your feedback and clarifications.

    1. suppose you need to have a private conversation, does having your traffic going to a server and that server can see your video in the clear make you comfortable? most of our customers would not accept that kind of security risk. Of course you can make the servers secure, but it takes work and complexity adds potential failure points. A better approach is to enforce end-to-end encryption where NO server can see your video except you and the other party. we do a lot of telemedicine work, where the system must be simple and secure. Every increase in complexity means increase in potential security holes.

    2. the intent of CloudAxis is media integration w/ Skype, even though their implementation is not there yet

    3. VSee generates dynamic public/private RSA keys, the public keys are send to the vsee server via SSL. The public/private keys are used to distribute a AES session key for each call and each user (we use separate AES key for people in the same call to protect secure file send with a single person). we didn’t invent anything new here – but kept the key distribution as simple as possible, so that it can be verified correct.

    4. thanks for the correction on FIPS certified vs. compliant 🙂


The comments are now closed.

%d bloggers like this: