OpenVPN 1.5-beta10 has been released with a number of important fixes for the
Windows version, and two changes to the crypto layer.


OpenVPN on the Win2K platform has been showing problems in several areas due
to incompatibilities between XP and Win2K.  Since until recently I did not
have access to a Win2K system, I was unable to do real testing on the
platform, aside from getting email reports about problems.  Luckily, someone
has come forward and set up a VMWare Win2K virtual machine for me which I can
remotely access.  I'm confident this will bring the 1.5 beta series on Win2K
up to the same level of quality as on XP.

I believe I've fixed the outstanding issues on Win2K:

* The install now pops up a dialog box encouraging you to reboot.  While
rebooting is unnecessary on XP, it appears to be critical on Win2K.

* When --ifconfig is used, OpenVPN now gives a choice of 3 methods for setting
the IP address and subnet mask of the TAP-Win32 adapter, using the --ip-win32
option.  In beta8 and beta9, --ifconfig was hardwired to use the netsh option.
 My newly acquired remote access to a Win2K VM has shown me that netsh is
rather broken on Win2k and shouldn't be relied upon (though it works well on
XP).  So the default operation is now to use a little-known Windows API called
the "IP Helper API" to set the address.  This option, while not having ideal
semantics, appears to work consistently on both Win2K and XP.  The --ip-win32
option is fully documented on the man page which can be viewed on the web site.


The other changes which deserve some discussion involve the crypto layer.

Some of you may have read Peter Gutmann's critique on "Linux VPNs" which was
slashdotted a couple weeks ago.

Peter actually likes OpenVPN (from a crypto perspective) and has been very
forthcoming in offering his crypto expertise to our project.


One issue that has come out of these discussions is that while OpenVPN
implements protections against message duplication (i.e. replay protection) it
does not fully protect against message reordering.

There's an important reason for this, however.  When OpenVPN sends encrypted
packets via UDP, it is part of the specification of UDP that packets may
arrive in a different order than how they were sent.  So the network itself
may reorder packets as normal behavior, making it difficult to distinguish a
malicious reordering attack from innocuous network behaviour.

When OpenVPN receives packets in a different order than how they were sent, it
passes these reordered packets up to the TCP layer where they are sorted back
into their proper order.  The problem is that while TCP is able to deal with
normal reordering which occurs over the physical transport layer, one could
imagine an attacker attempting to break through the VPN security layer by
maliciously reordering packets in an attempt to sneak through the VPN security
layer and attack the TCP layer directly.  This type of attack would require
that the attacker had direct access to the VPN link with the ability to read,
delete, and insert packets.  Basically, the attacker would delete a packet
going over the wire, but make a copy of it first.  He would then insert the
packet into the ciphertext stream at a later time with the goal of confusing
TCP into thinking that the packet is part of a current session.

There would be another hurdle as well.  OpenVPN since 1.1.0 has implemented
sliding window replay protection (like IPSec) with a window size of 1024
packets.  The maliciously inserted packet would also need to be not so old
that its sequence number had slid off the end of the sliding window, in which
case it would be rejected.  So that rogue packet could be reinserted back into
the stream no later than 1024 packets since it was first extracted.  That
means that attacks that focus on TCP sequence number wraparounds would not be
feasible either.

These hurdles make the attack mostly theoretical at this point, though I do
have concern that non-IP protocols might be more vulnerable to malicious
packet reordering than TCP.  For that reason, I've strengthened the replay
protection model in 1.5-beta10.  The first change is to decrease the 1024-wide
packet window to 256.  The second change is to add a time-element to the
window of 15 seconds.  This means that any packet representing a sequence
number backtrack must arrive no later than 15 seconds after any packet with a
larger sequence number.  These constraints should prevent malicious reordering
attacks but still allow normal physical layer reordering.  This problem of
reordering attacks is not unique to OpenVPN -- IPSec has it as well.


OpenVPN (like TLS 1.0) uses a common technique for IV generation that involves
saving the residual IV state from packet n and using it as the IV for packet 

Weaknessness, however, have been found in this approach.

See item #2 in this document:

While the weakness appears to be mostly theoretical at this point, I've
modified the IV generation code in OpenVPN to use a random IV (derived from a
SHA1-based PRNG).


While both changes protect against attacks that are largely theoretical at
this point, I've implemented them in the interest of thoroughness, and in
keeping with OpenVPN's crypto philosophy of remaining in sync with
developments occurring in the SSL/TLS and IPSec worlds.

It should also be noted that neither crypto change affects the OpenVPN
protocol or breaks compatibility with earlier versions of OpenVPN.


Reply via email to