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.

After spending several days installing and configuring OpenS/WAN, I went looking for an alternative.
Installing brittle kernel hacks in order to get my VPN up and running just didn't seem right. "It can't be
this hard," I kept saying to myself.

I had the feeling you get when you go through some horrible installation procedure (Oracle) and wonder
why it had to be so ugly, when all you need to do to install something as complex as Apache is
./configure; make; make install. I'm not ignorant to the fact that IPsec VPNs are kernel-
coupled, and Apache runs as a user space daemon, but as a user and administrator, I just don't care. I want
a product that installs easily, isn't brittle, and is straightforward to configure. I was sure there must be a
better way, and fortunately there is: OpenVPN.

I stumbled across OpenVPN at the perfect time, the summer of 2004. They had just released a client for
Windows and were about to finish version 2.0 -- which included robust centralized client configuration,
and more powerful traffic-shaping tools. The installation looked simple, and the security was based on the
tried and true SSL/TLS libraries. It seemed like it was worth a look.

I did some research and found the famous VPN article by Peter Gutmann which slammed the rest of the
open source VPN market, but singled out OpenVPN as a potential winner. I dug deeper. The install
instructions made my heart leap, ./configure; make; make install. The hook was set. The
deeper I got the happier I became. Finally! An open source replacement to IPsec VPNs that provides the
same feature set, plus some sane additions, but doesn't carry the kernel-coupled complexity that makes
traditional VPNs such a headache.

A look at OpenVPN
OpenVPN uses the SSL/TLS libraries and structures to manage its cryptographic layer. The dual
authenticated SSL/TLS key agreement/exchange method is almost identical to IPsec's Internet Key
Exchange (IKE), and OpenVPN implements a tunnel system like IPsec's Encapsulating Security Payload
(ESP) that has equivalent or better security to our venerable standard. The crypto algorithms available to
OpenVPN include all the heavy hitters you know and love, with the default setting of RSA authentication,
Diffie-Hellman key agreement, HMAC-SHA1 integrity checks, explicit IV, and symmetric encryption
using Blowfish in CBC mode -- an excellent stable in my opinion.

What does all this mean to the layman? It means OpenVPN is able to create and maintain tunnels with at
least the level of security found in the best IPsec implementations. This is important. There's a reason
people have tolerated 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.

Before we move on, I want to take a second to be really clear about one point. There is a terrible
misconception that any product labeled "SSL VPN" is not a real VPN, and only provides some sort of
bastardized access using a standard Web browser. IPsec provides what is commonly referred to as
"network extension." This means exactly what it sounds like -- you extend your private network to
include machines that are outside your local network's circle of control and likely will need to cross
untrusted networks to reach your LAN. To accomplish this and maintain a sane trust model, 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, and this is a good thing. OpenVPN makes the client issue less painful by providing easy-to-
install clients for Windows, Solaris, Linux, BSD, and MacOSX. (Let's see your Cisco or Checkpoint VPN
do that!) But the real point here is that OpenVPN's network extension architecture is exactly the same as
IPsec devices.

Many of the so-called SSL VPNs emerging lately tout their "clientless" architecture and claim you can
get VPN access using a simple Web browser. This has serious security implications that we've already
covered, but it also has feature limitations. Many of these products are just doing port forwarding, Web
proxying, or "Webalizing" of protocols on a one-at-a-time basis, not true network extension.

I think we all know that it's not a very robust solution to handle protocols one at a time. What happens
next week when a new cool protocol comes out that you want to run over your VPN? IPsec, and
OpenVPN, handle network extension on a link level basis and can allow all protocols, all traffic, to
traverse the VPN tunnel.

The real magic in OpenVPN is accomplished by its altered design paradigm. Instead of a kernel module,
OpenVPN is implemented as a user-space daemon. Network interface access is managed using the virtual
TAP/TUN drivers that are standard fare in most modern operating systems.

This simple change enables a host of flexible features and security improvements that leave IPsec in the
dust. The two most important options by far are the ability to downgrade the server's privileges to user
nobody, and the option to chroot the server daemon, both meeting our security philosophy of the principle
of least privilege.

With every compromise of an IPsec process, you get a free root shell. Not a bad deal, eh? If you happen
to find a way to crack an OpenVPN instance, all you get is an unprivileged user trapped in a fairly sparse
directory. This is a big improvement in my mind. Many clever folks out there may eventually be able to
wiggle free of this restricted environment, but it will take some time, time I can use to detect and react to
your breach. Instant root shell à la IPsec doesn't give me any breathing room or protection even from less
talented attackers.

