Slashdot Mirror
Security In Voice Over IP Converged Networks
dotslash writes: "This article at Internet Telephony Magazine has a very interesting analysis of security issues created by converging data and telephony networks with VoIP: "When the phenomenon of "convergence" between telephony and Internet started, it also brought closer the world of the phreaker and the hacker. VoIP brings all this to the next level. Unfortunately, the security inherent in VoIP solutions is equivalent to that of the early Internet: Non-existent.""
Don't use it for anything that should be even remotely secure.... or encrypt the data, but I like the first answer better.....
Anyone equiped with a standard issue electrician's but-set can walk up to a house, pop open the telco terminal and listen/make phone calls on any line in the house. Same goes for corporate lines.
"Virtually no security" is an improvement over "_no_ security."
Granted, security should be implemented at each layer if possible, but wouldn't VoIP inherit the security of the IP network itself? So far, most VoIP installations I've seen/heard about are either within an office, connecting handsets to a PBX with traditional trunks, or between offices of the same company using their internal WAN. Granted you can still have attacks internally, but in neither of these scenarios is it very easy for the general public to snoop or intercept your phone calls.
That said, I really don't see VoIP on a large scale taking off for a while. Two things need to occur before that happens;
- Suitably fast data service has to be ubiquitous. Spotty DSL/Cable coverage won't do it.
- Said data service has to be less expensive than conventional phone service. This one's a no brainer.
- Wireless data on a large scale would help as well.
So far, I don't see these criteria being met in all but niche markets, and that's exactly where VoIP has found itself... for now.
The current laws do not protect security or privacy...
...nor do they allow law enforcement access for wiretaps
Well, there is a flaw in the laws regarding IP networks.
Again, I'd say this is a flaw in the law.
The article points out that older analog telephone lines are covered by laws that prevent people from tapping the lines unless it is someone with the authority and authorization to do so. The article makes it look like the laws regarding VoIP are less advanced, and desperately need updated.
Legal things aside, I would have thought that by now, in this day and age, people would consider security when providing a new service that runs over a computer network. I'm dissapointed in the comapnies who have disregarded security here.
Is there no easy way to make it all tunnel through SSH?
Follow me
I think the main concern with using OpenSSL is that it is too slow for real-time data.
Just think of the amount of packets you have to crypt/decrypt per second.
If we assume 44khz, 16-bit (depends on the ADC/DAC I guess) data, well that's a lot of packets.
No one wants to have a 1-2 second delay in their phone conversation.
Sorry for swearing - but everyone reading /. is adult enough to get a dose of reality.
... need I go on?
If you're actually reading this thread - you're wasting your time.
do you really care if someone can easily tap your phone conversations?.
More importantly:
is the value of your conversation worth the energy required for someone to crack your phone call?
In a security course (both in college, and later in a Cisco class) we heard that the risk is equal to the value divided by the effort required to get at that value.
Now: I don't believe this quote exactly, but it's point is clear.
Nobody I know would spend the effort required to tap my personal line just to hear something I might not tell them directly.
Further: Companies with secrets can use:
I. Standard Non-Secure Phone Lines
II. Secure VoIP solutions
III.Standard VoIP solutions over a VPN
Most of that stuff won't work anymore.. the tones when you drop a quarter in a phone don't really mean anything anymore, they're just feedback so you know the quarter was registered and such. Course, I suppose if you could find a way old payphone somewhere...
There's still things that will work though. Not much stopping someone from climbing a pole with a butt phone and tapping another line, etc..
HELO?
what? is this ~l33t_hax0r? i'm sorry, there's no such user.
no, no, this is 129.168.0.1, you must have meant to connect to 192.168.0.1.
j00're welcome.
*click*
goddamnit, i gotta install a firewall.
Many of the current VoIP deployments today are not using the security features that you might expect to see. In large, this is because the standard itself is maturing and the manner in which security will be implemented is still under investigation. In the case of SIP, the article points out that although the payload (voice) might be encrypted, the signalling isn't. This is not entirely true. One thing that SIP permits is to tunnel SIP as a payload within SIP. The external session serves only as a routing mechanism for the fully encrypted 'real' signaling session contained within. These mechanisms are just completing peer review and implementors are just wrapping their heads around it all. One thing is for sure; unlike protocols that have preceeded them, SIP and it's designers are taking security very seriously. How else could they consider using SIP as an integral part of 3GPP and/or it's use for inter-carrier peering.
Sure, the protocol itself may have exposure issues, and problems with NAT/PAT devices, but there are companies on the market that are addressing these issues as they arise.
Few of them being:
* it's transport layer protocol, not an IP one. By default it runs on top of TCP, while majority of VOIP protocols do not require TCP's reliability. Needless to say that this is voids no good by any means.
* it requires reliable carrier for key establishment/renegotiation. Hence dropped and out-of-order packets will effectively break session. This means that you cant just stick SSL between V and IP layers.
You still can run SSL over unreliable layer (such as UDP or IP itself), but this will require certain protocol 'fixup' effort, which might end up be no less effort than building VoIP security from the scratch.
The simpliest solution along the lines of your suggestion would be to use IPsec and classical VPNs. Throw in IKE and you get yourself PKI-based system. It'd be somewhat pain in the arse to configure, but as a quick and dirty solution is will suffice.
3.243F6A8885A308D313
If security of VOIP is no WORSE than that of a normal phone line, then at least you only have to worry about physically securing a single infrastructure as opposed to the multiple parallel ones you had to manage previously.
Also, in some environments VOIP on top of IPsec may be reasonable. The article is NOT entirely on target (IMHO it's a cheap hit piece). Consider the Cisco IP Phone in a work station. Since a person plugs his or her PC into the phone for network connectivity, you merely need to have some way to trust that the phone is authorized to use QoS, and you can thus encrypt voice traffic AND have the phone do classification.
And that trust can be gotten on the small with simple approaches such as MAC address lockdowns on your switches.
Having worked in the subject area for some time, I can assure you that running VoIP and even video conferencing sessions over IPsec/AES tunnels results in the delay less than 1 ms on the P2-350 machines (serving as gateways on both ends).
I agree that lag may potentially become a problem as number of VoIP sessions grows, but, hey, that's what you need a hardware crypto gadgets.
3.243F6A8885A308D313
Not like it's all that important, but reading "Unfortunately, the security inherent in VoIP solutions is equivalent to that of the early Internet: Non-existent." made me ponder: How can you be equivalent to something that's non-existent? Isn't it kinda akin to dividing by zero?
Jobs? Which jobs?
So I'm listening to WFMU while Station Manager Ken has another of his little tirades about the RIAA and how they're screwing the world over (and they are, unless owing the RIAA $500 a year for webcasting a station with no music on it makes sense to you), and it hits me: what about VoIP? I can't decipher the legalese on the page, but it doesn't strike me as particularly far-fetched that after quashing webcasters, Rosen et al will sic the attack lawyers on businesses who have the audacity to play hold music on their VoIP phone systems.
If not, hello loophole!
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
Regular phone networks encode data at 64 kbps (that's bits per second, not bytes) - 8000 samples/seconds, 8 bits per sample.
Cell phones use more extreme compression, and can transmit at less than 16 kbps. Ever noticed how they sound worse, though?
Any stream has a built in delay - you have to buffer up enough sound in a packet before you send it off. So a 1 ms delay means 1000 packets a seconds, which is inefficient for voice. Buffering in voice calls is usually tens of milliseconds.
Delays of under 100 ms are usually not noticable. Delays of 500 ms will bug the crap out of you.
And, of course, there is the speed of light limitation, (5 milliseconds for 1000 miles - once you route that through a fiber optic cable, it can be a few times that, depending on the dielectric constant of the fiber.).
It's not wasting time, I'm educating myself.
Only a couple of months ago, we finished a roll-out for IP phones. The client was a bank and security was the top consideration. In essence, whatever worked to secure data, worked to secure VoIP. The problem in general is not with the technology; it is with the "old school" PBX designers and engineers.
I have met quite a few people, extremely skilled with PBXs, who view data networks as a black box and have almost no knowledge or methodology to work with products that use them, much less secure them.
When these people grasp the realities of the new, converged, technology, we can expect to see quite a few changes both on VoIP systems' built-in security and fail-safe operation.
All your voice are belong to us.
I suggest investing in good neighbors for security.
I my self am a good neighbor. I'm a good neighbor with 5 years worth of experience. Feel free to contact me if you wish to hire me.
44 KHz, 16-bit! Are you out of your mind!?
Telephone signals -- the current ones -- are 8 bit, 8 KHz and compressed out the wazoo.
You aren't playing a concert thru the phone, just talking!
Learning HOW to think is more important than learning WHAT to think.
Some really old phones can be found that redboxes work on. There is even a PalmOS application that will make your PDA play redbox tones. Helluva lot better than a hacked Hallmark greeting card!
My university just recently overhauled the on-campus phone system. They replaced the old (working) system with IP phones. They did the whole job in a matter of months, despite very vocal opposition by the CS department faculty. These Cisco IP phones cost $700 a pop.
They hooked the central hub of the phone system up to generators in the event of a power failure. Unfortunately, all our phones depend on switches and routers scattered throughout campus, and the phones themselves have DC power adapters. In the event of a power outage, the central hub will stays on-line, but all the phones throughout campus go out!
When asked what students and faculty should do in the event of an emergency during a power outage, our IT services department responded, "Try to find someone with a cell phone!"
Worse yet, switches have a mean time to failure of 100,000 hours. With 2,000 switches throughout campus, sections of the phone system go out once every 50 hours. The current average time for IT services to replace a down switch is 2 weeks.
These phone have web servers, and a few other goodies. I'm just waiting until an IP phone worm takes out our entire campus's network and telecommunications infrastructure.
Protects our privacy?? Oh, you mean like when I use e-mail, IMs or even those less expensive wireless phones?
I guess that head in sand == privacy.
Never never never smoke crack before geometry class!
Finally, something I know about! This is what I do for a living.
The fact of the matter is that most of the large emerging packet telephony networks are not being deployed in enterprises, but in the carrier networks -- telephone companies around the world are replacing their old circuit-switched back-haul networks for packet-switched networks, either ATM or IP. These are private networks which are not open to the general public, and so do not have the same risks as, say running VoIP on the internet would. Sure, the telcos still need to watch out for attackers... it's just that you've raised the bar far enough that 'script kiddies' would have a tough time.
The article also has an over-simplified view of the effort needed to tap an IP phone call. Even if the user were able to mirror any port on the network onto his computer, he still has the extremely hard task of figuring out which port(s) he needs to monitor -- they typically change on a per-call basis, and the user would actually have to mirror two ports (one for each direction of speech) in order to get the entire call. Now, it can be done, but it's difficult. And, it's made even harder because the signalling path (the communication link that handles setting up calls) is usually encrypted, so it becomes impossible to distinguish among calls.
1. almost all VoIP installations are run on switched networks and phone calls are inherently unicast so only source, destination, and possibly a router can see the traffic. Yes, conference calls can be multicast - but most aren't and switches prune non-multicast group member from the broadcast domain anyway
2. Almost all VoIP installations place voice traffic on a separate VLAN. This VLAN is ususally well protected through routers and the like. Also it's easy to enhance security for the VLAN with basic switch/LAN security techniques (tying MAC addresses to specific ports, traffic filters, even 802.1x)
3. Securing the call setup servers, gateways and other devices is relatively easy - any decent VoIP installation would protect these and distribute them so there's no single point of failure.
4. VoIP can be run of VPN's the main issue is the added latency of the encryption/decryption process.
5. VoIP over the wide area is no less secure than standard long distance.
Remember GSM handsets do encryption/decryption in real-time (not very strong, but it could be better without overloading the CPU).
Why would anybody bother to break into a corporate VoIP network to ... make free phone calls over the Internet to their friends? Which they could do directly, for free, now.
Is it really unexpected that Cisco would play down security issues on their training course.
"No don't worry yourselves on security just BUY MORE"
Then agian dont worry that standards are still emerging and this stuff will be out of date within two years.
Don't worry that interoperability with many PABX is only partial.
Don't worry that you may loose many of the smart features of your current PABX.
Dont Worry, BUY MORE
security in VoIP? don't make me laugh. check out VOMIT (feel lucky at google).
and don't believe the hype about the supposed safety of switched nets -- VoIP phones are so very compliant, they just love redirects.
nobody
parturiunt montes, nascetur ridiculus mus
I've got a 3com nbx phone system at work. I also have cisco switches and routers. I can take a phone call and copy the data anywhere I want to send it all transparently anywhere I want. I know this because I do it all the time in an attempt to figure out their unpublised protocol.
MAC address lock down can be broken on many switches. The common trick is overfill the MAC tables with fake addresses until it dumps the locked down one.
Most ethernet chipsets will accept new MAC addresses from the ISA/PCI bus. MAC addresses and IP addresses are both trivial to fake. A single box dropped between the switch for the R&D dept and the next highest-up switch will net you all of the phone calls to and from R&D. Cryptographic methods are the only robust ways to get confidentiality and/or authentication. Public key systems (like SSL) are usually easier to set up than symetric key systems (like Kerberos).
I agree with many people that it's retarded to come up with a new protocol and say "run this on top of a secure layer if you want". The truth is that 99% of the population won't. It's like saying "yeah, there is this exploding gas tank problem, so weld a tank full of fire fighting foam to the back of your Pinto if you want." It's trivial to say in the standard "this must be run on top of SSL/TLS". In this case, SSL setup times are most likely faster than POTS circuit setup times, so the user going from an analog phone to an SSL/TLS IP phone won't notice any dfference.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.