This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Security

SSL VPNs and OpenVPN: A lot of lies and a shred of truth

By Charlie Hosner on September 28, 2005 (8:00:00 AM)

Share    Print    Comments   

I wanted to write an article on the strengths of OpenVPN, but I just can't get the message out without first talking about the serious insecurities I see in the rest of the SSL Virtual Private Network (VPN) space. The SSL VPN market has blossomed in the last five years in response to dissatisfaction with the traditional VPN technologies, namely the insecure Point-to-Point Tunneling Protocol (PPTP), and the complex and intrusive IP Security (IPsec) standard. SSL VPNs have roared into the VPN space with the claim of high security, ease of use, and robust feature sets that eclipse the existing technologies. Whenever I hear that combination of claims, my brow furrows and I see that it's time to start digging.
Part I: Bad SSL VPN vendor, bad...

When you are working with mature security technologies (like SSL/TLS), security is often a zero sum game. I realize that SSL VPNs are a new paradigm, but when you increase an architecture's feature set, you almost always do it at the expense of security. It is possible to squeeze out small incremental gains, but when someone says they have bumped functionality way up without compromising security, you need to take a closer look to verify these assertions. It is possible to gain in both areas, as we'll see when we talk about OpenVPN, but for the most part those kinds of claims have nothing but vapor and marketing push behind them.

The main architectural advantage of SSL VPNs is that they shed the complexity of IPsec in exchange for the simple, well tested SSL/TLS structure for their cryptographic layer. To this I say "Bravo!!" IPsec is a hard protocol to use effectively for a variety of reasons.

One, IPsec has too many possible configurations, some of which produce insecure architectures. The adage, "complexity is the enemy of security," is well illustrated by this excessive group of configuration options and structural components.

Two, the nature of IPsec requires it to be tightly coupled with the OS kernel. This is bad for any application, but much more severe when we're talking about critical security components. Since the days of Multics it has been well-known that in order to architect a secure, available system, you need to avoid interference with kernel space wherever possible. If your code can interfere with kernel space, its failure is usually catastrophic for the entire system. If your security code can interfere with kernel space, it can compromise your entire security framework with a single failure. Every compromise of a kernel-coupled component equals instant root access. IPsec VPNs are implemented in kernel space, SSL VPNs do not have this requirement. So, in theory, SSL VPNs are a great idea.

In practice we see this opportunity squandered in the name of selling more boxes. While some SSL VPNs are experiencing the gains I mention above, most are taking one step forward and three steps back by failing to adhere to many of the important architectural requirements of VPNs. The primary area of weakness is the notion of a "Clientless VPN."

In traditional VPNs, a server runs the central VPN software and each client has a local application installed so they can participate in the extended network. This client application is pre-installed and pre-configured by an administrator and is done on a per-machine basis. Users can not connect from any old machine they want. They are limited to connecting from their pre-configured machine. The obvious area for improvement here is to free our belabored user from the tyranny of pre-configuration, and instead let them start a VPN session from any machine they happen to be using. While this sounds just dandy to the layman, the security implications of this are extreme.

We can not have secure communication unless we know who is on each end of the communication link. Having a pre-installed client on the user's machine helps satisfy this requirement. Otherwise, it's like having a cell phone that guarantees an encrypted link from end to end, but dials a random number every time you call someone. You know for sure that no one can eavesdrop on your communication, but you have no idea who you are talking to. Doesn't sound very secure, eh?

Traditional VPNs vs. SSL VPNs

Traditional VPNs required trusted end points to function. The server and the client were machines with (one hopes) some elevated level of trust as our corporate administrator installed the VPN components on them personally, and covered both machines with the corporate security policy mandated controls. Additionally, authentication credentials were pre-installed on both of these devices so each endpoint could authenticate its peer and have a high probability of trust in the entity with which it was communicating.

SSL VPNs allow users to connect to the central VPN using any machine they happen to find. This includes their home machine, their kid's laptop, a public machine in a coffee house, or a public kiosk machine in Eastern Europe. Two severe issues arise here. First, we break the trust model. The server and client no longer share a pre-configured trust relationship. Instead, they have to attempt to build something on the fly. Barring a user who is able to remember some 1024-bit RSA keys, we are going to have to do this with passwords. This opens us up to trivial to implement Man in the Middle attacks that are well-developed and available to even the least-skilled script kiddies. Now all our information is decrypted by our attacker and it is very difficult for us to detect the passive exposure.

The second issue is that our users are connecting from machines that are not subject to our rigorous (again, I hope) corporate security policies. Even if our user manages to start an SSL session with our actual server (instead of a Man in the Middle) they are still doing all their input and output on an unknown machine that might well be managed by people who specialize in making lattes, not computer security.

If they are connecting from a public machine that is under the control of an attacker, they will be exposed to keystroke loggers and remote management tools that allow our friendly attacker to sniff passwords, collect all data from our session, and even watch the graphic interface as our user works with our sensitive corporate data. Security is a chain which is only as strong as its weakest link. With "clientless VPNs" your weakest link becomes some random machine in some random location.

In a weak attempt to reduce the risk of our users connecting from insecure machines, some SSL VPNs include the option to verify that connecting client machines have virus protection and a firewall enabled. This is what Bruce Schneier likes to call "Security Theatre" -- it creates the illusion of security, but doesn't actually provide any increased protection. How do they verify whether the machine has virus protection and a firewall? Well they ask the client machine of course! This is tantamount to asking a criminal if they are a criminal. You can not ask an entity to validate itself, this is security 101. Additionally, if you go ask an attacker what the first thing he/she does when they crack a machine, they will usually respond with "update the system so it's secure, and turn on a firewall so no other attackers will bother me."

With IPsec, our users are restricted to only connecting from pre-authorized machines, but we have the advantage that these machines are trusted and known endpoints that we can authenticate. With the modern SSL VPNs, users can connect from a variety of machines, but NONE of them, not even machines that could have been pre-configured, are safe from Man in the Middle attacks. Just to keep the flamers at bay, some SSL VPNs provide the option of installing certificates on client machines to fix this problem. Hey, that sounds a lot like installing client software, plus certificates aren't the default or even suggested configuration. Systems that are insecure out of the box are likely to be insecure in implementation -- not everyone is a security expert and can understand the subtle ramifications of their configuration choices.

The second area of concern I have regarding SSL VPNs is the increase in their complexity. The very reason we want to move away from IPsec is to avoid its complexity. SSL VPNs are now including complex access control systems, intricate routing features, and a myriad of port forwarding, application proxying, and even file-sharing capabilities. Some of these features, authorization and routing, belong in a remote access solution, but many are overblown or just not appropriate for a VPN. The reason we moved away from "everything to everybody" type systems is because they usually don't do everything right, and dramatically increase a hacker's attack vectors.

