Encrypt sip traffic on local network

good day all, is there a way to encrypt sip traffic on a local the network. I am trying to avoid someone using wireshark to rebuild voice traffic. the handsets that i am planning to use are some Cisco spa 508G


Enable SRTP / TLS

… and fire the person trying to eavesdrop.


Lol. No i just want to implement it just in the event an audit comes up.

Im not sure what type of audit is going to require local voice traffic to be encrypted and I have doctor offices as clients.

1 Like

I’m with @BlazeStudios on this. I’ve got several Doctor’s offices that I’ve set up, and the HIPAA requirements for this are pretty lenient. Calls “in flight” do not need to be encrypted - the justification for that would be that POTS calls aren’t encoded, so requiring it of other vendors seems like a political (vice technical) limitation.

1 Like

This isn’t even about POTS or the PSTN. The request was for local network calls which would mean internal calls on the PBX that’s on the same network.

The original request was “I don’t want users rebuilding SIP calls” then it went to “I want it in case we get an audit”. Neither of those reasons make sense.

So this is just strange all around.

1 Like

And I maintain that if you have an issue where you are concerned about an internal user using a packet sniffer on the phone network and re-building SIP calls, you have a management issue, not a technical one.


I agree with Tom & Greg on the point of “I’m gonna encrypt my stuff, so that bad employee can’t mess with me”.
No, that bad person needs to go, and encryption won’t prevent them from harming your business.

However, I am a fan of enabling encryption.
We’re in 2018, just look back to 2016, we all know how many sites upgraded to https in just two years.
Thanks to contributers, you can get a free SSL certificate, or for reasonable pricing from other orgs.

So if it’s easier to get an SSL cert and more people start using TLS/SRTP, it’ll become more stable & reliable, and by the time it will be required by HIPPA & by all other security checks, you’ll have the experience necessary to roll out to the rest of clients you were cautious about…

Another point.
Which midsize company does not have today at least one remote phone? So IMO we should encourage people to start using TLS/SRTP.

But again, in this case, get rid of the bad apple first.


I am really new to the PBX game also the area of network security.

There is no TLS over the PSTN. There is a reasom the list of providers offering it is very small.

Why don’t you just lock down the phone network (vlan) and create firewall policies that the data network does not access the phone network. Also on your switches just whitelist the Mac addresses of the phones and PBX that are plugged into the ports so even so if they pull a phone and plug in a pc with packet capture the switch won’t allow it on the network.

VLANs do traffic segregation for QoS - they ARE NOT a security feature. The ability to snoop on voice and video sessions in a segregated VLAN using ARP Cache Poisoning was first demonstrated circa 2010, and is readily available in many hacker toolkits.

People can demostrate how things could happen all the time in regards to voice traffic being snooped. The one thing these demostrations all have in commin is what could happen once they are in your network.

What these demstrations don’t demostrate is how they got in to your network_. The amount of work it takes to get in to the network to a point you are scanning and capturing all the traffic is quite a bit. If it is not then that is a bigger issue with your security than a voip issue.

This is not something you can just grab “out of the ethers”. Again, if the concern is focused on “bad employees” this is not a tech concern. This is a HR concern and should be addressed with them

Tom, I’m sorry to have to tell you but this is not the 1990’s any more, the bad guys only need to infect one system inside your network (phishing usually) and then they have a jumping off point to do what they want. Look at the latest Marriott’s/Starwood breach - they currently reckon the bad guys were "inside " their network for up to four years!
Many attacks are automated (“spray and pray”) random exploits, though many are targeted. Once infected the machine simply phones home to tell the bad guys they are ready to go.
If you seriously believe that the problem is the disgruntled insider then you don’t understand the scale of the problem.
(Not meant as a flame - just that InfoSecurity is the “day” job)

We could go around and around about this. Encrypting traffic on the local network only requires TLS and SRTP on the local network. Set it up like you would any other secure transport. You have secure comms on the local network.

