[Openvpn-devel] OpenVPN Versioning

[James Y. <ja...@op...>]

I'm going to present some ideas and patches to make OpenVPN more solid 
in the area of versioning.  The overall goal is to make OpenVPN more 
robust with respect to differences between client and server in OpenVPN 
version, TLS version, protocol capabilities, and config file grammar.

Specifically:

1. Allow one OpenVPN config file to be universally used by different 
clients on different platforms, even if some of the directives target 
capabilities only available in newer OpenVPN versions or specific kinds 
of platforms (i.e. mobile).

2. Allow TLS versions higher than 1.0 to be negotiated when both client 
and server support them.

3. Improve the flexibility of the OpenVPN protocol negotiation so that 
parameters such as cipher and HMAC digest can be dynamically negotiated.

Versioning robustness is also a practical security feature, because it 
allows gradual rollout of updated security parameters in a large network 
without loss of service.  Security parameters might include minimum TLS 
version, allowed TLS ciphersuites, and OpenVPN cipher and HMAC digests.


Specific use case examples
--------------------------

(1) OpenVPN protocol negotiation: You are managing an OpenVPN server 
configured with the BF-128-CBC cipher.  You want to upgrade to 
AES-128-CBC to take advantage of hardware AES acceleration on the 
server, but not all clients in the field support AES yet.  With cipher 
negotiation, you could set up a mechanism where the server would 
negotiate AES-128-CBC with clients that support it, but downgrade to 
BF-128-CBC on clients that don't support either AES or the cipher 
negotiation capability itself.

(2) TLS version negotiation: You are managing an OpenVPN network and 
want to migrate to TLS 1.2 but still allow older clients to connect with 
TLS 1.0 for some period of time until it is phased out.

(3) Config file grammar: You are a developer and want to add a new 
OpenVPN config file directive, but don't want older clients to abort 
because they don't understand the directive.

Within these use cases are three areas where versioning is an issue, and 
I'll discuss each of them separately:

TLS Protocol
------------

Since day 1, OpenVPN has used TLS 1.0 as a control channel and key 
exchange mechanism.  But now we have TLS 1.1 and 1.2, each of which 
addresses significant shortcomings in its predecessor.  Fortunately, 
SSL/TLS already includes dynamic version negotiation.  So I've put 
together a patch that leverages on this, by allowing OpenVPN client and 
server to negotiate the TLS version and use the highest version 
supported by both peers.  The patch also adds a new directive 
"tls-version-min" that allows either client or server to specify a 
minimum required TLS version from the peer.

https://github.com/jamesyonan/openvpn/commit/6ee8faade224cc346d67a7f1716df4012782999a

OpenVPN Protocol
----------------

The OpenVPN protocol did not originally support handshaking, i.e. having 
the client and server mutually communicate their capabilities and use 
this info to dynamically select protocol parameters such as cipher, HMAC 
digest, compression algorithm, etc.

Instead of handshaking, we would manually add compatible directives to 
both client and server configs.  But this approach is not very flexible, 
because in the absence of a handshaked protocol negotiation, every time 
a configuration change is made on the server that affects the protocol 
(such as cipher type), all of the client configs must also be upgraded 
or they will fail to connect.

To improve flexibility, we've gradually increased the amount of 
handshaking that occurs in the OpenVPN protocol.  For example, with the 
recent addition of the Snappy compression algorithm, we now have a 
mechanism where the compression algorithm can be dynamically negotiated 
between client and server.

The basic mechanism for how this works is as follows:

After the TLS negotiation has succeeded but before the tunnel is active, 
the client communicates its capabilities to the server using a list of 
key/value pairs sent over the TLS control channel.  We will call this 
the Client Capabilities List (which itself was introduced in OpenVPN 2.1 
and was added to the OpenVPN protocol in a way that older clients would 
ignore it).

For example, running an OpenVPN 3.0 client on my mac, the following 
key/value pairs are sent to the server.

   IV_VER=3.0
   IV_PLAT=mac
   IV_SNAPPY=1
   IV_LZO=1

This tells the server that the client supports both Snappy and LZO 
compression protocols.  Now that the server knows this, it can choose a 
protocol that it also supports, and communicate this back to the client 
via a pushed directive:

   compress snappy

With this model, the client suggests a list of capabilities that it is 
willing to support, and the server makes the final selection from that 
list.  But this also gives the client some discretion, as it can choose 
to veto certain capabilities by not including them in the list sent to 
the server.  For example, suppose the client end-user chooses to disable 
compression.  In this case, the client will simply tell the server that 
it doesn't support compression, i.e.

   IV_VER=3.0
   IV_PLAT=mac
   IV_LZO_STUB=1
   IV_COMP_STUB=1

