Archive for January, 2012

We‘re excited to launch a new feature, the VPN Haus Readers’ Poll. Every few weeks, we’ll pose a remote access/VPN-related question and welcome your thoughts on it. Today’s poll invites IT administrators to tell us their biggest gripe with remote access projects. We appreciate your participation and look forward to any comments you might have. If you have any poll ideas, drop us a line at editor@vpnhaus.com

Dark Reading’s Kelly Jackson Higgins is reporting that many providers and vendors, including Google, AT&T, Facebook and others – plan to officially go live with IPv6 on this year’s IPv6 Day (June 6). This might sound familiar, as it was last June that more than 400 organizations — including Google and Facebook – enabled IPv6 standards on their websites. Last year, no major outages were reported, paving the way for this year’s official switch.

Even so, an ongoing concern has been whether our technology infrastructure is ready for IPv6. Rainer Enders, CTO of NCP engineering, posed this very question last year in the column “We Need Infrastructure Before IPv6 Becomes a Real Problem” on CTOEdge. Drawing upon his personal experience, Enders illustrated the stark technical reality facing IPv6 implementation:

I live in Walnut Creek, a community less than 30 miles from San Francisco — arguably, the epicenter of technology and innovation in the world. And yet, my community isn’t yet equipped to handle IPv6 or high-speed Internet protocols. If we — just a stone’s throw from Silicon Valley — can’t transition easily to technological innovations, how can we expect anything more from the rest of the country? 

Now, in an encouraging next step, the Internet Society has announced that “Major Internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012,” reports ZDNet’s Steven J. Vaughan-Nichols.

He adds:

In a statement, the Internet Society’s CTO, Leslie Daigle, said, “The fact that leading companies across several industries are making significant commitments to participate in World IPv6 Launch is yet another indication that IPv6 is no longer a lab experiment; it’s here and is an important next step in the Internet’s evolution. And, as there are more IPv6 services, it becomes increasingly important for companies to accelerate their own deployment plans.”

What this means, exactly, according to the Internet Society is that ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers.”

 Readers, what are your thoughts – is this a step in the right direction? Stay tuned as we feature more experts weighing into the next steps on IPv6 ultimate roll-out.

TechWorld, Gang pulls off $5.2 million bank job via remote access
Network World, Data Center Networking Discontinuity Impacts Network Security
InfoSecurity, Breach at Zappos exposes data on 24 million customers
eSecurity Planet, RSA Chief: Conventional Security Defenses are Inadequate

With the release of Android 4.0 (dubbed “Ice Cream Sandwich”) upon us, we checked in with Tim Felser, NCP’s chief developer of mobile VPN clients, to talk about what this release ultimately means for Android’s VPN functionality.

VPN Haus: What impact will the Android 4.0 “Ice Cream Sandwich” have on the device’s core VPN functionality?

Tim Felser: VPN functionality in “Ice Cream Sandwich” was extended to support native IPsec connections, using XAUTH for user authentication. With this new option, it is possible to connect to IPsec gateways without any problems.
By using this API, it is also possible for you to implement your own VPN features. However, it remains to be seen if the device manufacturers integrate this API into their devices.

VPN Haus: Until version 4.0, no integrated IPsec VPN client was available on Android. What

technical challenges were possibly precluding this functionality?

Felser: There were no technical reasons why prior Android versions did not have native IPsec functionality. In versions before and including 4.0, Android’s IPsec functionality is provided by the IPsec-Tools, namely the raccoon service responsible for Internet Key Exchange (IKE) negotiation.

VPN Haus: Can you tell me about the tests that NCP conducted in which an Android 2.2’s integrated VPN client—based on PPTP or L2TP—was used in lieu of “real IPsec”? What are the key lessons learned for the enterprise?

Felser: In Android 2.x and 3.x, the integrated VPN functionality was limited to the following modes: PPTP, L2TP and L2TP over IPsec. These protocols are used to connect to Microsoft Server systems. We just concentrated on L2TP over IPsec because NCP’s software is capable of processing these protocols. The connection works as follows: first, an IPsec connection is established; this one is used for encryption. A plain IPsec connection is not good at authenticating a single user, so that’s the job of L2TP. So after the IPsec tunnel is established, the user is authenticated via a L2TP negotiation. A design flaw in Android leads to a security hole: L2TP and IPsec are not closely linked, so L2TP negotiation simply starts two seconds after IPsec was triggered, independent of a successful result of the IPsec negotiation. This may lead to plain unencrypted L2TP packets visible in the Internet. Fortunately, authentication is done via PAP or CHAP, so no plain text passwords are transmitted, just the hash values hash.

Result: We adapted our VPN gateway in order to establish this connection. However, this wasn’t a huge effort on our part, since we already supported both protocols beforehand.

Since posting our series on SSL myths, some people have asked how these SSL vulnerabilities apply to mobile phones. While mobile phones and other handheld devices are mistakenly considered relatively safe, this misnomer does not qualify as an SSL myth. It does, however, require addressing, as the consumerization of IT forces CIOs and network security architects to integrate these devices into the VPN structure.

Beyond the recent consumer-oriented, high profile hacks to celebrity address books, the danger to enterprises is being laid bare in a more subtle manner. In May 2011, Juniper Networks published a study that found risks to mobile phone security at an all time high, and cited a 400% rise in malware against the Android, for example. In 2008, critical mobile SSL VPN vulnerabilities were discovered by Christophe Vandeplas, as a laboratory example of the man-in- the-middle (MITM) exploit.

In mid-March 2011, after Comodo issued nine fraudulent certificates affecting several domains, Microsoft issued updates for its PC platforms to fix the vulnerabilities, but the company’s patch for Windows Phone 7 was  not immediately available. More details surrounding this attack were outlined in Myth 1. But clearly, the priority is not currently on the mobile platform, creating an undeniable threat.