Re: [Openvpn-users] Man-in-the-middle Attack

[James Yonan <jim@xxxxxxxxx>]

On Sat, 28 May 2005, Paolo Coppo wrote:

> Hello James,
> 
> I am Paolo.
> 
> I appreciate your great work on OPENVPN and I would like to TEST it
> deeply.
> 
> I have same questions about the Man-in-the-middle vulnerability. I have
> already read a lots of articles on your newsgroup about it, but there is
> problem that I cannot understand.
> 
> If the client miss the server Certificate (could be different to the CA
> one) and the server don't check client certificates (server accept
> connections even if I delete all client certificates from the VPN
> Server) how client and server could authenticate each other in an
> inequivocabile way?

The OpenVPN client config must specify a CA, and the connecting server 
must supply a certificate which was signed by that CA.  This is how the 
client authenticates the server.

The server must also authenticate the client as well.  This is done 
by having the client present a certificate and/or username/password to the 
server.

> They seem to accept all certificates that are generate from the same CA
> (like Windows IPSEC do!)

There's several steps involved in authenticating a certificate.  Step (1)  
verifies that the certificate was signed by the provided CA certificate
(or CA certificate chain if you are using intermediate CAs).  Step (2)
verifies information embedded in the certificate such as the X509 subject
string or common name (--tls-remote/--tls-verify) and/or the certificate
serial number (--crl-verify).

> The tls-remote and ns-Cert-Type options check only the CN of the server
> and the CA. They are informations easy to collect by an attaccker.

An attacker could certainly view the public information contained within a 
certificate such as the common name.  This is something allowed by all 
public key cryptosystems which rely on usage of certificates and private 
keys.

What an attacker couldn't feasibly do is CHANGE this information.  That's
why we use the two-step authentication process above.  Step (1) tells us
that the common name, serial number, ns-cert-type client/server bit, etc.  
have not been tampered with.  Once we know that this information embedded
in the certificate can be trusted, we can then proceed to step (2) where
we decide whether or not to allow the connection based on this trusted
information.

> The tls-auth option is based on a STATIC key and, like pre-shared key,
> it must be known from a lot of people in production enviroments. An
> "internal" attaccker can easy obtain it.

True, but the goal of the tls-auth key is to provide security more along
the lines of a firewall/packet-filter than the full cryptographic security
provided by the SSL/TLS layer.  Think of tls-auth as being a cryptographic
packet filter that operates before incoming packets are handed off to the
SSL/TLS layer.  Most firewall-based packet filters accept or reject
packets based on cleartext information present in the packet header such
as protocol, port number, source/dest IP address, etc. -- information
which can easily be forged.  tls-auth is designed to be a better packet
filter because it is cryptographically based.  Without the tls-auth key,
an attacker would not be able to craft a packet which would make it past
the initial packet filter.

However, because tls-auth is a packet filter only, and operates
independently of the SSL/TLS security layer, the tls-auth key does not
need the same level of protection as the SSL/TLS session keys.  Suppose
the worst case scenario: the tls-auth key is compromised.  The most an
attacker can do at that point is get past the tls-auth packet filter and
initiate an SSL/TLS handshake.  They would still need to crack the SSL/TLS
layer itself in order to compromise the VPN.  And if you are using
user/group/chroot, they would need a couple more kernel exploits to
achieve root access and escape from the chroot jail.

The goal here is redundancy.  We want to make sure that an attacker would 
need to simultaneously exploit vulnerabilities in multiple, unrelated code 
bases in order to succeed in their attack.  In practice, this is very 
difficult to do.

> I think that security can be increased with the implementation of an
> authentication phase based on an key exchange between client and server
> using encryption with their asymmetric RSA keys  (according the standard
> use of private and public keys).

Of course -- that's exactly what TLS is.

If tls-auth was complexified into another independent TLS layer, then we 
would have TLS over TLS.  That doesn't buy us any more security than 
single TLS -- in fact it gives us less security because now a single 
attack against TLS could be used to penetrate both layers.

In addition:

Making tls-auth more like TLS would also defeat another important security
feature of tls-auth: stealth against port scanners.  Normal TLS requires a
multi-packet handshake before the TLS server is able to determine that a
client is not authorized to connect.  This means that an attacker can set
up a port scanner to reveal listening TLS servers.  Since tls-auth is a
packet filter, it can drop bad packets without any response by checking
the HMAC-SHA1 signature.  This makes it impossible for an attacker to nmap
your IP address and see that you have an OpenVPN server listening on a
certain port (provided you are using --tls-auth and --proto udp).

Making tls-auth more like TLS would also reduce its effectiveness in
dealing with DoS attacks.  TLS is vulnerable to DoS attacks where an
attacker floods the server with lots of bogus handshake initiations using
incorrect keys.  These handshake attempts ultimately fail, but only after
a significant number of CPU cycles have been wasted.  Because tls-auth is
based on a simple, static HMAC-SHA1 integrity check, far fewer cycles must
be wasted before throwing away a bogus packet, because that packet never
makes it to the TLS layer.

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users