Skype as a platform for secure VPN tunnels?

 Since Skype has an open client-side API, why not use it as a transport to tunnel VPN traffic and blow through firewalls to connect you to a remote system?  That's the idea raised by Peeter P. Mõtsküla in his Skype Developer Blog entry: "Idea: skypetunnel".    For instance, have a Skype client running on your home machine logged in as one account.  Have Skype on your laptop on another account.  Initiate a connection between the two of them and wind up with secure, encrypted access through the firewall from wherever you are.  Being peer-to-peer, there  would be no central servers or infrastructure required (outside the usual Skype p2p cloud.) This would require, of course, a yet-to-be-created "extra" that connected into the Skype client API and was installed on both systems... but that was the point of the article - to suggest that something like this could be done (and perhaps inspire someone to write one).

It's an interesting idea, although as one commenter noted, it has already been done in a p2p fashion by Hamachi.  I don't know how large Hamachi's p2p cloud (i.e. userbase) is compared to Skype and whether or not that even makes a difference, but the point is that if you are already a Skype user, this would be a way to make use of your existing tools without using another tool.

This whole concept, though, is part of the side of Skype that is admittedly a bit scary for those of us in security, and specifically corporate security.  The client-side API can be accessed by whatever extras a user installs.  All Skype traffic is encrypted, naturally, so a corporate IT security person has no way to know what is going across that connection. Whatever the user installs and allows to access the API gets to use that encrypted Skype connection. If a user installs this fictional VPN Skype extra, the user could then access their corporate desktop from wherever they are - without going through the "approved" VPN gateways... and at the mercy of the security of that fictional VPN "extra".  How well is that "extra" secured?  Could someone else using the extra connect to your corporate desktop PC and initiate a VPN?  What kind of authentication is part of it?

Yes, with Skype's business version, you can use Windows' registry settings to control access to the API, but this means that: a) the company would need to essentially "endorse" Skype usage by promoting the Skype for Business edition; and b) the company would need to somehow block all installations of the "regular" version of Skype.  I guess I don't see that happening - yet - in many corporations.  I expect they will probably continue to take the very black and white approach of attempting to block Skype entirely from their corporate LAN... or just ignoring the issue and letting Skype be installed if users do so.  This latter case is where the Skype client API gets a bit scary.

We'll see.  I agree with the article author that it's a rather logical extension of the Skype p2p cloud.... it will be interesting to see if someone does come up with a VPN "extra" for Skype.

Technorati tags: , , ,

VoIP/IP telephony in Estonia... disrupted by botnets?

With my post earlier this month about the possibility of SIP botnets, I've had a number of people asking about more information and wondering about the possible impacts.  And while I will write more on botnets in general, as far as the potential impact of "botnets" in general, one need only look over at the current situation in Estonia:

Now, perhaps Russia is behind the attack... perhaps not. There are obviously much larger political issues going on between the two states.  In the end it doesn't really matter on one level who exactly is behind it... the net of it is that Estonian entities are being attacked in a massive Distributed DoS (DDoS) brought about in part by botnets. For anyone doubting the potential threat, you need only to read through those news articles to understand what can happen.

In fact, I found it interesting that the UK's Centre for the Protection of National Infrastructure (CPNI) issued an advisory today about the DDoS attacks against Estonia, mostly to reassure people in the UK that no attacks were currently being seen against UK businesses.  It also included two links to previous papers written by NISCC (one of the predecessors to the CPNI) about:

Both make for interesting reading and give some suggestions for how to prepare.

So what does this have to do with telephony?  Well, for starters I'll admit to knowing nothing of Tallinn, Estonia, before Skype entered the picture.  Skype is, of course, headquarted in Tallinn and through things like their Life at Skype blog have provided a view of Skype as a company, but also of Tallinn and Estonia.   Since then I have also learned of other companies coming out of Estonia... certainly seems like an interesting hi-tech place these days.  Now I don't know what, if any, disruption Skype has been seeing from these attacks.  The distributed p2p nature of Skype would argue for there not being much of an impact (except, obviously, to those right in Estonia), but I don't know.

On a larger level, though, it's just a powerful reminder that the botnet threat is very real out there.  And the question is... could your IP telephony infrastructure withstand a botnet attack?  Is your larger IT infrastructure up to withstanding some degree of an attack?  Do you have multiple VoIP gateways?  Could you route around points on your infrastructure that were being attacked?  Do you (gasp) have TDM trunks that could work as backups? 

I don't know if anyone in Estonia has had their IP telephony disrupted by botnets, but odds are if the attacks are as bad as being reported, some companies probably did.  What will you do to ensure your company's IP communication isn't disrupted should botnets come calling?

P.S. For another view on the larger conflict between Estonia and Russia, here's an article (and comments) I found interesting in John Robb's "Global Guerillas" blog: "Russia vs. Estonia: 21st Century State vs State Conflict".