In a file server, we can tolerate some slop, but in our most essential security devices, this is not acceptable. That's why we have dedicated machines to handle VPN, firewall, routing, Web serving, email serving, etc. Many SSL VPN vendors have put us back into an environment where too many options are available to compromise our systems security. I saw one product that actually had a check box labeled "Allow Insecure Connections." This is ridiculous to see in a VPN device.

I'm only doing analysis here based on architecture; I haven't dug into how these SSL VPNs are actually implementing SSL/TLS. While I would say that some of these organizations (Cisco, Checkpoint, Juniper) should be quite adept at building crypto systems, the fact that they are missing the point on architecture makes me think they may be cutting corners on best practice crypto as well. Cryptography is tough to do right and variations as simple as the order that primitives are applied can totally break your security, as we saw earlier this year in broken IPsec implementations that would HMAC-then-encrypt instead of encrypt-then-HMAC. Time, and the reverse engineers, will tell.

The central flaw of most SSL VPNs is the variation in architecture that breaks the trust model necessary to provide the highest level of security, which most people equate with the label VPN. Security is a chain and the security of the entire system is only as strong as the weakest link. If the client is insecure, the entire system is equally insecure. The standard SSL VPN product has dramatically reduced the security requirements of the client machine in exchange for the flexibility to use the VPN from any device.

More on page 2...

 

Share    Print    Comments   

Comments

on SSL VPNs and OpenVPN: A lot of lies and a shred of truth

Note: Comments are owned by the poster. We are not responsible for their content.

Mostly agree...

Posted by: Anonymous Coward on September 28, 2005 09:22 PM
But, you must remember that we do not live in a perfect world and therefore perfect security may not be possible. Along with strong security we must also factor in ease of use and evaluate the cost of the risk.

The fact is that many businesses are willing to forgo the greater security of a client server VPN in favor of ease of use because the greater security hampers the user. Put another way, the clientless VPN enables greater efficientcy and productivity due to its ease of use.

Client based VPN's require the company to give the user a laptop and the user has to lug it around, both of which are often undesirable.

A clientless SSL VPN though not the most secure, is usually "secure enough" while offering sufficient convenience to increase user productivity. Protecting trade secrets for most companies is not as critical as protecting research data at Los Alamos. Additionally, with USB dongles that store encryption keys or with security tolkens, the risk to clientless VPN's goes down tremendously.

No, it's not perfectly secure but, we don't live in a perfect world and since there are no real guarantees in life, why would anyone expect it from a VPN?

#

Invalidating effective risk analysis

Posted by: Anonymous Coward on September 28, 2005 09:32 PM
"Along with strong security we must also factor in ease of use and evaluate the cost of the risk."

I agree with that statement, however, SSL VPN vendors are not explaining the weaknesses of their solutions or methods to configure these devices to avoid those weaknesses. They are doing this in the name of selling more devices and are sweeping the security issues under the rug. This is precluding non-security experts from performing valid risk analysis. So folks are implementing these devices and thinking (analyzing their risk) that they have the same security that their traditional VPN devices provided.

#

Re:Mostly agree...

Posted by: Anonymous Coward on September 29, 2005 12:22 AM
But, you must remember that we do not live in a perfect world and therefore perfect security may not be possible

In a perfect world you wouldn't need security.

#

Re:Mostly agree...

Posted by: Anonymous Coward on September 29, 2005 05:45 AM
Have you ever used the openvpn client? After I dare you to say it is not as easy as going to a web page (BTW not a little more insecure A LOT more insecure since now you bring in the http and all the exploits that involve that). First try the product before commenting.

#

SSL VPNs and OpenVPN

Posted by: Anonymous Coward on September 28, 2005 09:35 PM
Dear Charlie Hosner,

i fully agree with nearly every concerns you bring up here - the only thing i have to disagree is, that no commercial product is able to address those concerns.
Of course none of the so called Web VPNs from Cisco Checkpoint etc. are able to offer a full Tunnel functionality - but if you look at Aventail (which is regarding to Gartner, Forrester, Frost etc. the technical market leader) then you will see that they offer everything you wanted to have :
A full Tunnel Access (including Crossconnect and Backconnect possibility)invoked only by a browser and a couple of Appletts
Bidirectional Traffic Control inside the Tunnel
Full Control of the accessing Endpoints -
Different Levels of Access per Access Zone
Data Protection mechanisms like Cache Control if you access from a foreign Browser
Cross platform support and and and...

Of course, if you need a quick replacement for an IPSec in an small to medium environment, and if you dont need access without installing a Client then OpenVPN is an ideal(and very cool!) Solution.

But if you have Enterprise needs then you should seriously look for an Aventail<nobr> <wbr></nobr>;-)

regards
Volker Marschner

#

Re:SSL VPNs and OpenVPN

Posted by: Anonymous Coward on September 28, 2005 11:33 PM
Hey Volker,