Having said that, there are some things about this that bear reviewing:

  1. Having access to the audio stream without being part of the audio stream protocol is a network challenge. The RTP ports move within a large range of ports on purpose, so getting an RTP stream associated with a single extension would be challenging at least, and arguable infeasible at most.
  2. While VPN is not a security mechanism, it does “remove” the voice traffic from the data network, which makes it harder to get to than other data-only on your data network. If this is attractive, you can also set up a real private network which is occupied by your phones and PBX. This physical sequestration of the network provides a level of access that is hard to break into without physical access.
  3. Keylogging, and more advanced security-bypass protocols, are harder to do on a phone than they are on a computer. If someone were to hack the phone, then all bets are off on this one, but it’s worth mentioning.
  4. IPv6 is available for the PBX and for many phones. Implementing an IPv6 phone LAN with IPsec integrated is a sure way to lock out hackers. This was, after all, one of the points of moving to IPv6.
  5. We are protecting something on the local network that is not protected on the wider POTS network. Phone tapping is a time-honored way of collecting this information, and if your phone conversations traverse the POTS network, there is no standard encryption mechanism widely available. I know about KG-84s, Omnis, and TACLANEs, but these are point to-point encryption devices and present their own levels of headache.
  6. The voice traffic, if recorded on the server, will not be encrypted. The only way to accomplish this is with a post-recording script that provides a two-way encryption mechanism so that legitimate users can have access to the recording.
  7. There is a level of overhead and trouble that comes with security. For almost everyone, encrypting the local channel presents a solution for which the problem isn’t typically important.
  8. Even if you hack the voice network, what are you going to do with that information? We should have taught everyone (as “we” have for the past 50 years) that telephones are not secure.

Insider threat or hacker, there are hurdles in place for this that make is a high-cost, low-dividend solution. Yes, you can do it, but from a practical perspective, is it going to gain you the advantage you are hoping for? For most of us, the answer is no.


My day job is that of being a Voice Provider, mainly as a multi-tenant hosted voice. In the 15+ years I have done this the issue of the calls being snooped or having the audio stream compromised has been zero. Have I have end users get their devices/PBXes hacked? Yes but that is on them when they provide their own devices.

Unless you have explict control of the source, the destination and everything in between for a call there is absolutely no 100% guarantee of security for that call overall. Take a look at Twilio, they offer TLS/SRTP for their users. The only thing that is guaranteed is that the call has TLS/SRTP berween Twilio and the user. That call is being decrypted and delivered in a non-encrypted format to the destination the majority of the time.

At a certain point some security things are just that, things. They generally arent a concern if the main security overall is solid. Sure TLS adds security but if the person is so dead set on gettjng your calls and has the toolkits and skillsets to get your calls they probably have the tools and skills to break most encryption.

Because lets be real, there is a large amount of people out there that scream and insist on “security” but turn around and use Let’s Encrpyt certs and OpenVPN because they want security but they sure as hell arent going to pay for it.

These are generally the people that stir this pot about TLS calls being a must.

1 Like

See i have a Meraki stack and ARP Cache man in the middle attack won’t work on Cisco or Cisco Meraki devices and switches. Now I don’t know what equipment the guy has. But I never had an issue.

The debate heretofore is that “in theory” the audio stream is vulnerable, but “in practice” our collective experience is that the protocol and procedures we use and recommend pick off the easiest places. Like most things, if something is valuable enough to steal it is valuable enough to protect, but many of us have been working in this tech space long enough to know that the vulnerabilities we’ve been discussing are outside the network.

I’m not saying security isn’t important - I’m saying that the price for protecting a low-value target is limited. It costs nothing to set up TLS or a secure VPN, but the overhead and chances of it failing make it an unattractive solution to most people. As with most things, you can have it your way, no matter which way that is.

The original poster asked if such a thing was possible. We said “Yes”. If they have a problem with one of their employee’s listening in on other people’s conversations, there are administrative ways of dealing with that. If they are having problems with competitors or criminals listening in on their phone calls, there are lots of places that could be happening - some of which can be secured and some of which can’t.

The amount of trouble you take is based on the amount of trouble you expect from not doing certain things. Most of the outcomes from this type of activity are relatively benign, so spending a lot more resources over the “best practice” stuff the system is built to do is probably overkill in most situations.


No they do not.