In Part 1, I've
mentioned the modern secure VPN Technology
words. In this part, we will start a general
discussion about VPN
technologies and VPN solutions. Since
there is a lot to talk about, it will be
impossible to speak about every feature, so some
aspects may be omitted. Not many pictures will
be used in this part (a general
discussion).
On the VPN
Consortium site there is a white
paper discussing three major VPN
technologies: trusted VPNs, secure VPNs, and
hybrid VPNs. Please follow the bellow link if
you want to find out more about them.
VPN Technologies:
Definitions and
Requirements
Since it's out of the scope
of this article we will not explain all three
VPN technologies. Instead we will focus on
secure VPNs.
Today, high-bandwidth
Internet connections are quite
cheap. Therefore it has become very
popular for road-warriors and branch
offices to be securely connected to their HQ
through the use of secure VPNs. Even more, in
order to increase work productivity, remote
working might be seen as a solution, so secure
VPN comes once again into action. And not to
forget, the parteners/contractors/suppliers
which may require site-to-site connectivity or
remote access.
Thus, you will end-up
with some "basic" needs to address: an insecure
path (the Internet) and different security
challenges generated by the remote sites or
remote clients. See Figure1
.
Figure1: Possible
Scenarios
The insecure path:
attackers are assumed to have the ability to
capture, read, modify, delete or replay messages
sent between the communicating hosts.
If we want to securely move
sensitive traffic over Internet, messages must
be encrypted and integrity protected, and the
communicating devices/users must authenticate
themselves using strong authentication
methods.
Typically, through the use
of encryption we want to achieve confidentiality
for our data, so an atacker cannot read the
information sent. Another form
of confidentiality that might be desired is
traffic flow confidentiality, an attacker might
perform traffic analysis(message length, reveal
communicating parties' identities, frequency of
transmission).
We understand by integrity:
connectionless integrity(proof of the fact that
data has not been altered in transit) and data
origin authentication(proof that the data was
sent by the correct peer).
Since every packet sent can
be subject to manipulation from an attacker,
integrity needs to be provided per
packet.
Packet replay can
be used by attackers to gain control of a
communication channel. The attacker
will capture and record traffic between
hosts, analyze the packets and maybe modify
some of them. Then the attacker will
send these packets back into the data stream in
order to hijack the session.
Packet replay is often used
by attackers to become authenticated by an
unsuspecting host.
An attacker will try
weakening the protection afforded for the
communication channel. The protocols must
not be susceptible to version rollback.
The attacker, if possible, will
make the talking parties to use weaker
crytographic algorithms.
A modern secure VPN
technology must be able to defeat these attacks.
Throughout these series we will see how
L2TP/IPsec stands up against these
threats.
A modern secure VPN
technology should be an Industry standard-based
technology, an Internet Standard, an open
standard that has been under intense
scrutinity from the Internet
community.
A modern enterprise-class
VPN solution should be able to deal with
the scenarios presented in Figure1.
In order to do that, a VPN
solution might incorporate multiple secure
VPN technologies like "pure" IPsec,
L2TP/IPsec or SSL VPN.
Each of the remote sites or
remote clients can
represent a security challenge,
generating various threats for the HQ network,
thus different authentication methods, levels of
protection or security policies for
traffic entering and exiting the HQ network
may be needed.
Before you purchase a VPN
solution you must carefully
analyze your needs, present needs and
future needs. You are about to take a very
important decision. It can turn into an
irreversible one. Let's start a general
discussion about various features of a VPN
solution that you might need.
A modern
enterprise-class VPN solution should
provide features like interoperability,
flexibility, scalability, availability,
access/connectivity from anywhere,
performance, support for various crytographic
algorithms, a certain level of certification,
controlled access/protection out-of-the-box,
advanced logging and reporting. Also
it should be easy to implement, to use
and to maintain.
- Interoperability: a
critical feature. For example, when you need to
connect to a partner's network, you will
very likely need to interoperate with a VPN
gateway from another vendor for site-to-site
connectivity. If you have multiple branch
offices, it may be possible to use for them or
for some of them a VPN solution from
another vendor. Also, you may need to provide
remote access for some contractors, customers or
so which are not using the same OS as your VPN
clients. You should not lock yourself using
a single proprietary implementation that does
not include VPN clients for various Operating
Systems. Your VPN solution should include
an Industry standard secure VPN technology for
remote access too.
- Flexibility: this term is
somehow ambiguous. The level of flexibility will
typicalliy be achieved by a VPN solution by
incorporating the features discussed
here. Flexible to support various
scenarios(site-to-site and remote access),
topologies(mesh or hub-to-spoke), access from
various places(from behind restrictive
firewalls), scalability, easy to use and so
on.
- Scalability: your VPN
solution may need to scale both vertically and
horizontally. To address a high number of VPN
clients and site-to-site connections,
dependending on the solution you have opted, you
can upgrade hardware components(replace CPU, add
more RAM, upgrade NICs), distribute VPN sessions
across multiple appliances for load balancing or
both. You may build yourself an appliance(if you
are using an ISA Server 2006: buy the hardware,
install the Windows 2003 OS and so on) or opt
for a "hardware appliance" (this does
not necessary means an appliance from
Cisco, Juniper and so
on, you can buy an ISA 2006 appliance from
Celestix for
example).
- Availability: a single
point of failure can be inacceptable if VPN
connections are critical for your business. If
so, you need to distribute VPN sessions across
multiple appliances for failover.
-
Access/connectivity from anywhere: your
road-warriors must be able to connect
virtually from anywhere: behind broken NAT
devices, behind restrictive firewalls. A single
secure VPN technology for remote access like
L2TP/IPsec will not handle all these.
You need SSL-based remote access too. The term
SSL VPN may be ambiguous, some vendors do not
offer full network access.
- Performance: very likely
you will opt for an integrated security and
VPN solution, which will serve as a firewall,
IDP/IPS, network antivirus and VPN server.
You need to make sure you will not suffer from
performance degradation. The firewall might
perform stateful packet inspection, application
inspection, the VPN server will serve both VPN
clients and site-to-site connections.
- Support for various
crytographic algorithms: you need to think about
present and future needs regarding the use of
crytographic algorithms. Performance,
security strength and interoperability are key
words. Diffie-Hellman 1024 MODP Group or
1024-bit RSA keys offer only 80 bits of
security. 80 bits of security are not considered
adequate beyond year 2010. Using
Diffie-Hellman 2048 MODP Group or 2048-bit
RSA keys will enable you to benefit from
112-bits of security, the security strenght of
3DES. For AES, larger keys are
needed, which are more
resource-intensive to process. Instead, you may
consider using Diffie-Hellman ECP Groups
(computational speed and efficiency)
and ECDSA signatures(smaller signatures,
less bandwidth,computational speed and
efficiency). The attacks over SHA-1 might
make you migrate to the SHA-2 family of hash
functions. Additionally you may want to provide
overall security consistent with the AES, thus
to achieve say 128 bits of security. Regarding
the use of AES with IPsec, you need to evaluate
the modes of AES (say AES-CBC, AES-CTR,
AES-GCM).
- A certain level of
certification: you may be interested to search
for the FIPS 140-2
Level (cryptographic module
certification), Common
Criteria certificate(The Evaluation
Assurance Level achieved) or to see
if the product has received various logos
from VPNC. Some vendors are members
of the VPNC.
Follow this
link to start searching for
FIPS 140-2 certificates.
Follow this link to see the FIPS 140-1 and
FIPS 140-2 Vendor List
Follow this link
to start searching
for Common Criteria certificates.
Follow this link to see the VPNC
members.
Follow this
link to see various VPNC logos
and products that have passed various tests(like
Basic
Interoperability or AES
Interoperability for IPsec, or SSL
Portal or SSL File
Access for SSL VPN).
Follow this link to see VPNC Members
Supported Features for IPsec (VPN clients
for various Operating Systems, L2TP/IPsec
support, IKE v1 or IKE v2 support,
authentication with X.509 certificates, QoS, AES
encryption, Diffie-Hellman MODP Group 14 and so
on).
Follow this
link to see VPNC Members
Supported Features for SSL (remote access, SSL
Portal, SSL Exchange, Active Directory and/or
Radius client authentication, Full network
access with SSL plug-in and so on).
Follow this link to see the VPNC
Documentation Profiles for IPsec
Interoperability.
Regarding ISA Server,
follow this link to learn more about the
Evaluation Assurance Level. Microsoft is a
member of VPNC. ISA Server 2006
was tested for VPNC Basic Interoperability
Test and has "passed all tests in both
directions with all other participants".
Follow this link to
see Microsoft's validated FIPS 140-1
and FIPS 140-2 cryptographic modules.
- Controlled
Access/Protection out-of-the-box: once you
enable the VPN server for remote acces and start
creating site-to-site connections, all these
must not translate into drilling security
holes into your network. For example, on ISA
Server 2006, once you've enabled VPN remote
access, VPN clients can connect but cannot
access anything, a very good security practice
as opposed to the allow all by default
practice(low security). You have to start
creating access rules, allowing only needed
traffic(per protocol). And you can do that
granular, per user or per group.
Controlled-access is critical, but it's only a
part of the equation. VPN clients or remote
sites can represent an access path for viruses,
worms, spyware, keyloggers or Trojan
horses into your network. Your application
servers are also exposed. A simple stateful
packet filtering firewall cannot provide an
adequate level of protection for your
applications. A
traditional signatures-based
IDS/IPS(integrated with the VPN server) will
offer protection out-of-the-box for known
attacks using a database of signatures(some
vendors offer more complete and
updated database signatures). But this does
not protect you against 0-days attacks. Your VPN
server may be integrated with a
truly application-layer firewall. For
example, you may have a web application
used between sites or by your VPN clients. On a
simple stateful packet filtering firewall this
will translate into "open TCP port 80". Indeed,
the port is "open" because the firewall
will never know if port 80 is used for HTTP
traffic. Instead, an application-layer
firewall isn't really concerned about ports.
With an application-layer firewall you are
allowing access per protocols rather
than per ports. An application firewall
will recongnize if port 80 is really used by
HTTP traffic. You may configure your application
firewall to block known attacks using
signatures(signatures inspection). All
requests/responses except the ones containing
attacks are allowed. This is known as a negative
security model. What about unknown attacks,
0-day attacks ? A positive security model might
help here. A positive security model denies
everything by default while allows
only requests/responses known to be
good/valid. For example it can do that using
strict-policies. For the best security you
should use both models. An application firewall
may deliver out-of-the-box protection at a touch
of the button if it comes with default
policies(negative and/or positive models) for
popular applications. So you will not have to
analyze those applications in order to
figure out what means good traffic and
what means bad traffic.
- Advanced logging and
reporting: you will need to carefully monitor
your VPN users activity. Live monitoring
and detailed reports are
desired.
- Easy to implement, to use
and to maintain: either that you plan a
new VPN solution or upgrade an
old one, the VPN solution should be easy to
implement. Since you are likely to face various
scenarios, it should have a simple
interface, tasks and configuration should
be automated as much as possible saving time and
money. Needing too much steps to complete a
simple task will increase the likeliness of
configuration errors which may translate into
possible security holes. The level of expertise
needed will increase the costs. Also the VPN
users should have a pleasent VPN
experience. The VPN clients/connections(you
might use clientless VPN remote access
sometimes) should be easy to use in order
not to cause frustration, not to affect work
productivity and to lower the number of support
calls. Maintaining the VPN
solution should be done without
administrative overhead, again saving costs. The
VPN solution should not require highly
trained network administrators just to make
sure it is up and running.
There are certain aspects
that will contribute to the final decision. The
next two important "features" will influence the
decision of buying a VPN solution: the
"emotional" factor and the cost.
-The "emotional"
factor: there is no secret,
unless people want to keep it secret, that
everybody has certain feelings about vendors and
their products. Mixed feelings, good and bad
feelings. Feelings that can be based on people's
experiences or just on people's feelings. When
feelings are based on people's experiences, then
they can represent valid and solid
arguments regarding the selection of a certain
product from a certain vendor. But when feelings
are just based on feelings, rational decisions
are in danger.
A company
can build in time a strong relationship with a
vendor. An upgrade decision, such
as upgrading an ISA Server 2004 to an
ISA Server 2006, may appear natural. The company
will like to continue with a product that proved
to be an excellent solution for its needs.
The company also may consider that it can reduce
costs, because the transition should be
easier.
A company may
use various products from a vendor: switches,
routers, wireless access points, firewalls,
IDS/IPS and so on. Again it may seem natural to
keep things "contigous" and also use a VPN
solution from the same vendor based on
the confidence gained through the use of various
products.
A company has
used for a long time with success open source
solutions. When upgrading or implementing a new
VPN solution would seem natural to continue
this benefic tradition. Popular IPsec based
implementations (say Openswan) are
available, or if connectivity represents an
issue, OpenVPN (SSL
VPN) may be the answer. The solution
can be built from scratch. Already
built ones are available with commercial
support, with various features, say
the pfSense
project or maybe Vyatta OFR
(remote access available only on the
Glendale alpha release as writing this), just to
name a few. You can find out more about
using a Linux L2TP/IPsec VPN server from Jacco de Leeuw's Web
Site.
A
company may have migrated away from products
used in the past(say new switches or
routers from another vendor). This migration was
a real success and confidence is high. The
company also plans to replace its current
firewall, so using an integrated firewall/VPN
from this vendor may once again appear a
natural decison.
A
company may have had a bad experience in the
past with a certain product or various products
from a vendor. So it would seem a rational
decision to stay away from that vendor's
products.
Without
contesting these decisions, a deeper analyze is
required. You should always be in touch with the
latest innovations and listen what the "rest"
has to say and to offer. Another vendor may have
the upper hand in terms of technology.
Using a new VPN solution from another vendor can
be scarry, but it can turn into a success
story. It may outperform the current
vendor's solution so you will end-up with a
superior solution which will lower the TCO and
increase productivity. The past is past and
things may have changed. The painful experience
from the past could have been just an accident
or the guilty vendor may have learnt from its
mistakes.
-The cost: can be a tricky
factor. The initial cost of acquisition may be
low, but the TCO can prove to be
significant. And vice-versa. There are many
factors that will influence the initial cost of
acquisition or the TCO. We have already
discussed many of them above. It
will always be about what you are
going to get versus what are you going
to give up. Although many vendors claim
that you can have all the above features and
much more, assuming that this is true, it will
come at a price that your budget cannot afford.
So you will have to decide which features are
most important for your company for present
and for future. If you currently decide to opt
for a solution that does not offer, say SSL VPN,
because you don't really need that now, thus
saving some money(you have just a few VPN
clients using L2TP/IPsec which works great) and
in the future due to connectivity issues, you
may need SSL VPN remote access, your
current decision can prove a costly one (if you
are locked using a VPN solution that will
require a new infrastructure in order to
integrate SSL VPN). Also, when choosing an
integrated security and VPN solution, you will
want to benefit from all the levels of
protection at maximum. The vendor may claim that
is has the best-of-breed IDP/IPS,
application-layer firewall, antivirus and so on.
In reality, it may have the best-of-breed
IDS/IPS, a medium antivirus and a poor
application-layer firewall. You will have to
decide which features are the most important for
you and choose the most balanced solution for
your needs.
As shown in Figure1 ,
there are some security challenges that
must be handled accordingly.
Regarding the remote
sites, if all the sites in a VPN are owned by
the same company, the VPN may be thought of
as an intranet, if the various sites are
owned by different companies, the VPN may be
thought of as an extranet. So, it should be
noted that a site can be in an intranet and in
an extranet in the same time, a local
site can be connected to a remote site
representing a branch office of the
same company and to a remote site representing a
partener's office. Therefore, very likely,
different policies will be applied for the
communications between the sites(different level
of trust). Only certain traffic and
resources will be made available for
the communications between the local site and
the partner's site. Deep traffic inspection
may be applied for this scenario. Also, even
when the sites belong to the intranet, say two
branch offices and the local HQ site, this does
not automatically mean that the same policies
will be applied for the communication between HQ
and branch 1 office, and between HQ and
branch 2 office, branch 1 may need access
to different resources located on
the HQ than branch 2. The branch offices
may have their own local security
policies(including physical security), thus they
can generate various threats for the
HQ site. So it is critical to achieve
granular controlled access to resources. Various
level of traffic inspection are needed, simple
stateful packet inspection only offering little
protection for applications.
Regarding the VPN
clients, there are multiple types of VPN
clients: employees working on the road,
employees working at home, some
partners/consultants and so on. In order not to
create security holes, again strict controlled
access and deep traffic inspection are
needed. You can't allow a VPN user connecting
from home to have full access to the corporate
network and pass traffic without being inspected
by the firewall. However, since all these users
are away for some periods of time, the machines
they use(laptops), cannot be verified by the
network admins to ensure they follow some
policies like having the systems patched, the
personal antivirus updated and active along
with a firewall running and so on. So it will
appear the need for endpoint compliance. VPN
quarantine can solve this problem, by placing
the VPN clients on a special network
with limited access while the health state
of their machine is checked. If they pass the
checks, they are released from this special
network and allowed to access the permitted
resources. If they fail these tests, they must
update their machines(install the latest
patches, latest antivirus signatures). Also in
this way split tunneling can be easily avoided.
Some VPN quarantine solutions really work in
practice and are easy to use, other are complete
nightmares(Microsoft's VPN-Q). Fortunetely for
ISA there are third-party VPN quarantine
solutions like Winfrasoft VPN-Q
2006 or Quarantine Security
Suite(QSS) .
Also the VPN remote
access requires another level of
authentication: user authentication. In the case
of site-to-site connections, machine-level
authentication may be enough, the VPN gateways
authenticate themselves through credentials
stored securely within the devices without any
user input, for example using digital
signatures(the private key corresponding
to the public key from the certificate is
stored and protected within the machine). In
addition the VPN server is placed into a secure
physical location and unauthorized access is
prevented(isolation).
However, since VPN users
are mobile users, physical security becomes a
relative term.
From the
VPN client's point of view, the VPN server
requires machine-level authentication, the VPN
client needs to be sure that the
other end of the connection is indeed the VPN
server. From the VPN server's point of view,
machine-level authentication might not be
enough. From the VPN server's
perspective machine-level authentication
provides information only about the endpoint
(machine) from which the connection originates.
But the VPN server has no information about the
user using that remote machine, thus the VPN
server cannot be sure if indeed the authorized
user is trying to establish the connection. The
remote machine can be a laptop located in
various places where the level of physical and
network security is relatively low, say at
home. In order to make sure that the correct
user is trying to establish the VPN
connection some user input is required. Also,
alone, the user-level authentication(such
as information provided directly to the VPN
server, say an user name and a
password) might not be enough from the VPN
server's perspective. The VPN server will have
no information about the particular machine the
user is using. The company may allow access only
from approved machines.
Therefore, from the VPN
server's perspective, in order to make sure that
the authorized user is trying to
establish the VPN connection from the
authorized machine, both levels of
authentication, user and machine, are
needed.
L2TP/IPsec provides
clean and separated user and machine
authentication. Machine-level authentication is
straightforward through IKE(pre-shared keys,
digital signatures). The user-level
authentication is represented by PPP
authentication(CHAP, MS-CHAP, various EAP
methods).
When selecting a VPN
solution and/or VPN technology, it is very
important to see if they have support for
various authentication methods, thus to achieve
flexibility. The authentication methods used
provide different levels of assurance for
both machine and user authentication, levels of
assurance that can be considered acceptable in
certain situations while in other situations
regarded as inappropriate.
Talking about
machine-level authentication for L2TP/IPsec,
there are two common authentication methods:
pre-shared keys and certificate authentication.
It must be noted that
pre-shared keys are not really an authentication
method. As its name suggests, it's achieved
using a secret shared between the
communicating hosts. It cannot be proven that
the remote machine is indeed a specific machine,
since the pre-shared key does not
uniquely identify it. If only two hosts know
this shared secret (the two gateways creating
the site-to-site connection), it may function as
an effective shared secret keeping in mind the
above mentioned weakness. Even worst, in case of
remote-access scenarios, the pre-shared key will
transform into group pre-shared key (IKE Main
Mode). In this case, neither the client nor the
server identifies itself during IKE phase
I. It is only known that both parties are a
member of the group with knowledge of the
pre-shared key. This opens the posibility
of a man-in-the-middle attack from inside(any
user with access to the group pre-shared key).
This scenarios is advertise in RFC3193 Securing L2TP using
IPsec, an "Internet Official Protocol
Standards" . Also an attacker that,
somehow, manages to find out the pre-shared key,
can perform the MITM attack, pretending to
be the VPN server. In that case, it cannot be
said if it was an external attacker or someone
from the VPN clients group.
In addition, if weak
pre-shared keys are used(too short, guessable),
an attacker without knowledge of the pre-shared
key, can use an active MITM attack and
then, while being offline, attempt to guess
or brute-force the pre-shared key.
Also, the distribution of
the pre-shared key, the way it's stored on the
machines can affect the level of assurance of
this authentication method, assuming that for
some people this authentication method may have
any level of assurance in practice(real world
scenarios). One may argue that a trust
relationship was built, if you do not trust the
people, you should not give them VPN remote
access, thus do not give them the pre-shared
key. Regarding this so called trust
relationship, as said before, you cannot really
trust someone who has not really
proven his/her identity, therefore you
cannot create a real secure channel for
communications. RFC2408 Internet Security
Association and Key Management Protocol
(ISAKMP) states that:
"1.5.3 ISAKMP
Requirements
Strong
authentication MUST be provided on ISAKMP
exchanges. Without being able to
authenticate the entity at the other end, the
Security Association (SA) and session key
established are suspect. Without
authentication you are unable to trust an
entity's identification, which makes access
control questionable. While encryption
(e.g. ESP) and integrity (e.g. AH) will
protect subsequent communications from passive
eavesdroppers, without authentication it is
possible that the SA and key may have been
established with an adversary who performed an
active man-in-the-middle attack and is now
stealing all your personal data. "
You can think about
pre-shared keys in this way(it may be not the
best analogy from some points of view): you have
an office and this office has a door which is
locked. In order to enter this office, people
need to unlock the door. You distribute them
keys to open the lock. Since you need more keys
for your people, you duplicate the original key
and give these keys to the people. Since all the
keys are the same, you cannot say who opened the
door on a monday morning at 09:12, thus no
endpoint (machine) origination. You have little
control on how well protected is this key by
your people, loss or theft can occur. Also the
duplication and distribution process can
represent a weak point where an attack can
occur. Depending on the lock, the key can be
easy or complicated to forge (pre-shared key
length and complexity). In case a key is lost or
stolen, you cannot simply revoke that key, you
need to change the lock(modify the pre-shared
key on the server) and acknowledge all the
people using the old keys that they are no
longer valid. The time needed for making the new
key available(duplicate the new key, distribute
it to the people), would block office
access, people cannot enter the office (connect
to the VPN server). A skillful attacker, might
manage to duplicate a key without the knowledge
of the owner. And with this key, he/she
would enter the office(successfully establish a
VPN connection). Since all the keys are the same
and do not identify in any way the owner(the
machine in case of IKE), it will be very
difficult to locate from which person and
how the key was copied (from which machine was
the pre-shared key obtained and how did that
happen).
Regarding the machine
authentication method with certificates, this is
indeed an authentication method and should stop
the MITM attack. The digital
certificate will bind together a public key
with an identity(the name of the machine in this
case). The certificate will be digitally signed
by a Certificate Authority. The
certificates will be used to exchange
the public keys. Because the certificate is
signed by a Certificate Authority which both
machines trust, the certificate can be used to
verify that the public key belongs to the
remote machine.
The use of digital
certificates would require a PKI. For some
reasons, some folks, like to give to the PKI a
bombastic and complex meaning. In reality
is not that complicated to build your
own PKI(keeping in mind that depending on
which CA is used and how is the PKI
implemented, it will provide different
levels of assurance). The CA from Windows Server
2003 is easy to use, either as a Standalone or
Enterprise CA. It comes with templates for
various certificates(web server, computer, user
and so on). Certificates are easy to issue, to
revoke. Also certificates are easy to
store/import/export on Windows-based machines
providing flexibility, you can choose if a
private key will be or not exportable. Many of
the processes are automated, requiring few
skills from administrators. The certificates can
be easily protected when the private key is
exported. If you search the Internet, you will
find step-by-step tutorials with pictures about
how to install, configure the CA or to
issue/obtain various certificates from the
CA.
You do not need to
spend any money on Microsoft's CA if you want to
have your own CA. You can easily use
OpenSSL. Again if you search the Internet you
will find plenty of detailed tutorials about how
to create your own CA with OpenSSL, issue
various certificates types for various
scenarios, revoke certificates and so on.
Some products(VPN
solutions) come with an integrated CA.
If a certificate
uniquely identifies a single machine(as it
should), endpoint origination (machine) is
possible. Now, assuming that appropiate logging
is in place, you can verify from which machine
on a monday morning 09:12, a successful IKE
phase I was completed. If a certificate is
lost or stolen, you can simply revoke that
certificate and publish the new CRL in order to
make people/machines aware of the fact that
this specific certificate is no longer
valid, without having to rebuild
everything. This is a scalable and easy to
manage solution.
It must be noted that
the value of a certificate may vary. If an
attacker can easily obtain one from the CA, the
certificate will have a low value. So the
certificate enrollment process must be strictly
controlled. In certain common situations,
the terms machine certificates and user
certificates can have ambiguous meanings. In
reality the same certificate will be used for
both machine and user authentication(not very
smart). It's labeled as machine certificate
because it's stored within the machine (Computer
Store - Windows OS) while it is also stored
in the User Store(Windows OS). In fact, in
practice, a "machine certificate", can have its
EKU set to Client Authentication
(1.3.6.1.5.5.7.3.2). Such a certificate may
be defined by some people as a "user"
certificate. Even more, in practice, a VPN
server may use such a
certificate(which EKU's does not
contain Server Authentication
(1.3.6.1.5.5.7.3.1)) for IKE authentication.
Therefore, both the machine and user certificate
enrollment processes must be strictly
controlled.
In addition,
the way the private key is stored and protected
on the machine is critical. If it's properly
done, an attacker may have to steal the
entire machine. Maybe a laptop would be easy to
steal in certain situations. However it would be
also easy to notice that the laptop is missing
and then to revoke the certificate. This is true
as long as the laptop is "physically"
stolen. But what if the machine is "virtually"
stolen ?
Assuming the
attacker has physical access(ambiguous meaning)
to the machine for a certain amount of time, it
can transform the physical machine
into a virtual machine(cold clone, see VMware
Converter for example). Some may
argue that additional measures can be taken(WinMagic, TrueCrypt).
New attacks are found, see Cold Boot Attacks on
Encryption Keys.
The MITM attack
posibility when certificates
authentication is used exists in practice,
see this post , by Thor
Lancelot Simon. Although that post is old,
Windows XP SP2 VPN L2TP/IPsec clients are still
susceptible to the MITM attack. I have
installed SP3 (RC2) and haven't noticed a fixed
VPN client like the new one from Windows Vista
or Windows 2008
Server . Maybe, after a long time,
Microsoft will fix this.
The idea is that
every VPN client has a certificate
from the CA which also issued the VPN
server certificate, so when connecting to the
VPN server and receiving the VPN server's
certificate, the Windows XP VPN L2TP/IPsec
client will only check if the certificate was
issued by the trusted CA. It does not check and
cannot be configured to check if indeed the
certificate identifies the server, if the name
on the certificate belongs to the VPN server.
Only trusting the CA is not enough. The identity
of the server must be verified. That's what
digital certificates do, they bind
together a public key with an identity, the name
of the server in this case. Even worst, the VPN
client cannot be configured from which CA to
accept the VPN server certificate.
Some may say that since
certificates are issued to trusted machines by a
private CA and the user authentication
method used is also mutual(the server is
authenticated one more time) this would provide
for them a good level of assurance. However, in
case of remote access, the VPN client does not
know if the remote peer is indeed the VPN
server, or someone (another VPN client)
maquerading the VPN server.
Thus, any VPN user can
impersonate the VPN server.
Therefore, the
desired secure and authenticated
channel established in IKE phase I will become
suspect. This channel is used to negotiate the
IPsec SAs, and data will
be protected(confidentiality, integrity and
anti-replay attack) by IPsec ESP.
In case of ISA Server 2006
(its VPN functionality is handled through
Windows 2003 RRAS), L2TP/IPsec site-to-site VPN
connections, you cannot specify either to check
the name of the remote VPN gateway from the
certificate. Only in case of IPsec tunnel mode
site-to-site connections, you can select which
CA issued the certificate.
Let's examplify a little
bit this MITM aspect with the L2TP/IPsec VPN
client from Windows Vista.
As said before, Vista and
Windows Server 2008 include a VPN L2TP/IPsec
client that will verify VPN server's name
from the certificate, if "Verify the Name and
Usage attributes of the server's certificate" is
checked.. See Figure2.
Figure2: Vista
L2TP/IPsec VPN Client Verify Server's
certificate
If the name of the
server to which the VPN client connects,
see Figure3
, does not match the one from the VPN
server's certificate, the connection will fail,
see Figure4.
Figure3: Vista
L2TP/IPsec VPN Connection: Specify Server's
Name
Figure4: Vista
L2TP/IPsec VPN Connection Failed
The log shows that the
name of the certificate was incorrect, instead
of "isamain.carbonwind.net", the certificates
was issued to "owa.carbonwind.net", and error
"CERT_E_CN_NO_MATCH" appears, see Figure5 .
It would be interesting
to see what this "name of the server's
certificate" means. For example, the log from
Figure5, was
generated using for the server a
certificate which "Subject"'s field contains the
CN(Common Name) "owa.carbonwind.net". It does
not contain the X509v3 extension "Subject
Alternative Name". So it looks that Vista
verified if the CN from the certificate matches
the one to which the VPN client connects.
I've generated another
certificate with the CN set to
"vpn.carbonwind.net" and "Subject Alternative
Name" to DNS Name "attack.carbonwind.net", see
Figure6. If
the name of the server to which the
VPN client connects is "vpn.carbonwind.net", the
connection fails with the error from Figure5. If
the name of the server to which the
VPN client connects is "attack.carbonwind.net",
the connection succeeds.
In addition Vista checks
the EKU field on the VPN server's certificate.
It appears that if the EKU field does not
contain Server Authentication
(1.3.6.1.5.5.7.3.1), the connection will
fail, the log showing "CERT_E_WRONG_USAGE"
error, see Figure7. Also
Vista accepts a VPN server certificate which
does not contain the EKU field, the log saying
"CertFindExtension failed with 0. This is OK as
it means all Key usages are valid", see Figure8.
If something or not is
achieved through this second check(EKU), depends
on the certificates used by clients.
We will see all these
later, in detail. We'll analyze(in pictures) the
machine authentication methods, certificates and
CAs.
What must be noted is
that with Vista or Windows Server 2008
L2TP/IPsec VPN Clients, the MITM posibility is
eliminated. And that is not all about the server
side when talking about a secure VPN solution,
the VPN client plays an important role too.
Also it appears that with
Windows 2008, in case of L2TP/IPsec site-to-site
connections, it is possible to check "Verify the
Name and Usage attributes of the server's
certificate". As writing this part I have
not tested yet this to see hwo it works. As
said before, in case of ISA Server 2006 (its VPN
functionality is handled through Windows Server
2003 RRAS), is not possible to perform this
check.