Protection from worms

Not only was I impressed with the security OpenVPN provides for the present, but I also discovered
another very interesting feature, future worm protection. What makes a vulnerability "wormable"? Well,
you want a remotely exploitable vulnerability that can be automated and implemented efficiently and
provide a useful level of access into your target system so you can access OS tools to further propagate
the infection. You also want a large homogenous installed base of machines that are all vulnerable to the
exploit so you get the most bang for your buck. Who wants to write a worm to infect 10 machines? No
one, it's just not economical.

The OpenVPN designers realized this and put a great option into OpenVPN to diffuse the standard worm
attack, tls-auth. What this option does is allow you to designate a key that all your VPN clients and
servers must have in order to even start the SSL/TLS handshake with another OpenVPN instance. This
key is unique to each OpenVPN administrative domain, making every OpenVPN installation different
from every other one. So instead of having two million Windows 2000 machines that your worm can
target, you now have clusters of 10, 50, maybe 100 OpenVPN instances that are similar enough for you to
write an automated attack against. This feature won't stop determined attackers who are targeting you
specifically, but it dramatically reduces the threat of automated worms.

Most of the above security controls are turned on by default or included as strong suggestions in the
installation documentation.

And it's not all about security. I've already mentioned the ease of initial installation. Configuration is just
as straightforward. One config file controls the server with a typical format we are all used to using in
other open source products. Client configuration options can be set and controlled centrally using the --
push and --pull directives.

Failover to multiple OpenVPN servers can be achieved with multiple --remote directives, and traffic-
shaping and Quality of Service (QoS) options are also easy to implement. Authentication can be done
using a variety of methods with X.509 certificates being the suggested method, and most common. User
passwords, smart cards, and static key setups are also available for a variety of security levels ranging
from good to great.

One feature I find appropriate and useful in a VPN is a reasonable level of routing and access control.
Most SSL VPNs take this to an extreme level, but OpenVPN provides simple-to-use routing functions
that can be assigned to specific users, and groups in the not-yet-released 2.1 version, to provide a flexible
network architecture for partitioning remote access and directing client traffic.

If the command line gives you a stomach ache and you find OpenSSL hard to use, OpenVPN provides a
suite of graphic tools to help install and administer an OpenVPN environment. The My Certificate
Wizard and OpenVPN GUI are two great products that shield the weak at heart from the gorgon of the
command line interface. Other graphic tools can be found on the OpenVPN Web site.