Thanks for the response. Aventail does have a nice feature set, but my problem isn't with the features, it's with SSL VPN vendors selling themselves as Clientless VPNs. I believe they are misusing the term VPN, as their security is drastically reduced in this clientless state. That's my main thrust, customers do not understand the security trade off they are making in exchange for this clientless option, and I'll bet if you went and asked your (Aventail's) sales force whether or not they emphasize this trade off, you'll find that they don't. Why would they? It reduces sales. But I feel they have an ethical responsibility to educate their customers and they aren't doing it.

I certainly don't mean to pick on Aventail, I don't have direct experience with them so to a degree I am speculating, but I have talked with the sale force of several of the other SSL VPN vendors and not one of the mentioned this security trade off and most of them stared at me blankly when I brought it up.

Thanks again for your input!

--charlie

#

Re:SSL VPNs and OpenVPN

Posted by: Anonymous Coward on September 29, 2005 12:31 AM
Volker Marschner should have noted he's a paid employee of Aventail. It's considered good ethics, and etiquitte, to disclose such things when commenting on one's own, and competitors, products.

#

Re:SSL VPNs and OpenVPN

Posted by: Anonymous Coward on September 29, 2005 08:32 AM
>A full Tunnel Access (including Crossconnect and Backconnect possibility).

          OpenVPN has full tunnel access, read the article first your exaxtly the incompetent admin he is talking about. Its client just as easy if not easier then any java appelet.

Bidirectional Traffic Control inside the Tunnel

      OpenVPN has it and you can even control bandwidth. since the tunnel looks just like another interface.

Full Control of the accessing Endpoints

        This doesn't make sense since I don't know what youo mean by "control"??? I will assume you mean actually setting up the tunnels which is the function os the program.....so yes.

Different Levels of Access per Access Zone

      Getting tired of typing see 2 answers up.

Data Protection mechanisms like Cache Control if you access from a foreign Browser

          If you really believe that you can be "Secure" on a foreign browser by clearing cache then Aventail might want to re-think who they allow to endorse their product.

Cross platform support

      OpenVPN - MAC, Windows, Unix...sorry your apple newton or timex sinclair are not supported....oh wait thats right source in available so you can compile even for those....bet you Aventail will not run on those...

The ONLY thing that openvpn is lacking for enterprise is a central easy to configure large number of clients/networks. But again you're not paying $25,000+ for similair products!

#

What about UDP?

Posted by: Anonymous Coward on September 28, 2005 10:48 PM
Aren't the SSL VPNs based on TCP tunnels? And AFAIK using TCP tunnel to carry UDP is bad idea...

#

Re:What about UDP?

Posted by: Anonymous Coward on September 28, 2005 11:11 PM
I can't speak for many of the SSL VPNs, but OpenVPN uses UDP. It can be configured for TCP and actually works pretty well in that state, but UDP is the preferred method.

--charlie

#

Another tool for OpenVPN server

Posted by: Anonymous Coward on September 28, 2005 11:20 PM
Please, check the following tool too:
<a href="http://openvpn-web-gui.sourceforge.net/" title="sourceforge.net">http://openvpn-web-gui.sourceforge.net/</a sourceforge.net>

#

Corporate attitude

Posted by: SarsSmarz on September 28, 2005 11:43 PM
At our place, all the 'trendie' people are wearing those 'changing number dongles' for 'secure' vpn from home. It is very impressive, even if they are using zombie machines.

#

Re:Corporate attitude

Posted by: Anonymous Coward on September 28, 2005 11:51 PM
Yeah, I use RSA SecurID where I work, and that does help. But if you don't have some level of control for the remote tunnel end point, I can control the machine you connect from, and install some sort of access tool into your corporate network during your active session. The token based authentication will keep me from logging in as you, but after having a long enough period of unauthorized access during your logins, I will eventually find a way to make my access permenant.
Strong authentication is better, but it's no substitute for having a trusted remote endpoint.

--charlie

#

Re:Corporate attitude

Posted by: SarsSmarz on September 29, 2005 12:31 AM
Well, I've changed my mind, now. If you use your RSA from a totally infected machine, with all those hackers fighting each other; Or if you are flitting from one Nigerian cafe to another, then you are totally secure!

#

interesting comments

Posted by: Anonymous Coward on September 28, 2005 11:44 PM
You referred a few times to corporate laptops being theoretically secure and well managed. Well in my experience that's just not the case.

I know of one very large corporate where, to get round the hassle of IPSec VPN rollout, you can get the VPN client emailed to you. They reckon it's been installed on any number of home PCs. And thanks to the network extension style of access, you can get to everything in the organisation, whereas with SSL VPNs you only have access to specific resources.

What makes this worse is that many organisations believe that because they have a "controlled VPN", they don't need strong authentication. Therefore you get the "IPSec email", install the client, use the pre-shared key and the username/password in the email and you're into EVERYTHING.

At least with SSL VPNs, most people implement strong authentication - if you don't you really should have your head examined. This does add extra cost and complexity, but there are ways and means to reduce this. Portwise have an integrated VPN and strong authentication solution which is pretty cool (I know because I helped implement this for my previous company).

I strongly agree with the point about the stupidity of asking the device if it is secure. With Portwise I remember there was an option to scan the device but send the information back into the corporate network for a decision on what level of access could be granted.

We also evaluated some SSL VPN appliances and I could not believe how difficult they were to setup. I always thought the big deal about SSL VLN was the simplicity, but you definately need training before getting hold of one of those things.

#

Uninformed FUD

Posted by: Anonymous Coward on September 28, 2005 11:50 PM
One, IPsec has too many possible configurations

Yes, everything is not like you're personal winux/i386 based network<nobr> <wbr></nobr>...
For professionals, networks can get complex, you know, and need specifics
setups... Like many things not doable with OpenVPN

Also, not everybody needs simultaneously authentification and encryption,
or PFS, or non-repudiation<nobr> <wbr></nobr>... and want to spend money for ressources for
something they don't need. I mean, on large networks

Two, the nature of IPsec requires it to be tightly coupled with the OS kernel.
This is bad for any application,


Ah ? Then you're looking for an userland TCP/IP stack, I guess<nobr> <wbr></nobr>...

Didn't you understand why IPsec was in kernel ? it work at IP level,
IPsec is part of any conform implementation of the IP stack for next generation, IPv6
(the standard was later on backported to IPv4).
It is on kernels because IT IS TCP/IP.

And it need to be fast enough for high volume traffic of today networks
(having those crypto operation on kernel avoid many context switches and
memory copys). OpenVPN is for SOHO, small network with small traffic, with
very simple configurations needs.

IPsec VPNs are implemented in kernel space, SSL VPNs do not have this
requirement.


I guess you push packets on the wire from userland ? And you get
get random source from a random deamon rather than<nobr> <wbr></nobr>/dev/*random ? And you
don't use kernel crypto accelleration as provided by OpenSSL ? If you do
one of this, then you basicaly use the kernel for the same things IPsec does,
except that you get more exchanges with the userland.

You find more secure to have youre kernel get the data, push it to userland,
then userland push it back to the kernel, then the kernel does operations
(giving randomness, crypto, pushing packets to firewall or network
interface...) ?

Appart from this, don't you understand that the IPsec part residing on the
kernel shoud be as secure as the TCP/IP stack you rely on with OpenVPN ?
Other (non IP) parts of IPsec protocols (like IKE/ISAKMP) runs on userland,
like does OpenVPN.

After spending several days installing and configuring OpenS/WAN

Yes, so you tried the worst and weakest implementation of IKE/IPsec suite
ever, you failed, then "IPsec is crap" ? Then for all you're paper, IPsec
is the damn har thing to configure ?
Wouldn't it be more honest to test other implementations before writing all this ?

IPsec VPNs require administrators to install a client component on machines
that need to participate in this extended network.
[...]
OpenVPN uses the same architecture. No differences, no tricks. OpenVPN
requires client installation just like IPsec


Plain lies ! IPsec stack is included out-of-the-box on all modern OS.

IPsec for so long, because it provides the gold standard for device-to-device
communication over untrusted networks. OpenVPN matches this standard and takes
it a step further.


Well, you entirly miss the point here: IPsec is an IETF standard, while OpenVPN is
not a standard at all. Huge difference, you see ?
You can't make OpenVPN talk to you're infratstructure Cisco (or other)
router, simply because it's not standard (and not fast enough of course).
Actually any IPv6 compliant network stack implementation must support IPsec
(it means: windows, Linux kernel (2.6), *BSD, Mac OS X, Solaris, HP-UX,
Cisco, Juniper, Checkpoint VPN*, AIX,<nobr> <wbr></nobr>...).

The very reason we want to move away from IPsec is to avoid its complexity.


Very guessable from youre paper content. But then, you shouldn't have tried
to rant against IPsec like if you where a security expert<nobr> <wbr></nobr>...

we saw earlier this year in broken IPsec implementations that would

Again, you didn't you're homework, and you confuse what is from the
implementations and what come from the standards. The weakness was on the
protocol (the standard), not on "some broken IPsec implementations".
One design error is very infortunate. But IPsec as beneficied from a large
audit, reflexion, analysis from the expert community, as a standard process of the
RFCs writing, and still after this (because it's an industry standard).
OpenVPN can't have beneficied for such an in-depth audit (but design bugs -with
worst consequences, btw- have already emerged, see below).

easy-to-install clients for Windows, Solaris, Linux, BSD, and MacOSX. (Let's
see your Cisco or Checkpoint VPN do that!)


Yeah, IPsec is included in standard on all those OS (including Cisco IOS and
Checkpoint one). So there's nothing to install. BTW, by using a standard, all
those OS / devices can interoperate to make a VPN seemlessly.

With every compromise of an IPsec process, you get a free root shell.

Oh yes ? then you should try "privsep"'ed IKE daemons (like OpenBSD's isakmpd).
There the IKE deamon is chrooted and unprivilegied, as OpenVPN.
As for OpenVPN, that only a question of implementation (and in no way related
to IPsec standards).

It's the perfect symptom of youre paper: you doesn't see the difference
beetwheen the IPsec standard protocols suite, and the particular (and dirty)
implementation you tried. Can you get a "root shell" from a bug on the TCP/IP
implementation of you're kernel ? not so probable, and for the same reason,
you won't get a "root shell" for the kernel part of an IPsec implem.

And talking about implementation, OpenVPN doesn't have a good security record.
See, after a quick search for only the last two monthes OpenVPN vulns :

OpenVPN MAC Address Spoofing Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14608" title="securityfocus.com">http://www.securityfocus.com/bid/14608</a securityfocus.com>

OpenVPN Failed Authentication Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14605" title="securityfocus.com">http://www.securityfocus.com/bid/14605</a securityfocus.com>

OpenVPN Same Client Certificate Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14610" title="securityfocus.com">http://www.securityfocus.com/bid/14610</a securityfocus.com>

OpenVPN Packet Decryption Failure Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14607" title="securityfocus.com">http://www.securityfocus.com/bid/14607</a securityfocus.com>

You also miss an important point: beside you're (looking really SOHO and not
so professional, given you're hard time to configure it and to understand
IPsec basics) network routers and gateways are usually embedded devices, and
route a huge amount of traffic. There, no userland solution can be of use.

OpenVPN is slow, kernel IPsec implementations are fast. That is.

Oh, and by the way, IPsec implies crypto, but isn't at all an "SSL VPN"
(Do you know what the "socket" in "SSL" means ? See, network crypto != SSL).
Even youre title is unacurate.
You're entire paper is all FUD, uninformed and unbalanced.

#

Re:Uninformed FUD

Posted by: Anonymous Coward on September 29, 2005 12:50 AM
Good grief man! Are you the author of the IPSec spec? Why are you taking it so personally?

He offered a good paper that may have a flaw or two but, it is still far better than almost anything else on this site and is much more coherent than your post.

You posit that IPSec is already available in every modern OS. While this may technically be true it is very disingenuous. Firt off, few people are using IP V6 even if it does come with the OS. Furthermore, those OSes that include IP V4 IPSec implementations are so convoluted and difficult to configure and manage that almost everyone uses a separately installed third party client for their VPN implementations. It may be possible to natively connect a Windows 2000 system to a Cisco 3000 with the Microsoft IPSec client but that client sucks so badly that almost everyone will use a SafeNet or Cisco client instead. Let's be honest here before accusing someone else of spreading FUD!

Then of course there is the fact that regardless of whether the IPSec implementation comes with the OS or not, it must be configured by an administrator. Or are you going to suggest that the typical salesdroid roadwarrior can configure Microsoft's IPSec client themsleves, or even Cisco's for that matter. What's IPSec? What's IKE? What's ISAKMP? What's an IP address? What's my password?

You offer up security bulletins for OpenVPN which are indeed a fact. But, they are all denial of service issues. None of them are breaches. But IPSec is not without issues either and with the recently discovered problems with MD5 most IPSec VPNs that are older that 1 year at at risk, though I'll bet you think that everybody went out and bought new kit that could support AES256, no matter how unrealistic.

As for the slowness complaints... All encryption schemes are going to slow things down some what but, since 100Mbps wide area and internet connections are still very rare hardware throughput is still a paper tiger. The real issue with any encryption scheme is not hardware throughput but rather the 50% loss of already limited network bandwidth. Very few people need a VPN server that can push 100Mbps or more. Most people will require VPN hardware throughput to be FAR below 45Mbps.

Obviously you prefer IPSec solutions so, you should continue to use them and just chill. The article is recommending OpenVPN as a more secure solution over SSL VPN's but is still easier to implement than IPSec and in that respect it is dead on, regardless of your opinion.

#

Re:Uninformed FUD

Posted by: Anonymous Coward on September 29, 2005 05:17 AM
Good grief man! Are you the author of the IPSec spec? Why are you taking it
so personally?


Well, you're right I should have had more polished word (beside this, I'm far
to be a native english speaker, so I can't do much subtlety on the wording).

Anyway, this article sound like a troll, so no wonder where irritation come
from. How necessary is it to spread such inacurate bullshit on IPsec and most
other OpenVPN alternatives all the long to show the OpenVPN strong points ?

I also like OpenVPN, and prefer it over IPsec for certain usages, but really,
such a biased article only gave the need to take the oposite side to
restore balance. In particular when it comes to be wrong.

I've (as network security admin) suffered from many networks breakages
(and even intrusion, at the vtun ol'time) because of PHB coming arrogantly
with the latest ultra-cool-vpn-thingy seen on a random website for executives
to install for yesterday on an already designed network..., so here about
more personal motivations.

He offered a good paper that may have a flaw or two but, it is still far
better than almost anything else on this site and is much more coherent than
your post.


But I don't pretend to write a new article telling the world what security
of networks is<nobr> <wbr></nobr>... sorry, a comment doesn't claim the same authority than an
article

Furthermore, those OSes that include IP V4 IPSec implementations are so
convoluted and difficult to configure and manage that almost everyone uses a
separately installed third party client for their VPN implementations.


Not quite. All the OS I cited have IPsec for IPv4. And (except, yes, Windows)
native stack is very widely used, I think, when IPsec is needed.
For the windows exception: Microsoft try to encourage a mixed l2tp with
IPsec tranport usage (rather than IPsec tunnel). So in order to make it
integration easy with pure IPsec solutions, a third party client may be
better. Anyway with an l2tp capable "serveur", the builtin stack is very
efficient, and (as far as we talk of easy deployment) integrates well
with tools for software configuration management.

Or are you going to suggest that the typical salesdroid roadwarrior can
configure Microsoft's IPSec client themsleves, or even Cisco's for that
matter. What's IPSec? What's IKE? What's ISAKMP? What's an IP address? What's
my password?


That's really not the point of the discussion. The article isn't
about those people (and when would them try to implement or setup a
corporate security policy ? that not theire job). They won't manage
certificates either, nor configure OpenVPN.
A VPN solution mostly implies gateways, configured by administrators,
If workstations are concerned, entreprises needs deploying facilities:
integration with the tools for centralized deployment, administration
and management.

Most people will require VPN hardware throughput to be FAR below 45Mbps

Seems like you weren't talking about (in my experience, pretty common) case
of remote access to file servers, did you ?

But IPSec is not without issues either

I didn't said the contrary, in any way. I said that claiming the superiority
of ovpn over IPsec for security as he does is just not serious. He does
this for a very large part of the article, so it worst be contested.

but is still easier to implement than IPSec and in that respect it is dead
on, regardless of your opinion.


Well, it seems that I didn't made it clear enough on the comment: this
assertion as no sense ! No one can say, comparings those, that one is simplier
than the other. As a proof, let me claim, just to take the opposite side,
that IPsec is easier:
1- because there are differents implementations of IPsec tools, with different
"ease of use" levels.
(Free|Open|Strong)Swan are (at my knowledge) among the ugliest. For instance
to have a simple yet working IPsec setup on two OpenBSD 3.8 gateways, I only
need to edit two config file lines on each (using the 'ipsecctl' tool).
2- because the wide possibilities of differents IPsec implementations allows
things that would need nasty twisted shell scripting with ovpn on unix, and
nearly impossible with ovpn on win : auth and certs fetch trough ldap, auth
tokens on smartcard and other pkcs#11 devices, usage of enterprise PKI
solutions (involving OCSP, CRL, precise usage of certs fields), pre-auth
trough biometric devices, keys in reverse dns (and "opportunistic encryption")
etc...
3- because in many place, integrating with existing setups (that implements,
surprise, standards protocols), like routers, is only possible with this.

#

Re:Uninformed FUD

Posted by: Anonymous Coward on September 29, 2005 10:03 AM
*"I also like OpenVPN, and prefer it over IPsec for certain usages."*

          Name your uses, please on why you think IPSEC is better. (don't tell me to read your first article either bonehead, I want direct comparing IE gateway-to-gateway IPSEC is better becuase<nobr> <wbr></nobr>....

*"I've (as network security admin) -LOL- suffered from many networks breakages
(and even intrusion, at the vtun ol'time) because of PHB coming arrogantly
with the latest ultra-cool-vpn-thingy"*


          Read this guys article before you reply, openvpn itself has had NO security bugs. So what, every kernel exploit should count against IPSEC well I don't have enough time in the next 10 years to list those

*"That's really not the point of the discussion. The article isn't
about those people (and when would them try to implement or setup a
corporate security policy ? that not theire job). They won't manage
certificates either, nor configure OpenVPN.
A VPN solution mostly implies gateways, configured by administrators,
If workstations are concerned, entreprises needs deploying facilities:
integration with the tools for centralized deployment, administration
and management."*


          You've obiviously not worked in any company larger than 12 people (please save your BS reply about 'working in a fortune 10 company' blah blah). Your post proves it so let me tell you now "YOU WILL ALWAYS HAVE TO WALK USERS THROUGH TROUBLESHOOTING" and believe me most admins (BTW I have set-up many(25+) IPSEC VPNSs working for a company that specializes in them), nevermind users, have issues with ALL IPSEC clients. Have you ever set-up an openvpn client? then you would know that 3-5 simple lines are better than 15-25 complex network jargon. Listen if you want use IPSEC no one is stopping you, no one is stopping you from re-write std.io either, what we are trying (unsucessfuly it seems but maybe we will drill past the concrete) to tell you is there is a better PROVEN (SSL is not some ultra-cool-security-thingy) solution out there. And believe me as it gets better, through-put will exceed IPSEC. IPSEC is old-school (interesting that you forgot to mention the NAT transveral issues that to-this-day almost ALL ipsec implemetations have) and for a time when engineers where still testing/setting-up networks but we have grown up kid so if you wish stay at the kid's table thats fine, but when you're ready to sit at the adult table we'll be here to baby step you there.

*"For instance
to have a simple yet working IPsec setup on two OpenBSD 3.8 gateways, I only
need to edit two config file lines on each (using the 'ipsecctl' tool)."*


          Yet another sign of your inexperience in large networks....openBSD so what you are planning on having all users use openbsd, would love to see how openbsd works on a new viao? Change frightens weak people and your frightened we all see that...so with every release OpenVPN will be easier, more secure to the point where even a monkey....uh I mean, you can use it.

Listen, simple fact: IPSEC is too complex and too bloated with useless features to be effective. OpenVPN address those better than any other product out, nevermind if you include cost!!!

**OH BTW before you post you're ill-informed reply rant, which I will read then mutter "idiot" at the end, you may want to first convince someone else first why IPSEC is SSSSOOOO good. His name is Bruce Schneier, being that you're a noob to this whole "security/vpn" thing just know this guy knows what he is talking about I won't go any further becuase I'm not a kindagarden teacher. He wrote an interesting paper evaluting IPSEC read : <a href="http://www.schneier.com/paper-ipsec.pdf" title="schneier.com">http://www.schneier.com/paper-ipsec.pdf</a schneier.com>
and if you have issues reading it, I'll save you the trouble, he says IPSEC is too complex and too bloated with useless features....sound familiar??



 

#

Re:Uninformed FUD

Posted by: Hideki on October 02, 2005 11:20 AM
Calm down...I don't know whether you make bold for readability or enphasizing your emotion but anyhow, IPSec is too damn complicated for something like SOHO and whatnot for sure, I've given up using Linux router for Ipsec due to sparse documentation (something understandable in a 5th year unix user...) and way too complex ipsec.conf and whatnot. And for the being of article, the author points out the point just fine.

I guess we're not the real security network experts, but OpenVPN has its place, IPSec has its place, so it's not like 'IPSec sucks completely' all the time... Choose what you want, both is said to have good security.

And I just wanted to say 1 thing to the topmost of this thread is even all OS you mentioned may have IPSec installed, you can't make a network to network router out of them. Windows client machines just don't work that way. And even if whatever OS with default IPSec does the job, you can't most likely out of Windows or Mac OS can touch any of the detail of the IPsec, unless you open up deep inside registry or something. So out of current condition, I agree OpenVPN is a good solution that is manageable to some good extent with decent security and cross platform.

Otherwise, it just seem like OpenVPN is never used anywhere.

#

OpenS/Wan : bad example !

Posted by: Anonymous Coward on September 29, 2005 12:30 AM
Do you know why FreeS/Wan (ex-Openswan code) was never included in the mainstream Linux kernel (and why D. Miller prefered to rewrite the stack himself) ?

Because it was an ugly mess of bad spaghetti code.

OpenS/Wan inherit all those deficiences in the remaining parts (IKE). So : don't get fooled by this very very bad implementation. Please, give a try to KAME's ipsec-tools (racoon) or OpenBSD's isakmpd: IPsec suddently look far easier. And far more powerfull than OpenVPN.

#

Re:OpenS/Wan : bad example !

Posted by: Anonymous Coward on September 29, 2005 09:03 PM
Again in the real world not everyone is running openbsd or freebsd or linux. You have to be easy to confure for all platforms.

#

Re:OpenS/Wan : bad example !

Posted by: Anonymous Coward on September 30, 2005 07:04 AM
That's right, but AFAIK Openswan runs only on Linux, where we have other choices (like the ones cited above, and some other).

#

Re:OpenS/Wan : bad example !

Posted by: Anonymous Coward on September 30, 2005 09:56 AM
OpenS/Wan really has it ways. But i believe that the
it is far more complicated than openvpn to deploy. I'm not counting here it's portability, because you can only deploy ipsec (the real one) in posix-like operating system. The clients for windows, or they miss some feature, or they require you to wide open your ipsec implementation. If we talk about the pair L2TP/IPsec, the ipsec become a fair play, but it loose some of it's security (AH transformation), and only give you the ESP encapsulation. And i'm not even mentioning the fact tha openvpn need only 1 single port (TCP or UDP) and is NAT traversal by default.

#

DIY VPN with OpenSSH and Samba

Posted by: Anonymous Coward on September 29, 2005 12:34 AM
Well, you could simply use an old favourite and trustworthy solution - OpenSSH, as described here: <a href="http://www.aerospacesoftware.com/samba-ssh-tunnel-howto.htm" title="aerospacesoftware.com">http://www.aerospacesoftware.com/samba-ssh-tunnel<nobr>-<wbr></nobr> howto.htm</a aerospacesoftware.com>

It is platform independent and works between any kind of machines, eg: Linux/Linux, Windows/Windows and Linux/Windows.

#

Re:DIY VPN with OpenSSH and Samba

Posted by: Anonymous Coward on September 29, 2005 01:10 AM
That's great for securing your Windows/Samba file transfers but, it doesn't give you a VPN. Virtual Private Network(VPN), the key word is network.

With a real VPN, your IP traffic is secured, regardless of what that traffic is. This means more than secure file transfers. It means that your ICMP, SMTP, NCP, telnet, HTTP, VoIP, MS SQL, RDP, RTSP, RIP, OSPF and any other traffic is all encrypted. If all you want is to secure Samba file transfers, you could make life simpler by using WebDAV via HTTPS like iFolder and others do. That way you wouldn't need to install and configure Putty on the Windows machine.

#

FUD on MITM?

Posted by: Anonymous Coward on September 29, 2005 01:53 AM
I don't see how using passwords over SSL subjects you to MITM attacks. Maybe that was not the intent of your writing, but that's how I read it.

If you only authenticate the server with certificates, then the client will know it is talking to the right server. Any SSL client worth its salt will check that the host name embedded in the server cert matches the actual host.

Now the question becomes how does the server authenticate the client. Passwords is one way. Assuming no hackers have ready access to a legitimate users passwords this is secure, and does NOT subject you to MITM attacks. Another way is to use client certificates, potentially in addition to passwords. This makes it slightly more inconvenient on the users part. The VPN admins need to issue each user a certificate, and users need to tell their VPN client to use that cert whenever connecting. If you carry your cert on a keyfob/smart card, it is pretty easy. Another way would be to copy the certificate around (less secure).

#

Re:FUD on MITM?

Posted by: Anonymous Coward on September 29, 2005 02:24 AM
"I don't see how using passwords over SSL subjects you to MITM attacks"

He's talking about connecting from a public machine to an SSL VPN, and the risk that the public machine could have spyware installed.

#

Re:FUD on MITM?

Posted by: Anonymous Coward on September 29, 2005 10:09 AM
Thanks I was going right a long answer to this boob's mis-understanding....you said it pretty well.

#

Re:FUD on MITM?

Posted by: Anonymous Coward on September 30, 2005 01:09 AM
That's not how MITM attacks are defined.

Running malware is a different problem.

#

Re:FUD on MITM?

Posted by: Anonymous Coward on September 29, 2005 10:11 AM
The only reason SSL HTTP (HTTPS) isn't generally subject to MITM attacks is the fact that HTTPS certs are signed by trusted third party signing agents which are embedded in the browser (I could easily create a self-signed cert for www.microsoft.com, but because it's not signed by the trusted third-party, people would get a warning during the connection). SSL VPNs don't typically use third-party signed certs, so the only way to validate the cert is either through it's "fingerprint" as you would do with SSH or some other out-of-band transportation of that trusted cert. If you do not validate the certificate any MITM attack is relatively easy to carry out (via ARP spoofing, DNS poisoning, etc). The attacker merely needs to provide his own cert to your client with the proper hostname, and decrypt the data you send him, and re-encrypt it with the real server's cert before relaying it.


Client certificates get around this because presumably the server knows exactly which certs are issued and which are not, so when the attacker connects with a bogus cert, the server can react appropriately. Fixing the MITM attacks possible with only passwords over SSL requires similar effort to deploying client certificates. If you're going to take that kind of effort, you might as well just deploy client certificates and be done with it.

#

Right tool for right job

Posted by: Anonymous Coward on September 29, 2005 07:29 PM
I'll preface this by saying I currently work for a SSL VPN vendor but hopefully the comments are still valid.

Most SSL VPN's are installed with one or two apps in mind and that has been the traditional area for SSL's, web apps and single apps at a time, basically a SSL VPN has more of an app centric view than a network centric view, though this is changing.

What this means is that you allow access to a single app at a time, making hard for a virus infected machine to use the SSL unless it is targetted at that specific app.

Also as the idea is that its access from anywhere you define your policies with that in mind and if you have half a brain start with denial by default setup. You then open access based on authentication mechanisms, client device being used, corporate or not corporate, client device scans, user group memberships. For example, user1 logs in with standard username and password from a web cafe they only get webmail with not ability to download/upload attachedments, same user logs in with a RSA token from their corporate laptop that has been check for running (up to date) AV you let them have full mail client.

This isn't really a SSL v IPSec arguement its simply a case of making sure you define a policy that covers all bases, simply using a SSL which installs a local tunnel client (as we all have to do) does not make the machine anymore insecure, a bad secure policy does that.

Of course I could just install a local VPN client and have a straight connection into the corporate network with everything then wide open<nobr> <wbr></nobr>:-)

#

Some corrections

Posted by: Anonymous Coward on September 29, 2005 09:31 PM
I agree that PPTP's time has passed unless you have very modest security requirements or ease of use is paramount. PPTP is also not standards compliant (but nor is OpenVPN). I also agree that IPsec is a complex standard and it is very hard to create an IPsec implementation. But IPsec is not hard to _use_ anymore. Yes, there are many possible configurations but Openswan uses sensible defaults. Anyone should be able configure a basic IPsec VPN with Openswan in about 10 lines.

Kernel integration also has its advantages. It's faster, for one. Encryption takes a lot of horsepower, you know. Installation is a non-issue: most operating systems ship with built-in IPsec. Pocket PC, Linux, BSD, Mac, Windows, you name it. No client installation required. And you only need a kernel recompile if clients are NATed and you are using Linux kernel 2.4 (or kernel 2.6 with KLIPS instead of the native NETKEY). Recompiling your kernel on a regular basis as Charlie suggests is nonsense.

I agree that asking the client to do an assessment of itself is stupid. But it should be able to detect 'simple' compromises such as virus infections. Still, this is basically security through obscurity which is always a bad idea. It will not withstand a targeted attack (e.g. corporate espionage). SSL VPN vendors do not seem to understand this and Charlie is right in bringing it to our attention.

Unfortunately there are also a few errors in Charlie's article. His statement about "broken IPsec implementations" is incorrect. IPsec uses encrypt-then-authenticate. The reported "flaw" refers to IPsec implementations that are purposely configured by the user to do encrypt-then-no-authenticate. This is asking for trouble and one should expect to be attacked. Therefore most IPsec implementations don't even allow such a broken configuration.

Another error is that OpenS/WAN does not exist. The correct name is Openswan. Installation of Openswan couldn't be more simple. It is included with most distributions, either in the base packages or in the contributed packages. I'm sure that compiling the tar ball is a no-brainer too, but I never had to resort to it.

Disclaimer: I am the author of an Howto on L2TP/IPsec at <a href="http://www.jacco2.dds.nl/networking/" title="jacco2.dds.nl">http://www.jacco2.dds.nl/networking/</a jacco2.dds.nl>

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 01:54 AM
Jacco,

Thanks for taking a second to provide some useful corrections. You of course are right, Openswan, I'm still suffering from FreeS/WAN hang over.

You are also correct in pointing out my use of the term "broken IPSec" when it should be called "misconfigured IPSec" or "broken IPSec configurations". Again, thanks.

I've noticed several commentors really focusing on the speed advantage from IPSec. It is clear that IPSec will be faster, but how often do you really sack out your CPU on your VPN devices? I think the much more common bottle neck would be bandwidth, rendering the IPSec speed advantage much less important. Perhaps there are some people out there with enourmous pipes that have thousands of VPN connections pumping huge amounts of traffic which could overload their machines and they might well want to install an IPSec device (or many). But I doubt this is really a common problem.

Regarding standards compliance which you just lightly touched on, I know the IPSec community is really focused on the "we're a standard" line, but how often in real implementations does that work out for them? Turn on Cisco's (or any vendor's) NAT traversal features and your interoperatability is gone. And this is not an uncommon feature to use. You didn't really make a big deal about standards but I wanted to get this out anyway. I think standards compliance is a shaky advantage at best.

"Encryption takes a lot of horse-power" This is definitely the age old comment and it was very true for a long time, and still is true if you use outdated algorithms. I'm still surprised to see so many VPN implementations (SSL and IPSec) using 3DES. This just blows my mind. When you move to algorithms like AES or BF (OpenVPN default), the encryption load is massively reduced. The only real area of concern is the handshake and unless you have a super huge implementation, you aren't going to be overwhelmed with handshakes.

The fact that IPSec is faster is undeniable, but I just don't see that having much of an impact in real world implementations. I'd appreciate anyone supplying numbers to the contrary, I'd be very interested in seeing specifics. Maybe I'm wrong, but I don't think there are too many folks out there saturating their T3 with VPN traffic. A fairly small system can keep up with encryption at 45Mbs. So maybe IPSec is 50% faster, but if you're talking 155Mbs as opposed to OpenVPN's 100Mbs, it doesn't really matter. We're both getting the same amount of data over the wire. The above numbers are non-sense of course but hopefully they help to illustate the point.

Again, thanks for pointing out those errors and bringing up a couple good points. I appreciate the information and the perspective.

--charlie

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 04:58 AM
Thanks for your comments, Charlie.



I'm not sure about where the bottle neck is. As a rule of thumb, I guess faster encryption speed is always better. In some scenarios such as embedded devices the CPU may actually be the bottle neck.



Regarding standards, I don't know why you are mentioning NAT-Traversal because it has been ratified by IETF months ago. Yes, there are still some NAT-T interoperability problems but these are being worked on. I do agree that standards are not always what they are cracked up to be. For instance when a standard is not really an open standard or when there are licence fees. However, standards do buy you a couple of things:

  • You can replace a VPN server by one from another vendor (in theory)

  • Smart people from industry and academia (including real cryptographers) have looked at the standard.

  • Interoperability. Sometimes you don't control what the other side is running.



You're right that IPsec often uses 3DES (or much worse: DES). That is the default on most VPN servers. I'm not sure if system administrators were simply too lazy to optimise the settings or that AES, Blowfish et al. were just not available. Most implementations I have seen (Linux, BSD, Mac, Safenet etc.) support these ciphers. Windows is one of the few counterexamples.


Jacco

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 06:12 AM
I don't know why you are mentioning NAT-Traversal because it has been ratified by IETF months ago


    You're kidding right? Months ago? come on I still know people running 2.2 kernel. It will be years, if ever, when admins change/recompile IPSEC for NAT issues. I'm sure whatever solution they came up with was painstaking they are not going to throw that away so soon.


        * You can replace a VPN server by one from another vendor (in theory)

        * Smart people from industry and academia (including real cryptographers) have looked at the standard.

        * Interoperability. Sometimes you don't control what the other side is running.


      Well the first and third point are almost the same. In this day and age of security concerns you don't care what the other side is running? Listen if some admin tells me they only run 42-bit PPTP I'm not going to connect with them!!! if they are running cisco, check point etc then I will "try" to connect w/IPSEC becuase as anyone who has tried knows it's not easy in fact I'm pretty sure cisco and checkpoint made it that way on purpose. On your second point, you're right smart people have looked at it...www.schneier.com/paper-ipsec.pdf and they have pretty much said "it's old, outdated, too complex (it was written in 1999 so it's not like a 1980 paper)". Not too many "I really enjoyed setting up IPSEC" papers out there. Try openvpn and if you have every installed & configured IPSEC to gateway-to-gateway AND workstations you will say "I really enjoyed setting up openvpn".

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 08:29 PM
come on I still know people running 2.2 kernel.

And this is for you a reference among good security practices ? come on, you are just a troll.

On your second point, you're right smart people have looked at it...www.schneier.com/paper-ipsec.pdf and they have pretty much said "it's old, outdated, too complex (it was written in 1999 so it's not like a 1980 paper)"

One opinion. An army of specialists have designed that protocol suite, and made IPsec evolutions. Hundreds of people have implemented it for the many operating systems (this means that they have actually evaluated it very deeply).

And how many serious people have evaluated OpenVPN ? no one. The author have made one implementation.
Wow, pretty deep audit !

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 09:38 PM
I'm assuming this is still Jacco,

You are completely correct, IPSec is relatively mature and has undergone a lot of scrutiny and was developed by a group of smart folks (which is also part of the problem). OpenVPN is still pretty new and has not had the same level of attention.

You kind of discount the Bruce Scheier reference as just one guys opinion. It is actually two guy's opinions as Niels Furgeson co-authors that document, and it happens to be the two guys who are the leaders in the field, so their opinion, in my opinion, carries alot of weight. Just my opinion.

Anyhow, if you read the link in the article that refers to Peter Gutmann you will see he has done a cursory review of the product but by no means a deep dive. The one advantage OpenVPN does have is that is uses the SSL/TLS handshake and encryption methods, which are the most reliable, most mature, most widely used crypto structure available today. There may be problems with the implementation, and maybe not, but the use of that mature crypto library helps me sleep better at night.

And I've done a lot of implementations with OpenVPN and so have the people who populate OpenVPN's mailing list. Again I'm not suggesting that the product itself is anywhere near as well tested as IPSec, but again, I think it's important to weigh in the fact that SSL/TLS is much more mature than IPSec. You take some risk using any new (less than 5 years old) product, but my confidence is high for a lot of reasons with OpenVPN.

Thanks for your comments. You definitely have some good points and I'm glad you've brought them up.

--charlie

#

Re:Some corrections

Posted by: Anonymous Coward on September 30, 2005 09:52 PM
" You're kidding right? Months ago? come on I still know people running 2.2 kernel."<nobr> <wbr></nobr>...
"Listen if some admin tells me they only run 42-bit PPTP I'm not going to connect with them!!!"

This sounds like contradiction... what if the guy with 42-bit PPTP doesnt have support for stronger encrypton? tell him to update his system? so why not update the system kernel too?

two wheights two measures uh?

#

Being fast for embedded devices

Posted by: Anonymous Coward on September 30, 2005 07:00 AM
I believe IPsec wasn't thougth only for computers; dont forget that it's part of the larger IPv6 plan, where many more devices may become part the network, suddently.

Those embedded devices, like phones, PDAs, home routers, access points, etc. have very slow cpus. And do you see how slow is https (so, userland SSL) on phones ?

That's why we also need a protocol that is fast. For industry, this means smaller and cheaper cpus, less power consumption etc.

That's also why we need protocols that make them interoperate as is: we won't install softwares anywhere, as we do on the desktop ; but still we want to have the PDA, the modem-router, the AP, and the phone networked together (even if we replace the brand of one of them) right ?.

To be honnest I don't know any IPsec'ed or IPv6'ed phone just now, but it's begin to be comon on access points, and I'm confident this needs will increase.
So it makes sense to have a protocol with the lesser overhead, for those small cpus, and standard enough to make very differents devices able to communicate without hassle.

Making VPNs on a pure fasts computers environment is another matter of course.

#

misleading and biased

Posted by: Anonymous Coward on September 30, 2005 09:16 PM
Hm... this paper looks a bit biased and misleading... while its true that ipsec had a flaw, the paper omits that the same security advisory proposed three solutions to the problem, so its not need to update your installation to the latest ipsec implementation.

Ipsec is not perfect, but openvpn isnt the vpn's holy grail.

#

About OpenVPN...

Posted by: Hideki on October 02, 2005 10:37 AM
I haven't read all the comments, so bare me if I'm repeating but OpenVPN isn't completely off the kernel like the author keep repeating.

Tun/Tap device IS a kernel module, I don't know which Linux distribution turns it on by default, but for my Gentoo Linux, I had to make a module and load it up. And so is for Mac OS X, you need a kernel extension downloaded and installed in.

At least all the functionality does not go inside the kernel module, it's just a virtual device for the end points, so still you have a point that most likely it won't fail the entire system with OpenVPN, unless that module is deficient.

#

Mini review of own

Posted by: Hideki on October 02, 2005 10:51 AM
I've tried quite some free VPN solutions and I must say OpenVPN is pretty neat.

The author wrote just about most of the good points so I won't repeat, but for the sake of cross platform, which is very important that you can set this up in your own environment, not like have to replace your network to Linux-Linux or whatever it only runs on.

And then again, the firewall rule is you only need to open 1 single UDP or TCP port, NAT is no problem, this is very good.
Even VPN server is behind the router, it just works, no need to open 2 or 3 ports along with a protocol as in IPSec.

And the author of OpenVPN has thought out the configuration very well, it doesn't have to have any external ip configuration to get the routing done since all you need to get network to network settings can be set in the OpenVPN configuration itself, along with other security options.

The next one is of course, even if the connection hangs up due to one side going down and whatnot, it brings it back up just fine when the connetivity comes back up, so it's not like you ever have to restart the service once you have run it on start up. It even determines connection from different IP since one side has dynamic IP assigned and changed but will switch to that IP when all the authorization passes.

And just to say, 'it just works'. Tried l2tp/ipsec, pptp, vtun, openvpn. Vtun comes close to being easy, but as noted in the document, it's likely the security is a bit rough on the edges, for other ipsec implementations, they exist as both client and server, but it's just plain impossible to get it running on Linux, way sparse documentation on web/readme/man page. I have given that up.

Can't believe you get all this for free in GPL...
Nice work.

#

Re:Mini review of own

Posted by: Hideki on October 02, 2005 10:55 AM
Something you want similar in IPSec or other implementation all you can do is to shell out $$$, unless you want sleepless weeks and less hairs and configuration even unknown to yourself after you run it...

#

hhh

Posted by: Anonymous [ip: 190.65.138.162] on August 15, 2007 12:23 AM
fdgf

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya