Verto - WebRTC and FreeSWITCH Get Hitched

Unless you've been hiding under a rock you know that WebRTC is posed to be the next big thing in real time communications.

If you're familiar with the technical details of WebRTC you also know that WebRTC doesn't mandate a signaling protocol - that's left up to well, whoever. For many of us coming from a SIP/telephony background it's made the most sense to use a signaling protocol we all know - SIP.

WebRTC makes extensive use of WebSockets and this combined with various JavaScript SIP libraries (sipml5, sipjs, jssip, etc) allows you to do call control using SIP from a browser to a remote system over WebSockets. This assumes, of course, that the remote system supports SIP over WebSocket transport. Then there's also the matter of implementing the various requirements for WebRTC media support such as ICE, STUN, DTLS, SRTP, etc. In short, implementing full WebRTC support is no small task.

Over a year ago I worked with the FreeSWITCH developers to get support for this approach to WebRTC added to FreeSWITCH. As usual, Tony and team delivered a very impressive result - the ability to use the aforementioned JavaScript libraries to call into a FreeSWITCH system using audio, video, or both - all from your browser! Of course once you were connected to a FreeSWITCH system all of the existing functionality was available to you. Conferencing, bridging to existing/legacy endpoints, etc. It wasn't a stretch at all to connect from Chrome using ICE, SRTP, OPUS, and SIP over secure WebSocket and then bridge to an endpoint using SIP over UDP and G729 (or even a PRI)! It boggles the mind to consider what is happening to the audio alone in this scenario - encrypting/decrypting, transcoding, and resampling. All magically and masterfully handled by FreeSWITCH.

One of the most interesting aspects of WebRTC is the ability to develop applications using the full power of the web and the browser environment. For years now we've seen WebRTC sample applications emerge demonstrating just how easy and powerful the peer-to-peer capabilities of WebRTC are. Some of these even demonstrate increasingly complicated "multi-peer" scenarios involving multiple parties.

Where does FreeSWITCH fit with all of these new-fangled web technologies? First, I've already mentioned the ability for FreeSWITCH to bridge to endpoints on different networks. Even though WebRTC shares some standards with these legacy endpoints, direct communication or even media will almost certainly never be possible. Requiring DTLS and SRTP virtually guarantees that.

FreeSWITCH also hosts many powerful applications - including voicemail, conferencing, and even entire custom applications written using LUA or Javascript. Custom applications can also be developed using ESL - a powerful event socket with accompanying library.

Historically there hasn't been a good way to make use of all of this functionality - the power of HTML5/JS/CSS in the browser (via WebRTC) and the power of voice/video applications hosted in the cloud using FreeSWITCH.

Until now.

Verto is an exciting new Javascript library and FreeSWITCH endpoint module. Together they allow web developers to use a single Javascript library for call control and FreeSWITCH event handling and interaction. That's right - call control and ESL in the same endpoint/protocol/library!

The FreeSWITCH endpoint module is configured to listen on a WebSocket or Secure WebSocket (or both). The Javascript library is included and configured to point to the FreeSWITCH instance. With a single library and simple API a web developer can make full use of a remote FreeSWITCH system using WebRTC within minutes!

One more thing - WebRTC (by way of OPUS) supports two channel audio (stereo). As part of Verto development the FreeSWITCH team decided it was finally time to implement stereo as well!

Make sure to stay tuned for more about WebRTC and Verto but in the meantime - enjoy the demo!

VoIP Users Conference Talks Crypto

I spent about two hours today on the always awesome VoIP Users Conference talking with Olle Johansson, Dan York, Tim Panton, Dave Taht, and others about VoIP security and encryption in general.

If you can handle listening to my voice and seeing my stupid mug it should be pretty educational. I hope you appreciate the Nagel print hanging on my office wall!

2013 Kamailio Awards

It has come to my attention that Daniel-Constantin Mierla has selected my blog as a 2013 Kamailio Award Winner! This is a huge honor and I appreciate the recognition from Daniel and the entire Kamailio project.

With only six posts in all of 2013 it seems that (thankfully for me) some people do prefer quality over quantity.

Thanks again Daniel!

Securing Real-time Communications - Quickly

This is a post that would be received completely differently a year ago.

We now live in a “post-Snowden” era where even average members of the general public are at least vaguely aware of things like “wiretaps” and “encryption”. With that said this isn’t another post about those revelations.

Over the past year I’ve been steadily working to improve the security of the various real-time communications platforms I’m involved in. Timing on this has been coincidental with the news about the NSA and the various programs operated by them. Of course with these revelations I’ve been paying extra special attention to key sizes, cipher suites, and of course the use of elliptic curve cryptography.

As regular readers of my blog might suspect my primary technical focus is on SIP and RTP.  SIP provides for the use of TLS to secure the signaling channel. While TLS isn’t always TLS (TLS versions, cipher suites, etc) there isn’t anything special about the application of TLS to SIP.

TLS is one of those things we just take for granted these days (kids - get off my lawn)!  However, there are several well known issues with various TLS implementations currently in use. Even though TLS is used to secure banking and highly sensitive web traffic everyday, SSL Labs reports that only 20% of web servers currently support TLS 1.2. Yikes.

