Slashdot Mirror
Skype Addresses Visibility Concerns
An anonymous reader writes "TechWorld is reporting that VoIP pioneer Skype has finally decided to buckle down from their startup mentality and address some of the concerns about the 'visibility' of Skype by network admins. From the article: 'Problems started around the time that the version 2.0 beta appeared last year, the moment when a handful of software engineers started to assess a troubling issue thrown up by the program's new and evasive design: it was incredibly hard to detect using perimeter security systems. Skype's unofficial explanation for its extreme stealthiness has always been that this was necessary to avoid telcos threatened by its business model from blocking it. While this presents no issues for a home user, using "invisible" software capable of making and receiving voice calls, opening instant messaging sessions and exchanging files on a corporate networks, caused some to ponder whether the ever-more-popular Skype hadn't just turned itself into a huge security risk.'"
Because as a last resort I believe it will use 443, so you would have to block SSL as well. That's why packet inspection is required.
No. The whole point of the article is that Skype purposefully intends to be invisible and sneaky. The reason is that it makes it easier to run Skype on firewalled and/or NATted networks, either at home or at work. Many home users have convoluted NAT setups, and most don't have the expertise (or reason) to poke holes in the firewall. Skype likes to advertise that it offers Internet phone service that "just works", so they need to make it work on every network. That may mean using random ports, using ports intended for other protocols, tunneling to remote servers or through peers, or other things that can be interpreted as resourceful or sneaky, depending on your point of view.
ttuttle is a rankmaniac
Skype has done a pretty good job of creating a protocol that works in almost all situations, unlike SIP or many other VOIP technologies. You don't have to worry about NAT full-cone, restricted-cone, port-restricted cone, STUN, or any other crap in a badly designed protocol.
However, if you want to block skype, it is very easy. Have a look at reports using openbsd & squid.
Or do a quick search with google.
The gist of this article seems to be that unless you're doing complete content analysis on incoming packets, you aren't going to be able to detect Skype: it uses (on my system at any rate) port 443 (SSL?) and port 80 (HTTP) as its default ports. Any sysadmin that blocks those ports is going to get some very annoyed phone calls from pissed off users.
That skype is being devious and sneaky is not the issue here. I think the real issue here is that sysadmins don't have control over the machines they're supposed to be looking after. There are plenty of ways to make sure that Skype doesn't make it onto the corporate network-- don't give unauthorized users permission to install software, blacklist it on the company approved software image, packet analysis... the list goes on. I figure if the sysadmin is not paranoid enough to do these things to begin with, the use of Skype on his/her network probably isn't a major threat. Or the sysadmin is inept. Your call.
... caused some to ponder whether the ever-more-popular Skype hadn't just turned itself into a huge security risk.
The fact that Skype is designed to be unfirewallable is not a security risk: Any site which wants to block Skype should have a policy prohibiting its use.
The security risk is users who ignore such policies, and system configurations which allow said users to install and use Skype.
Tarsnap: Online backups for the truly paranoid
I'm worried about allowing software on to the network that I can't monitor and disable at will.
And thats exactly why I dont want skype to change. I dont want the ability for my ISP, or any other provider down the line, to be able to block skype. It is my personal long-distance telephone, and I dont doubt that there are plenty of providers out there that would jump at the opportunity to block it.
Imagine that you have just spent the last two years actively using an internet service for your telephone - at free or near-free pricing. You wake up one day, and it doesnt work anymore. You call up your internet provider, who also happens to be a telco, and say "my internet-based-replacement for long distance isnt working anymore".
You can bet what their responce would be.
.
Already been down that road. The only way to defeat it using port 443 as well is to REQUIRE that all SSL'ed traffic pass through a device that can break down the SSL'ed traffic and look at it. You're basically setting up a man-in-the-middle scenario. If that's the case, you have two issues: 1. You need to have a way to decrypt the SSL'ed traffic on the line. That basically requires you to run certificates that YOU control on the proxy host as well as on the end-user's computer. 2. You now have a privacy issue that would become a real pain in the ass at least in the USA in many jurisdictions. Even if you established a policy that allowed let's say going to a banking site to do personal banking during approved hours, you would still have someone legally challenging a company's ability to completely take apart and read someone's supposedly private SSL session. In layman's terms, it means even if I have that padlock in the bottom right-hand corner of my browser, someone upstream who is NOT my bank can see my username and password. This is problematic from a legal standpoint...it has nothing to do with technology.