Heading out to Arizona for US DoD/JITC conference on telecommunications

In a few short hours, I will be catching a plane heading out to Fort Huachuca, Arizona, to swim in an alphabet soup of very different acronyms and jargon than my normal work - the "OSD-Sponsored, JITC-Hosted DOD Telecommunications Services Information Conference".  As noted on the page:

The purpose of the conference is to provide an open forum where DOD and vendor representatives can discuss issues related to interoperability of systems providing DOD Telecommunications Switched Services.

The conference will present the current program and discuss ongoing developments to the interoperability certification and information assurance procedures and test documentation. Other topics for discussion include emerging technologies, standards and their integration into the systems providing DOD Telecommunications Services.

I attended last year as well and it's definitely an interesting experience.  The US DoD is really doing some intriguing things with how they make use of VoIP / IP Telephony.  Obviously security is rather important.  They are also driving IPv6 adoption into their infrastructure and so, with the June 2008 mandate only a year away, it will be quite interesting to hear where they are with regard to IPv6 adoption.  Obviously, their huge size and buying power is of strong interest, so the number of vendors will no doubt be high.  Also, and I would think "obviously", I won't exactly be writing about things that I hear or learn there.

If any of you reading this happen to be out there at the conference, do drop me a note as I'm always interested in meeting readers or listeners.

Technorati tags: , , ,

Getting ready for VoIP "botnets" that attack SIP systems...

Over on the Voice of VOIPSA weblog, I just posted "Ready or not... here come the IRC-controlled SIP/VoIP attack bots!" Given the sheer number of VoIP security tools out there, I think I and most others involved with VOIPSA figured it was only a matter of time before someone automated the attacks.  Did I hope that the creation of "bots" could have held off for a bit longer?  Definitely... but we have to play with the cards we are dealt.

I tried in the article not to hype the threat... that we are aware of, there are not massive botnets out there waiting to attack VoIP systems.  But there is now a proof-of-concept "bot" out there and those of us dealing with VoIP security have to look at how that could impact us.

And it's definitely a sign that we as an industry really have to get security locked down on SIP systems!

Blue Box Podcast #56 posted, beginning a series of VoIP security tutorials

I posted Blue Box Podcast #56 tonight and with it Jonathan and I are beginning a series of mini-tutorials on subjects related to VoIP security.  In this show, we talked about voice encryption. In the next show (already recorded) we will talk about signaling encryption.  The idea is to cover some basic ground so that people not familiar with the area can have a basic understanding.

