VSee – An Alternative To Cisco (H.323/SIP) For Secure Videoconferencing

A NY Times article shook the video conferencing space when it reported that hackers were able to easily listen in on the board room discussions of major firms. The dark secret of the industry is that almost all existing video conferencing systems ( Cisco, Tandberg, Polycom, Vidyo, Blue Jeans, Radvision ) use the H.323 protocol which has many security flaws

I had the great fortune to be a co-author of the XMPP video standard which is used by Google Talk, Cisco Jabber, IBM Sametime (99.99% of the credit should go to my co-author Peter Saint-Andre).

After I finished this XMPP work, I wanted to create a protocol with security as the number one requirement, so VSee was born. These are 5 ways VSee keeps you secure:

1. End-to-end encryption without a man-in-the-middle listener. In WebEx, Vidyo, Tandberg, and Polycom architectures, your media is sent to a server (also called a video relay or MCU). Although encryption is applied from your computer to these servers, the servers still have full access to your media. In contrast, VSee uses end-to-end encryption where no server, including VSee servers, has the decryption key. VSee uses public/private RSA keys to exchange a 256-bit AES session key with the property that only the endpoints have the AES session key. VSee uses FIPS 140-2 certified 256-bit AES encryption.
2. One port. H.323 systems not only require many ports, but they require dynamic ports. This means if you want to use H.323 across your firewall, you are essentially opening your network to attackers on many many ports. VSee, on the other hand, uses a single port for call signaling and media. The VSee protocol is structured so that only the outgoing port needs to be open because return traffic is always structured as responses to outgoing traffic. This allows administrators to set a policy where if users inside their network are using VSee then their firewall lets VSee traffic securely cross the firewall, however, if users inside their firewall stop using VSee then the firewall will block external port scans.
3. Automatic HTTP/SSL tunneling. VSee prefers to use UDP since it allows higher performance video. However, if the firewall does not allow UDP, VSee will automatically switch to HTTP/SSL tunneling.
4. Cloud Control. A number of VSee customers have specific security policies for their users: the U.S. Congress does not allow recording, NTT Data does not allow file transfer, Kaiser Permanente does not allow unscreened external calls into its users. VSee’s cloud solution allows enterprises to maintain central control of their security policies to a large number of end points even though the service is hosted by VSee. It does this by having VSee clients always connect first to VSee servers in the cloud, where the policies are controlled. The cloud servers determine whether any of these security policies should be applied and enforces them at the VSee client.
5. No-install client. Video conferencing software clients tend to be large and to leave a big foot print on your system. Almost all of them require administrator permissions to install. Once the client software gains administrator permissions, they can severely compromise your computer security: Asking for administrator permissions is like asking you to throw away your operating systems’ natural defenses. VSee is a lightweight client that does not require administrator permissions or installation. Just run the vsee.exe.

H.323 was designed more than 20 years ago, in a time when there were no firewalls or network address translator (NAT) issues, when any computer could send packets to any other computer, and security was not a consideration. The world has since changed and security is now paramount to how people live and work. If you’re looking for security in today’s world, VSee is a simple way to make your video communications secure!

Response from H.323 Committee Chairman Paul E. Jones

Our article above caught the attention of H.323 Committee Chairman Paul E. Jones. Paul is also a Cisco Architect and the driving force behind H.323. We got his permission to publish his response (in italics) to our article so you have a more complete picture of H.323:

1. 1. H.323 systems not only require many ports, but they require dynamic ports.This is largely true, but it is also possible to use a single port. H.323 recommends use of certain ports, and most implementations follow those guidelines. However, some clients use H.245 tunneling, tunnel RAS inside H.225.0 (H.460.17), etc. At least two clients tunnel media inside a TCP connection, as well.
   2. Opening a number of ports increases security risk.That is not entirely correct. If a PC opens 4 UDP flows through a firewall, the “risk” is that somebody might send a mal-formed UDP packet through that port. One port or 4 ports, the same risk exists. Systems are not made more secure by limiting the number of ports used by RTP and to claim that is the case is misguiding readers.
   3. H.323 was designed more than 20 years ago…when any computer could send packets to any other computer, and security was not a consideration.There are several things wrong here. While 20 years is close, H.323 was actually written 16 years ago — same age as SIP. Security issues existed even then, which is why work was started on the H.235-suite of specs after the successful uptake of H.323v1.
   4. H.323 was designed…in a time when there were no firewalls or network address translator (NAT) issuesNAT/FW issues also existed. It is true that H.323 was designed for LAN environments where firewalls were not so much of an issue, but that has never been the only place of deployment. H.323 ALGs have existed for years and years to address the NAT/FW issues.
   5. The world has since changed leaving H.323 in the dust.It’s not reasonable to make claims about a protocol by observing what is deployed and not considering the fact that it’s evolving. It’s like talking about how poor fuel economy is on a car from the 1920s when the car has evolved over the years. H.323 is always evolving and now we have a NAT/FW traversal capability so that H.323 can get through virtually any NAT/FW device, even allowing point-to-point media between two different users behind two different firewalls. See [ITU-T] Recommendations H.460.17, H.460.18, H.460.19, H.460.23, and H.460.24. Those specs do introduce some complexity, but firewalls introduce challenges. These specs provide a means of getting through those firewalls. [However] [a]ny solution to get through NAT/FW devices will introduce complexity. The ICE spec used by SIP is also non-trivial.

As to the future of H.232/SIP, Paul notes:

“I fully agree with you that the existing protocols [H.323 and SIP] have problems. There is not really a lot we can do, except to create something new. What I’m doing is trying build a new system that will bring about a whole new user experience. The project in the ITU is called H.325 (or AMS). It will be a protocol specified in XML (since so many hate looking at ASN.1) and is really a departure from the more traditional telephony models found in the PSTN, H.323, and (yes) SIP…. Whether the world adopts it or not is another matter.”

In our experience, currently deployed Cisco (H.323/SIP) systems are the cause of a lot of headaches for IT, and while there are ways to make it more safe, it is hard to do, so what is actually deployed is more like a ‘car from the 1920s’. However, Paul is 100% correct in that H.323 is evolving, and it is unfair to compare what is currently deployed with what H.323 should be and will be.