Maybe you just love recompiling your kernel on a regular basis, and have the time to sit in the server
room and babysit your VPN machines to achieve sub 10 second incident response. If that's the case, IPsec
may be the thing for you. Or maybe you're just looking for a cool remote access tool that doesn't really
worry about security. If so, one of these alleged SSL VPNs may be right for you, although I don't think
they are right for any organization with even one bit of confidential data. But for those of us who want an
intelligent, easy-to-manage VPN that provides robust features with industry strength security, OpenVPN
is the clear choice.
Eu quis escrever um artigo nas forças de OpenVPN, mas eu apenas não posso começar a
mensagem para fora sem primeiramente falar sobre os insecurities que sérios eu v no
descanso do espaço confidencial virtual da rede do SSL (VPN). O mercado do SSL
VPN floresceu nos últimos cinco anos em resposta ao descontentamento com as
tecnologias tradicionais de VPN, a saber o protocolo point-to-Point insecure tunneling
(PPTP), e o padrão complexo e intrusive da segurança do IP (IPsec). O SSL VPNs rujiu
no espaço de VPN com a reivindicação da segurança elevada, facilidade de utilização, e
a característica robust ajusta esse eclipse as tecnologias existentes. Sempre que eu ouço
essa combinação das reivindicações, meus furrows e eu da testa vemos que é hora de
começar escavar. Parte I: Vendedor mau do SSL VPN, bad... Quando você trabalhar
com tecnologias de segurança maduras (como SSL/TLS), a segurança é frequentemente
um jogo de soma zero. Eu realizo que o SSL VPNs é um paradigm novo, mas quando
você aumenta o jogo da característica de uma arquitetura, você fá-lo quase sempre à
custa da segurança. É possível espremer para fora dos ganhos incrementais pequenos,
mas quando alguém diz colidiram a maneira da funcionalidade acima sem segurança
comprometendo, você necessitam fazer exame de um olhar mais próximo para verificar
estas afirmações. É possível ganhar em ambas as áreas, porque nós veremos quando
nós falamos sobre OpenVPN, mas para a maioria de parte aqueles tipos das
reivindicações não têm nada mas os vaporizam e o impulso do marketing atrás deles. A
vantagem architectural principal de SSL VPNs é que vertem a complexidade de IPsec
na troca para a estrutura simples, bem testada de SSL/TLS para sua camada
cryptographic. A este eu digo o "bravo!!" IPsec é um protocolo duro a usar-se
eficazmente para uma variedade das razões. Um, IPsec tem demasiado muitas
configurações possíveis, algumas de que produzem arquiteturas insecure. O adage,
"complexidade é o inimigo da segurança," é ilustrado bem por este grupo excessivo de
opções da configuração e de componentes estruturais. Dois, a natureza de IPsec
requerem-na ser acoplados firmemente com a semente do OS. Isto é mau para toda a
aplicação, mas muito mais severo quando nós estamos falando sobre componentes
críticos da segurança. Desde os dias de Multics foi well-known que o arquiteto um
sistema seguro, disponível, você necessita evitar a interferência com o espaço da
semente wherever possível. Se seu código puder interferir com o espaço da semente,
sua falha é geralmente catastrófica para o sistema inteiro. Se seu código de segurança
puder interferir com o espaço da semente, pode comprometer sua estrutura inteira da
segurança com uma única falha. Cada acordo de um componente semente-acoplado
iguala o acesso imediato da raiz. IPsec VPNs é executado no espaço da semente, SSL
VPNs não tem esta exigência. Assim, na teoria, o SSL VPNs é uma idéia grande. Na
prática nós vemos esta oportunidade squandered no nome de vender mais caixas.
Quando algum SSL VPNs experimentar os ganhos mim mencione acima, a maioria
estão fazendo exame de etapas para diante e três de uma etapa para trás não aderem a
muitas das exigências architectural importantes de VPNs. A área preliminar de
fraqueza é a noção de um "Clientless VPN." Em VPNs tradicional, um usuário
funciona o software central de VPN e cada cliente tem uma aplicação local instalou
assim que podem participar na rede prolongada. Esta aplicação do cliente é instalada e
pre-configured por um administrador e é feita em uma base da por-máquina. Os
usuários não podem conectar de nenhuma máquina que velha quiserem. São limitados a
conectar de sua máquina pre-configured. A área óbvia para a melhoria aqui está livrar o
nosso belabored o usuário do tyranny da pre-configuração, e deixou-o preferivelmente
começar uma sessão de VPN de toda a máquina que acontecer se usar. Quando isto
soar apenas dandy ao layman, as implicações da segurança desta são extremas. Nós não
podemos ter uma comunicação segura a menos que nós soubermos quem está em cada
fim da ligação de comunicação. Tendo um cliente instalado nas ajudas da máquina do
usuário satisfaça a esta exigência. Se não, é como ter um telefone da pilha que garanta
uma ligação encrypted da extremidade à extremidade, mas marca um número aleatório
cada vez que você chama alguém. Você sabe para certo que ninguém podem eavesdrop
em sua comunicação, mas você não tem nenhuma idéia a que você está falando. O som
não se fixa muito, eh? VPNs tradicional contra SSL VPNs VPNs tradicional requereu
pontos de extremidade confiados funcionar. O usuário e o cliente eram máquinas com
(se espera) algum nível elevated da confiança como nosso administrador incorporado
instalou os componentes de VPN nele pessoalmente, e cobriam ambas as máquinas com
os controles exijidos da segurança política incorporada. Adicionalmente, os credentials
do authentication foram instalados em ambos estes dispositivos assim que cada endpoint
poderia authenticate seu par e ter uma probabilidade elevada da confiança na entidade
com que se estava comunicando. O SSL VPNs permite que os usuários conectem ao
VPN central usando toda a máquina que acontecerem ao achado. Isto inclui sua
máquina home, laptop do seu miúdo, uma máquina pública em uma casa de café, ou
uma máquina pública do kiosk em Europa oriental. Duas edições severas levantam-se
aqui. Primeiramente, nós quebramos o modelo da confiança. O usuário e o cliente
nenhuma parte mais longa um relacionamento pre-configured da confiança. Instead,
têm que tentar construir algo na mosca exceto um usuário que possa recordar chaves de
algum 1024-bit RSA, nós estão indo ter que fazer isto com senhas. Isto abre-nos até
trivial para executar o homem nos ataques médios que estão well-developed e
disponíveis para nivelar os kiddies menos-hábeis do certificado. Agora toda nossa
informação decrypted por nosso atacante e é muito difícil para nós detectar a exposição
passiva. A segunda edição é que nossos usuários estão conectando das máquinas que
não são sujeitas a nossas (outra vez, eu espero) políticas incorporadas rigorous da
segurança. Mesmo se nosso usuário controla começar uma sessão do SSL com nosso
usuário real (em vez de um homem no meio) estão fazendo ainda toda sua entrada e a
saída em uma máquina desconhecida que possa jorrar seja controlada pelos povos que
se especializam em fazer lattes, não segurança do computador. Se estiverem
conectando de uma máquina pública que esteja sob o controle de um atacante, serão
expostos aos loggers do keystroke e às ferramentas de gerência remota que permitem
que nosso atacante amigável sniff senhas, coletam todos os dados de nossa sessão, e
prestam atenção mesmo à relação gráfica como nosso usuário trabalha com nossos
dados incorporados sensíveis. A segurança é uma corrente que seja somente tão forte
quanto sua ligação mais fraca. Com "o VPNs clientless" sua ligação mais fraca
transforma-se alguma máquina aleatória em alguma posição aleatória. Em uma
tentativa fraca de reduzir o risco de nossos usuários que conectam das máquinas
insecure, algum SSL VPNs inclui a opção para verificar aquele cliente que conectando
as máquinas têm a proteção do vírus e um guarda-fogo permitido. Este é o que Bruce
Schneier gosta de chamar da "o theatre segurança" -- cría o illusion da segurança, mas
não fornece realmente nenhuma proteção aumentada. Como verificam se a máquina
tem a proteção do vírus e um guarda-fogo? Poço pedem a máquina do cliente
naturalmente! Isto é tantamount perguntando a um criminoso se forem um criminoso.
Você não pode pedir uma entidade para validar-se, este é a segurança 101.
Adicionalmente, se você for peça um atacante o que a primeira coisa he/she faça quando
racha uma máquina, ele responderá geralmente com "update o sistema assim que é
seguro, e para girar sobre um guarda-fogo assim que nenhum outro atacante incomodar-
me-á." Com IPsec, nossos usuários são restringidos somente a conectar das máquinas
pre-autorizadas, mas nós temos a vantagem que estas máquinas estão confiadas e os
endpoints sabidos que nós podemos authenticate. Com o SSL moderno VPNs, os
usuários podem conectar de uma variedade das máquinas, mas NENHUMAS delas, as
máquinas nao uniformes que poderiam pre-configured, são seguras do homem nos
ataques médios. Para manter apenas os flamers na baía, algum SSL VPNs fornece a
opção de instalar certificados em máquinas do cliente para reparar este problema. Hey,
isso soa muito como instalar o software do cliente, mais certificados não é o defeito ou a
configuração sugerida uniforme. Os sistemas que são insecure fora da caixa são
prováveis ser insecure na execução -- não todos é um perito da segurança e pode
compreender os ramifications subtle de suas escolhas da configuração. A segunda área
de interesse que eu tenho a respeito de SSL VPNs é o aumento em sua complexidade.
A razão que very nós queremos se mover afastado de IPsec deve evitar sua
complexidade. O SSL VPNs está incluindo agora sistemas de controle complexos do
acesso, características intricadas da distribuição, e uma miríade do forwarding portuário,
da aplicação que proxying, e de potencialidades lima-compartilhando uniformes.
Algumas destas características, autorização e distribuição, pertencem em uma solução
do acesso remoto, mas muitos são overblown ou apenas não apropriam para um VPN.
A razão que nós movemos afastado de "tudo a todos" sistemas do tipo é porque
geralmente não fazem tudo para a direita, e aumenta dramàtica vetores do ataque de um
hacker. Em um usuário do arquivo, nós podemos tolerar algum slop, mas em nossos
dispositivos de segurança mais essenciais, este não é aceitável. Isso é porque nós
dedicamos máquinas ao punho VPN, guarda-fogo, distribuição, serving da correia
fotorreceptora, serving do email, etc.. Muitos vendedores do SSL VPN puseram-nos
para trás em um ambiente onde demasiado muitas opções estivessem disponíveis para
comprometer nossa segurança dos sistemas. Eu vi um produto que teve realmente uma
caixa de verificação etiquetada "para permitir conexões insecure." Isto é ridiculous ver
em um dispositivo de VPN. Eu estou fazendo somente a análise baseada aqui na
arquitetura; Eu não escavei em como este o SSL VPNs está executando realmente
SSL/TLS. Quando eu diria que algumas destas organizações (Cisco, ponto de
verificação, juniper) devem ser completamente peritas em sistemas crypto do edifício, o
fato que estão faltando o ponto na arquitetura faz-me pensar d pode ser cantos do corte
na mais melhor prática crypto também. O cryptography é resistente fazer para a direita
e as variações tão simples quanto a ordem que os primitivos estão aplicados pode
totalmente quebrar sua segurança, como nós vimos mais cedo este ano nas execuções
quebradas de IPsec de que HMAC-então-hMAC-then-encrypt em vez encrypt-then-
HMAC-então-HMAC. O tempo, e os coordenadores do reverso, dirão. A falha central
de a maioria de SSL VPNs é a variação na arquitetura que quebra o modelo da
confiança necessário fornecer o nível o mais elevado da segurança, que a maioria de
povos igualam com a etiqueta VPN. Segurança são uma corrente e a segurança do
sistema inteiro é somente tão forte quanto a ligação a mais fraca. Se o cliente for
insecure, o sistema inteiro é ingualmente insecure. O produto padrão do SSL VPN
reduziu dramàtica as exigências da segurança da máquina do cliente na troca para a
flexibilidade usar o VPN de todo o dispositivo.