Just glad to get that one up - tomorrow I'm going to work on #57 to see if I can get it online for Wednesday.  We're trying hard to get back on a weekly schedule.  (#56 was intended to go up last week.)

My article "Using IP Communications as a Tool for Disaster Recovery and Business Continuity" is now online

I just realized that I never wrote here that an article I wrote recently came out online.  Published in Mitel's "Presence" magazine, it's titled "Using IP Communications as a Tool for Disaster Recovery and Business Continuity".  Okay, so the title's not overly catchy, but here's the first paragraph:

If a hurricane devastated your main office, how rapidly could you restore telephone connectivity? If a branch office had a fire or other disaster, how soon could you connect back into the main office? Or if Avian flu or some other pandemic created a situation where you needed to stay out of the office, could you access remote phone capabilities equal to that at the office? How long would it take your business to recover? How much (and how many customers) could you afford to lose in the process?

I go on to talk about why IP communications/IP telephony/VoIP fundamentally changes the traditional way you might address these issues and offers tremendous benefits.  In fact, to me, the ability to put an IP phone pretty much anywhere you can get an IP address remains one of the major - if not the single biggest - disruptive aspect of IP telephony/communications.  Remove geography as an issue and suddenly things like disaster recover and business continuity take on a whole different view.

While it's in a Mitel publication, there's nothing in the article that is really Mitel-specific.  Listeners to Blue Box or readers of Voice of VOIPSA probably won't find it terribly new since I've been talking about this before in those sites... but for those of you not familiar with DR and BCP and how VoIP can change that, I think you'll find it a useful read.

Shawn Merdinger - The Top 11 VoIP security issues you need to discuss with your vendor

Over on the Voice of VOIPSA weblog, security researcher Shawn Merdinger is 2/3 of the way through a series of posts on the "top 11 VoIP security issues you need to discuss with potential vendors".  His posts are:

with the third post coming at some point soon to cover points 9-11.  Shawn's posts are definitely "required reading" for anyone working on or concerned about issues around VoIP security.  He's done a great job bringing into one place the many questions that you should be asking VoIP/IP telephony/IP communications vendors about the security of the systems you are considering (or have already deployed).

Technorati tags: , , ,

Is OpenID really secure? Can you trust it? A Security Round Table podcast explores the issue... and provides a ton of links

What is OpenID? What are the security issues around it? Should you trust using it? What do you have to be worried about? What are the main security threats to it?

While I've written about OpenID here, I really wanted to understand more about the security issues around OpenID, so I got together with two other members of the Security Round Table, Michael Santarcangelo and Martin McKeay, to explore the issues around OpenID and security to a far greater degree.

We have shared the resulting conversation as a SRT podcast, and have also published as the show notes the large body of links that we accumulated during our preparation for the show.  I'd encourage you to check out the SRT site purely for the links alone, as I think we pulled together one of the more comprehensive lists of links I've seen related to OpenID.

In the end, the three of us came aware quite impressed with the possibilities of OpenID with regard to the specific piece of the identity puzzle that it is aiming to solve.  We hope this podcast helps people understand both the potential benefits as well as a few potential challenges with regard to security and OpenID.  Comments and feedback are very definitely welcome.

Technorati tags: , , , ,

Ranting about how very wrong ComputerWorld.au is about enterprises avoiding IP telephony for teleworkers

ComputerWorld in Australia came out with an article today headlined "Enterprises must avoid IP telephony for teleworkers or face attack".  Given that I use a secure teleworker phone on a daily basis, I was immediately struck by the headline and felt compelled to write a response over on Voice of VOIPSA: "Why Computerworld.au is dead wrong about... ".  I think you can gather my opinion from the title.  It will be interesting to see if there is any response from ComputerWorld (I've emailed them the link).

The sad thing is that outside of the headline, the rest of the article was more or less okay. Just a bad headline...

AOL & OpenID - 63 million AIM users are now OpenID-enabled! And perhaps a slight security problem...

UPDATE: O'Reilly now points over to the post from AOL's John Panzer about this with more details.  It's funny... I read that post yesterday from John, but I don't think the enormity of it sank in until about 5am this morning when I read the post from Fred Stutzman that I reference below.


Wow!  Talk about a major boost for OpenID... continuing my OpenID research, I learned from reading Fred Stutzman (also here) that all 63 million users of AOL Instant Messenger can now use their AIM account for OpenID!  Now, I don't actually use my AIM account all that much these days (my IMs of preference are Skype, Jabber and MSN/WLM)[1], but I had to try it out, so I headed over to stickis.com and logged in using my AIM screen name - as shown in the image to the right.  Simple.  Easy.

Okay, that's fairly cool. My OpenID is simply:

http://openid.aol.com/dyorkottawa

Now the only peculiar thing was that I never saw this screen to grant or deny the access to the site.  The only reason I have this screen capture is because I pressed the Back arrow on my browser because I wanted a screen capture of the login page.  In actual operation, once I was logged into the AOL OpenID page I went directly to the stickis.com page... without actually granting the site access to my OpenID.

Hmmmmmmm...

This happened in Firefox 2, so just to verify the issue, I flipped over to IE7 and tried the same procedure.  Again, I was asked for my AIM password and then... bang... I was logged into the site (without seeing the Grant/Deny screen).  Note that I am not running any AIM client on this PC right now.

Now at the second site I tried this at, schtuff.com (a wiki provider that allows OpenId login), I was prompted to Grant/Deny access... but I was apparently already logged in to AOL's OpenID server.  Of course, I can't figure out how to log out of the AOL "Screen Name Service"... I guess I have to close out all my browser windows.    So given that I can't figure out how to log out, I can't replicate this procedure again (sorry, AOL, but I am not going to exit all my browser windows right now)... so I'd be curious to know if anyone else experiences this.  If you get a OpenID login screen, do you then just go right in?

I'm not sure there is a huge issue... I mean, you are going to the site to login... to a certain degree the Grant/Deny screen seems redundant in this instance.  You still have to go through one screen to allow the relying site access to your ID.  And with subsequent sites it seems to do the right thing and pop up the Grant/Deny screen.  Is the skipping of the initial Grant/Deny screen really a security issue?  (if it turns out to be more than just me?)  I don't know yet...

Anyway, kudos to AOL for OpenID-enabling their system... even if there might still be a few bugs to iron out.

This does raise a larger question, too... who do you use as your ID provider?  There's a long list of OpenID providers, but if you use AOL most of the time for IM, might it not make sense to use them as your OpenID provider?  Or do you want the more granular control provided by some of the others?  Where do you establish your online identity?   It shall be an interesting question to continue to ponder.

[1] My AIM name might give a clue as to why I don't use it as well... I took it out during the 5 years we lived in Ottawa, and, well, I've just never gotten around to getting a new one now that left there 1.5 years ago...

Technorati tags: , , ,

  • Search:

Other Places I Write

Twitter Updates

    follow me on Twitter

    Disruptive Conversations

    Blogs.voxeo.com

    Voice of VOIPSA