In January 2013 we enabled both TLS and SRTP on outbound calls. Today it is available on all incoming calls, i.e. using Simwood numbering with us delivering calls to you over SIP.
What is it?
For those who don’t know the signalling element of SIP often takes place in UDP, a fire and forget protocol which is lightweight and fast. It requires no handshake from the other side like TCP but conversely the sending equipment only knows the packet hasn’t been delivered when it doesn’t receive a reply in a certain time. The application, rather than the protocol are then responsible for retransmission just as they are similarly responsible at re-assembling packets which are fragmented. Support for the latter is often poor which is why SIP INVITEs might simply never arrive if they’ve been made to big through enthusiastic codec options for example. UDP is great for things that can be fire and forget such as the RTP making up the audio of a call, but there’s better choices for the signalling.
Signalling can also operate in TCP which has the benefit of a proper handshake (reducing spoofing opportunities), fragmentation and retransmission handling at the protocol level. By virtue of being an open connection rather than a stream of apparently unrelated packets, it can help greatly with NAT traversal type issues too. It is fractionally slower as a result but we think the benefits outweigh that. After all, TCP is the protocol which drives much of the rest of the Internet as it is used in all major protocols with the exception of DNS (which like SIP is predominantly done in UDP).
TLS has all the virtues of TCP but is encrypted. It is a successor to SSL and both are built into all mainstream browsers and email clients to enable authentication and encryption between applications and servers where data is being sent across an insecure network. Isn’t that exactly our scenario with SIP?
So in short, SIP can work over one of three transports UDP (default), TCP (better) or TLS (best). Using them is often a simple configuration change and our side will respond to all three. TLS would normally require a secure certificate and indeed our side will identify itself with a *.simwood.com certificate but in a SIP scenario most people seem to use self-generated certificates, giving the obvious encryption benefit without the authentication, that instead being handled in the usual way within the secure session.
SRTP is not a transport, it is simply the encryption of the RTP to secure it, hence the S before RTP. The RTP is still transported in UDP but both parties to the call have exchanged keys in the SIP to enable encryption. You can use SRTP regardless of the transport used for the SIP as they are unrelated. However, there is little value to encryption of audio with keys that are exchanged in plain text – anyone sniffing the SIP has the key to decrypt the SRTP. Therefore SRTP really should be used over and above TLS transport of the SIP leg.
Why bother?
In this day and age of privacy concern and alleged snooping, that should be an easy question to answer. You wouldn’t access your bank over plain old HTTP, or send credit card details in an email for obvious reasons. Why therefore would you want to convey not only the full caller/callee information (which is all the Communications Data Bill sought to access) but the entire unencrypted audio? Tools such as Wireshark can trivially re-assemble these far more readily than, actually, unencrypted Internet banking simply because raw audio is natively comprehensible to humans unlike a page of HTML with a few snippets of private information. We suspect your end users are blissfully unaware but becoming more so.
We very strongly recommend that you enable TLS/SRTP at the very least on the leg between us and your equipment. Naturally though, privacy is more relevant the closer you get to the end-user and you should therefore seek to enable TLS/SRTP on your own equipment and out to end-user handsets. This is especially true if they are consuming your service over WiFi or other shared Internet access.
How?
Unsurprisingly, Simwood is the only wholesale provider we know of that offers this universally. Like HD Voice and great APIs we think everyone should, naturally, but meanwhile we hope us offering it alone is more a reason to use us than a reason not to enable your customers to communicate securely!
Interfacing with Simwood using TLS and SRTP is pretty straightforward. Vendors will be able to advise on the preliminary steps to take to first enable it on your equipment. The Freeswitch wiki for example gives a detailed ‘how to‘. Beyond that we offer a sample configuration for Freeswitch to integrate with us.
In overview though, once your equipment is TLS capable you can configure your outbound trunks to us to use TLS as a transport and to offer SRTP. For inbound, your equipment needs to be reachable on a TLS SIP port (usually 5061) and you need to configure your numbering with us to suffix ;transport=tls to the target URI. This command will cause us to use TLS to reach you (for the record you could put ‘tcp’ or ‘udp’ in there instead). As this is applied at the level of an individual number’s dial-plan it makes sense to use a test number first!
If you tell us to use TLS then we will automatically offer you SRTP, should your equipment be configured to use it.
Having made some test calls if you open a support request we can happily confirm whether they completed securely, i.e. were both signalled over TLS with media over SRTP.
Upstream of Simwood
Nearly all traffic coming into Simwood comes over our SS7 links to BT and others. SS7 is unencrypted but is a private closed system, not conveyed over the Internet. A small proportion of traffic comes into us over SIP, for example some of our porting partners prefer to do it this way, but that is generally over private interconnects. We use TLS/SRTP where possible but sadly support is lacking. This is deterministic however so we can advise whether a particular number enters our network in a securable manner.
Traffic leaving Simwood similarly largely goes over SS7 but some, international traffic for example, uses SIP. Again, this is generally over private interconnects but not exclusively. We’re working to enable TLS/SRTP where possible but cannot presently guarantee it beyond us.
Whilst we want end to end encryption on every call it isn’t presently possible. However, we come back to fact that private information is most relevant close to the party it relates to. For example, if someone wants to invade Mrs. Jones’ privacy they’d logically do so close to Mrs. Jones, perhaps on her home WiFi. They could equally intercept at her provider (you) but have no idea you send traffic to us or visibility of the path to/from us.
Security by obscurity is not ideal but when most of the SIP/RTP traffic out presently is completely insecure we think securing from Mrs Jones as far up the chain as you and we can control is a crucial first step. Beyond that if there is appetite amongst our customers for secure-only termination, please let us know.
***
As always, do please get in touch if we can assist with any of this. We’d really like to see a substantial proportion of traffic coming into and out of our network shift to TLS and SRTP and look forward to seeing you differentiate your service further from the herd by offering it.