Of course TLS isn’t just for web traffic. SIP can be secured with TLS as well. This is a very interesting scenario because as the name implies, SIP is almost exclusively used as a signaling channel to establish another session (which may or may not be secured). This means that securing SIP with TLS is not only important for the integrity of the SIP session, it’s often reused to secure the communications established by that session. This is the case with real time voice and video communications using RTP or more specifically the secure profile of RTP (SRTP).

As always, anything SIP related is complicated and security is no exception. To offer a completely encrypted solution the alphabet soup and resulting complexity adds up pretty quickly.  First, you must establish a secure signaling channel using SIP over TLS. You then use SDES (hopefully) to exchange offers and key information over SDP. Once the SDP offer answer model has done it’s thing you will have negotiated the transport of secure voice and/or video using SRTP.

Originally defined in RFC 3711, SRTP has now been updated with several follow-ups, errata, and extensions. Looking around in the open source community and commercial VoIP space, however, shows that many implementations have not moved very far beyond this original specification for various reasons.

One of these reasons is due to existing libraries implementing SRTP. Just about all of the open source implementations of SRTP that I’m aware of use some version of the original libsrtp written by David McGrew of Cisco Systems over seven years ago. Since then libsrtp has been forked, patched, and otherwise used by pjsip, FreeSWITCH, Asterisk, the Chromium/Chrome web browsers from Google (for WebRTC), and countless other projects.

For some time now I’ve been interested in replacing the built in AES and SHA functions in libsrtp with those provided by OpenSSL. This goal led me to the work of John Foley (also of Cisco Systems) and the official libsrtp Github repository. When I first started looking into this John had (recently) completed work on a branch of libsrtp that accomplishes exactly this.  He also went two steps further: the use of AES-NI and support for AES-GCM mode in SRTP.

What?

AES-NI is the reason I was first interested in using OpenSSL for SRTP. Long story short new(ish) Intel CPUs include a new instruction set that greatly increases the performance of AES (especially with AES-GCM and larger payload sizes). This is a good thing and should (hopefully) lead to more widespread adoption of SRTP.

The use of OpenSSL included another perk: support for AES-GCM. While AES-GCM isn’t necessarily new there hadn’t been support for it with SRTP yet. AES-GCM is the current “gold standard” AES block cipher mode of operation, especially for “streaming” operations like VPNs and other packetized data. In fact, Cisco currently considers AES-GCM a “next generation encryption” solution.  AES-GCM is also preferred by the National Security Agency’s (NSA) Suite B crypto specification (for better or worse in a “post-Snowden” world).

AES-GCM is one of those “standing on the shoulders of giants” moments I really appreciate. To think that I’m writing a blog post in 2014 talking about a technology that uses a field named after an early nineteenth century French mathematician (with a really interesting life) is amazing to me. As Isaac Newton said “If I have seen further it is by standing on the shoulders of giants.” In this case the giant was born over 200 years ago and only lived to the age of 20.

Anyway, John Foley (another giant) was able to provide a fork of pjsip that included the feature-openssl branch of libsrtp and had been patched to support AES-GCM mode with SIP (SDP/SDES) and SRTP. He just didn’t have anything else to test it against.

I wrote patches implementing 128 bit AES-GCM mode using the updated libsrtp branch for both FreeSWITCH and Asterisk. Because of limitations in the original SRTP specification both projects would require fairly significant refactoring to include support for 192 and 256 bit GCM modes, “big AES SRTP”, and the use of GCM mode with DTLS (for WebRTC). In fact, both FreeSWITCH and Asterisk implemented support for SRTP by largely differentiating only on authentication tag length.

In any case we were able to use these patches to test 128 bit AES-GCM mode SRTP interoperability between pjsip, Asterisk, and FreeSWITCH. However, there was still work to be done.

I’m happy to report that as of last week the FreeSWITCH master branch now not only has support for the use of 128, 192 and 256 bit AES-GCM modes it also includes a very flexible means to control the use of various SRTP crypto suites on both incoming and outgoing channels. Unfortunately this hasn’t been implemented for DTLS use with WebRTC yet but I plan to advocate for that shortly. I’m also still working with the Asterisk project to clean up my patch for inclusion there.

I think it’s safe to say that with these changes FreeSWITCH now supports state of the art (some may say “next generation”) cryptography with SRTP. However, if you recall the keys used for SRTP are still exchanged using SIP over TLS, which depending on various factors, could still have numerous issues and be fundamentally insecure. How can we be sure that our SIP signaling channel is properly secured?

FreeSWITCH and Kamailio now both also support the explicit specification of TLS version and cipher suite. When using OpenSSL 1.0.1 (which is required by FreeSWITCH) this allows the user to require the use of TLS 1.2 and only the strongest cipher suites supported by OpenSSL. Of course this is great news for FreeSWITCH and Kamailio, but what about the rest of the SIP+SRTP implementations out there?

Unfortunately support for these standards is bleeding edge at this point and not widely deployed. While any use of SIP over TLS and SRTP is certainly preferred for various reasons (performance and security) I’m pushing for support of TLS 1.2 and AES-GCM everywhere possible.

Hopefully I’ll be able to offer more on that soon but for now enjoy the faster and more secure real time communications made possible using FreeSWITCH and Kamailio!