more skype reports

I’m in a bitchy mood today and want to rant on something. This article from ComputerWorld about “How dangerous is Skype” came in at the wrong time.

First, let me just say that I am mixed in my feelings about IM and Skype in a corporate environment. I think this is a trend that, in the long run, will be a losing battle for corporate IT and security. IM is just part of our culture and life, and embracing technology for the betterment of people and the company does have weight. That’s not to say I want Skype in corp nets, but I can sit on either side of the fence comfortably. Encrypted network traffic is also part of our future, and we need to start dealing with it now instead of whining about it.

Here is my take on some of the “Skype FUD” or myths that Michael Gough tackles in his article.

Myth No. 1: Skype uses a lot of bandwidth on my network. Great, I’m glad that Michael Gough tells me that a voice call takes 30kbit/sec on my network. That’d be great if I allowed only one call at a time. Scale that out with your users and get back to me.

Myth No. 2: Any computer can be a Supernode. This is one of those beefs with Skype that has been around a long time, and I hated it because it’s not an issue in almost every corporate network. Michael is correct, you can’t be a supernode if you’re behind a NAT. But, that does mean, as Michael mentioned earlier, that your communications will be weirdly routed through someone else. Annoying, but really a non-issue in any NAT situation. (This may become a huge problem in IPv6 or it may become a big problem for Skype itself if less and less supernodes are available as people hide behind NAT or slow connections.) So, I agree with Michael: this is a myth.

Myth No. 3: Skype is susceptible to IM worms and viruses. Myth? What the crap? Is this the Apple defense about “well other IM apps have had lots and Skype none so that means security?” Yes, in part it is although he oddly mixes actual client vulnerabilities with malware sent via other IMs via file transfer. That inflates his “other IMs” numbers and keeps Skype’s really low. *sigh*

He also mentions that file transfer can be turned off (which it can be on other IM apps too) and files can be scanned by anti-virus (other IM apps as well). So, I’m not sure what he’s trying to say here, but I can illustrate that Skype is no different from other IM apps that have been hit with his 1,000+ issues.

I also challenge that “the main vulnerability of IM applications is their file transfer
feature.” I conjecture that links to malicious sites sent via IM is more dangerous. This “myth” from Michael is completely wrong, and Skype is absolutely no different from any other IM program.

Myth No. 4: Skype is hard to stop on my network. This really is a half-myth but I slightly dislike how Michael Gough tackles it. From the start, Skype was not hard to defeat: just block it from being able to authenticate and logon the user. Easy. I’m surprised he never mentions this; maybe this has changed. I also dislike that he attempts to defend the network by controlling the OS inventory and OS outbound connections. I don’t think this is the best approach, and Skype should be able to be blocked on the network by the network alone. I will admit, however, that stopping a P2P app on a network presents problems, so in a way, Michael’s approach is still solid advice. The real issue, though, is Skype should not have to be that hard to block on the layers it uses.

Myth No. 5: Skype is encrypted, so I can’t archive IM messages. This is a two-headed dragon and I’m surprised Michael Gough attempted to tackle this in either direction as a myth. Instead, he fumbles the ball:

This one’s not really a myth. Skype sessions are encrypted, so yes, you
can’t capture or archive Skype communications. The same is true of many
IM applications, though, so it’s not less secure than other IM programs
that can use encryption.

Bah! Yes, Skype is encrypted so you can’t archive it off the wire, but I’m not sure what settings and apps he uses to say that other IM programs are the same. I can sit down and monitor and grab IMs off the wire on every other popular IM program with default settings. Skype has this feature enabled by default whereas other IMs do not. In fact, I can turn off this setting on every IM program, but with Skype I absolutely cannot. Also, for an article that itself says it is geared to corporate networks as well as individuals, he ignores any issues with HIPAA or compliance that requires logging/archiving/monitoring of data egress via IM. For home users, this is an awesome feature to protect privacy. But this is maybe the biggest hurdle Skype has been facing when it comes to corporate use.

Just to add one more item. Until Skype settings can be controlled centrally, that is another hold in the argument for Skype in the corporate network. Let me centrally control and force settings, file transfer allowances, and yes, adjust encryption such that I can monitor data egress (note that I don’t necessarily want it cleartext). There are other considerations, but that’s all I’ll throw out for now. 🙂

One thought on “more skype reports

  1. I usually tell normal people to use AIM Lite, which supports SSL by default and has flawless file transfers. I like to use lighter clients that only support AIM and also support OTR-Messaging (or work good through otrproxy). There is also SILC.
    If you are using encryption in an IM client that is not what I just said above, then I would personally question the implementation. I’ve seen plenty of point-and-click tools that sniff SecureIM, Skype, etc.
    The “cool NAT trick” that Skype does isn’t really that neat since they stole it. It’s called UDP hole punching, or firewall hole punching. Check out chownat… I even saw a Ruby implementation of this recently that was pretty slick.
    UDP hole punching can only be stopped by blocking all UDP. This means you’ll need separate firewall and other infrastructure for your DNS servers (or NTP). Other things you use might also break (UDP Multicast, streaming stuff, VoIP stuff, etc). There is also TCP hole punching and techniques like pbounce.
    pbounce is available here:
    chownat here:
    Hole punching via Wikipedia:

Comments are closed.