The "STUB" parameters indicate support for null compression algorithms 
that include the compression framing byte, but don't actually compress 
any data.

So this basic model of the client sending a key/value list of protocol 
capabilities to the server, and the server responding with push 
directives to select the actual protocol feature can be a basic building 
block for adding additional negotiated features to the OpenVPN protocol.

For example, this model could be used to negotiate other protocol 
capabilities such as cipher and HMAC digest:

   IV_CIPHER=BF-CBC,AES-128-CBC
   IV_AUTH=SHA1,SHA256,SHA512

After receiving this info from the client, the server could choose a 
cipher and auth parameter and push it back to the client.  Among other 
things, this requires that the client supports pushed "cipher" and 
"auth" directives (currently only the 3.0 core supports this).  There is 
also the issue of the size of the Client Capabilities List.  The 
IV_CIPHER and IV_AUTH lists might grow to be quite long, and the current 
Client Capabilities List is limited in size to 2048 bytes based on the 
TLS_CHANNEL_BUF_SIZE constant in common.h.  To reduce the size, we might 
consider:

(a) use a single character designation for ciphers and HMAC digests, 
such as:

Cipher Codes:
  A : BF-CBC
  B : AES-128-CBC
  . . .

Then communicate IV_CIPHER using the cipher codes:

   IV_CIPHER=AB

This would require that the OpenVPN Project standardize on set of codes 
for ciphers and HMAC digests.

(b) remove the 2048 byte limitation on the Client Capabilities List. 
The limitation arises because of the packetization of messages over the 
OpenVPN control channel.  One way to resolve this would be to 
standardize on a continuation marker that tells the peer that another 
packet of Client Capabilities List data is forthcoming.  This would be 
similar to how the same problem was solved with the pushed directives 
list using continuations.

Rather than choosing either (a) or (b) I would suggest implementing them 
both.  The number of ciphers and digests is always increasing and using 
a one or two-character code to denote a cipher or digest will make the 
Client Capabilities List smaller and faster to pass over the wire.  It 
would also be good to fix (b) since it seems like an arbitrary 
limitation that could cause issues as the Client Capabilities List grows.

Config file grammar
-------------------

Originally, OpenVPN was strict about config file directives that it 
didn't recognize -- it was a fatal error to specify an unrecognized 
directive.

In many cases this is beneficial for security in the sense that a 
directive such as ns-cert-type or tls-remote, if not understood by the 
client and ignored, could render the connection much less secure than 
intended.

But it also reduces flexibility because it makes adding new directives 
unnecessarily difficult if the new directive crashes an older client 
that doesn't yet recognize it.

One solution that was introduced in OpenVPN 2.1 added a new directive 
that would cause any unrecognized directive to be ignored.

   setenv FORWARD_COMPATIBLE 1

In hindsight, this is probably too broad.  It would be better to allow 
individual directives to specify whether older clients that don't 
recognize them should ignore them or abort.

I've put together a new (and very small) patch that I believe solves the 
problem in a better way.

https://github.com/jamesyonan/openvpn/commit/037690df22a4604a556c9b470d1f5e891991834b

This patch defines a new directive prefix "setenv opt" that if prepended 
to an existing directive, will cause it to be ignored by clients that 
don't understand it (starting the directive with "setenv" is useful 
because OpenVPN clients going back to 2.0 don't really care what comes 
after the "setenv", so older clients should simply ignore the prefix).

To look at an example, the TLS versioning patch above adds a new 
directive "tls-version-min" to set the minimum allowed TLS version used 
by the peer.  Example client usage might be:

   tls-version-min 1.2

Suppose I want to put this directive in the config files I distribute to 
clients, but have it be ignored by older clients that don't recognize 
it.  I could do this as follows on the client:

   setenv opt tls-version-min 1.2

Suppose I also want to handle the case where some clients understand the 
tls-version-min directive but are not linked with an SSL library that 
supports TLS 1.2.  To allow these clients to gracefully degrade to the 
highest TLS version they can support, a variation of the directive could 
be used on the client:

   setenv opt tls-version-min 1.2 or-highest

Now suppose that after some upgrade period, we now want to require that 
all clients connect at TLS 1.2 or higher, and that 1.1 and 1.0 are no 
longer allowed.  This can be done by limiting TLS to 1.2 or higher on 
the server:

   tls-version-min 1.2

James