Após ter gastado diversos dias que instalam e que configuraram OpenS/WAN, eu fui
procurar uma alternativa. Instalando cortes frágeis da semente a fim começar meu VPN
ascendente e o corredor justo não pareceu direito. "não pode ser este duro," eu mantive-
me myselfdizer-. Eu tive o sentimento que você começa quando você atravessa algum
procedimento de instalação horrible (oracle) e maravilha porque teve que ser assim feia,
quando tudo você necessita fazer para instalar algo tão complexo como Apache é
/configure; faça; faça para instalar. Eu não sou ignorant ao fato que IPsec VPNs
semente-está acoplado, e os funcionamentos de Apache como um usuário espaçam o
daemon, mas como um usuário e um administrador, eu apenas não me importo. Eu
quero um produto que instale fàcilmente, não seja frágil, e seja direto configurarar. Eu
era certo que deve haver uma maneira melhor, e felizmente há: OpenVPN. Eu tropecei
através de OpenVPN no tempo perfeito, o verão de 2004. Apenas tinham liberado um
cliente para Windows e deviam aproximadamente terminar a versão 2,0 -- que
configuração centralizada robust incluída do cliente, e ferramentas tráfego-dando forma
mais poderosas. A instalação olhou simples, e a segurança foi baseada nas bibliotecas
experimentadas e verdadeiras de SSL/TLS. Pareceu como ela valeu a pena um olhar.
Eu fiz alguma pesquisa e encontrei o artigo famoso de VPN por Peter Gutmann que
bateu o descanso do mercado aberto da fonte VPN, mas escolhi-o para fora de
OpenVPN como um vencedor potencial. Eu escavei mais profundo. As instruções
instalar fizeram meu coração pular, /configure; faça; faça para instalar. O gancho foi
ajustado. Mais profundo eu comecei mais feliz eu tornei-me. Finalmente! Uma
recolocação aberta da fonte a IPsec VPNs que fornece o mesmo jogo da característica,
mais algumas adições sãs, mas não carrega a complexidade semente-acoplada que faz a
VPNs tradicional tal headache. Um olhar em OpenVPN OpenVPN usa as bibliotecas e
estruturas de SSL/TLS controlar sua camada cryptographic. O método chave
authenticated duplo de SSL/TLS agreement/exchange é quase idêntico à troca da chave
do Internet de IPsec (IKE), e OpenVPN executa um sistema do túnel como o payload
encapsulating da segurança de IPsec (ESP) que tem a segurança equivalente ou melhor
a nosso padrão venerable. Os algoritmos crypto disponíveis a OpenVPN incluem todos
os hitters que pesados você sabe e amam-nos, com o ajuste do defeito do authentication
de RSA, verificações chaves do acordo de Diffie-Hellman, da integridade Hmac-sha1,
IV explícito, e encryption symmetric usando Blowfish na modalidade de CBC -- um
estábulo excelente em minha opinião. Que todo este meio ao layman? Significa que
OpenVPN pode criar e manter túneis com ao menos o nível da segurança encontrado
nas mais melhores execuções de IPsec. Isto é importante. Há uns povos da razão
tolerou IPsec para assim por muito tempo, porque fornece o padrão de ouro para o
excesso de uma comunicação do dispositivo-à-dispositivo untrusted redes. OpenVPN
combina este padrão e faz-lhe exame de uma etapa mais mais. Antes que nós nos
movamos sobre, eu quero fazer exame de um segundo para ser aproximadamente um
ponto realmente desobstruído. Há um misconception terrível de que todo o produto
etiquete "SSL VPN" não seja um VPN real, e forneça somente alguma sorte bastardized
o acesso usando um web browser padrão. IPsec fornece o que é consultado geralmente
como de "a extensão rede." Isto significa exatamente o que soa como -- você estende
sua rede confidencial para incluir as máquinas que são fora do círculo da sua rede local
do controle e provavelmente necessitarão se cruzar untrusted redes para alcançar seu
LAN. realizam isto e mantêm um modelo são da confiança, IPsec VPNs requer
administradores instalar um componente do cliente nas máquinas que necessitam
participar nesta rede prolongada. OpenVPN usa a mesma arquitetura. Nenhumas
diferenças, nenhuns truques. OpenVPN requer a instalação do cliente apenas como
IPsec, e esta é uma coisa boa. OpenVPN faz o cliente emitir mais menos doloroso
fornecendo fácil-à-instala clientes para Windows, Solaris, Linux, DEB, e MacOSX.
(vamos ver que seu Cisco ou ponto de verificação VPN faça isso!) Mas o ponto real
aqui é que a arquitetura da extensão de rede de OpenVPN é exatamente a mesma que
dispositivos de IPsec. Muitos do SSL so-called VPNs que emerge ultimamente tout sua
arquitetura "clientless" e reivindicam-no podem começar o acesso de VPN usando um
web browser simples. Isto tem as implicações sérias da segurança que nós temos
coberto já, mas tem também limitações da característica. Muitos destes produtos são
justos fazendo o forwarding portuário, a correia fotorreceptora que proxying, ou o
"Webalizing" dos protocolos em uma base do um-em-um-tempo, extensão de rede nao
verdadeira. Eu penso que nós todos sabemos que não é uma solução muito robust para
segurar protocolos um de cada vez. Que acontece a semana seguinte em que um
protocolo fresco novo vem para fora daquele que você quer funcionar sobre seu VPN?
IPsec, e OpenVPN, extensão de rede do punho em uma base do nível de ligação e
podem permitir que todos os protocolos, todo o tráfego, atravessem o túnel de VPN. A
mágica real em OpenVPN é realizada por seu paradigm alterado do projeto. Em vez de
um módulo da semente, OpenVPN é executado como um daemon do usuário-espaço. O
acesso da relação da rede é controlado usando os excitadores virtuais de TAP/TUN que
são fare padrão em a maioria de sistemas se operando modernos. Esta mudança simples
permite um anfitrião de características e das melhorias flexíveis da segurança que
deixam IPsec na poeira. As duas opções as mais importantes perto são distante a
abilidade de degradar os privilégios do usuário ao usuário ninguém, e a opção ao chroot
o daemon do usuário, ambo reunião nossa filosofia da segurança do princípio de menos
privilégio. Com cada acordo de um processo de IPsec, você começa um escudo livre da
raiz. Não um negócio mau, eh? Se você acontecer encontrar uma maneira rachar um
exemplo de OpenVPN, tudo que você começa é um usuário unprivileged prendido em
um diretório razoavelmente escasso. Esta é uma melhoria grande em minha mente.
Muitos povos inteligentes para fora lá podem eventualmente poder wiggle livre deste
ambiente restrito, mas fará exame de alguma hora, tempo onde eu posso se usar detectar
e reagir a sua ruptura. O la imediato IPsec do à do escudo da raiz não me dá nenhuma
quarto ou proteção respirando mesmo dos atacantes mais menos talented. A proteção
dos sem-fins era não somente mim imprimiu com a segurança OpenVPN fornece para o
presente, mas eu descobri também uma outra característica muito interessante, proteção
futura do sem-fim. Que faz um vulnerability "wormable"? Bem, você quer um
vulnerability remotamente exploitable que possa ser automatizado e executado
eficientemente e forneça um nível útil do acesso em seu sistema de alvo assim que você
pode alcançar ferramentas do OS para propagar mais mais a infecção. Você quer
também uma base instalada homogenous grande das máquinas que são tudo vulneráveis
à façanha assim que você começa a maioria de estrondo para seu buck. Quem quer
escrever um sem-fim para infect 10 máquinas? Ninguém, é nao econômico justo. Os
desenhadores de OpenVPN realizaram este e puseram uma opção grande em OpenVPN
para difundir o ataque padrão do sem-fim, tls-auth. O que esta opção é permite que
você designe uma chave que todos seus clientes e os usuários de VPN devam ter a fim
começar mesmo o handshake de SSL/TLS com um outro exemplo de OpenVPN. Esta
chave é original a cada Administrative Domain de OpenVPN, fazendo cada instalação
de OpenVPN diferente de cada outra. Assim em vez de ter dois milhão Windows 2000
máquinas que seu sem-fim pode alvejar, você tem agora conjuntos de 10, 50, talvez 100
exemplos de OpenVPN a que seja similar bastante para que você escreva um ataque
automatizado de encontro. Esta característica não parará os atacantes determinados que
o estão alvejando especificamente, mas reduz dramàtica a ameaça de sem-fins
automatizados. A maioria dos controles acima da segurança são girados sobre pelo
defeito ou incluídos como sugestões fortes na documentação da instalação. E não é toda
sobre a segurança. Eu tenho mencionado já a facilidade da instalação inicial. A
configuração é justa como direta. Uma lima dos config controla o usuário com um
formato que típico nós todos somos usados a se usar em outros produtos abertos da
fonte. As opções da configuração do cliente podem ser ajustadas e centralmente usar-se
controlado -- empurre e -- puxe diretrizes orientadoras. Failover aos usuários múltiplos
de OpenVPN pode ser conseguido com múltiplo -- as diretrizes orientadoras remotas, e
tráfego-dar forma e qualidade de opções do serviço (QoS) são também fáceis de
executar. O authentication pode ser feito usando uma variedade dos métodos com os
certificados X.509 que são o método sugerido, e os mais comuns. As senhas do usuário,
os cartões espertos, e as instalações chaves de estática estão também disponíveis para
uma variedade dos níveis da segurança que variam do bom a grande. Uma
característica que eu encontro apropriado e útil em um VPN é um nível razoável do
controle da distribuição e de acesso. A maioria de tomada do SSL VPNs isto a um nível
extremo, mas OpenVPN fornece as funções simple-to-use da distribuição que podem ser
atribuídas aos usuários específicos, e os grupos na versão 2,1 não-ainda-liberada, para
fornecer uma arquitetura de rede flexível para o acesso remoto dividindo e a direção do
tráfego do cliente. Se a linha de comando lhe der um ache de estômago e você
encontrar OpenSSL duro se usar, OpenVPN fornece um suite de ferramentas gráficas à
ajuda instala e administra um ambiente de OpenVPN. Meu GUI do wizard e do
OpenVPN do certificado é dois produtos grandes que protegem o fraco no coração do
gorgon da relação de linha do comando. Outras ferramentas gráficas podem ser
encontradas no Web site de OpenVPN. Talvez você amor justo que recompiling sua
semente em uma base regular, e tem o momento de sentar-se no quarto do usuário e de
babysit suas máquinas de VPN para conseguir 10 secundários a segundo resposta do
incident. Se aquele for o caso, IPsec pode ser a coisa para você. Ou talvez você é justo
procurando uma ferramenta fresca do acesso remoto que não se preocupe realmente
sobre a segurança. Se assim, um destes alegou SSL VPNs pode ser direito para você,
embora eu não penso são direitos para toda a organização com um bocado uniforme de
dados confidential. Mas para aqueles de nós que querem um inteligente, fácil-à-
controle VPN que fornece características robust com a segurança da força da indústria,
OpenVPN é a escolha desobstruída.