[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] First OpenVPN 2.0 Release Candidate is available

  • Subject: Re: [Openvpn-users] First OpenVPN 2.0 Release Candidate is available
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Wed, 8 Dec 2004 04:35:29 -0700 (MST)

On Wed, 8 Dec 2004, Richard Atterer wrote:

> On Tue, Dec 07, 2004 at 02:37:31PM -0700, James Yonan wrote:
> > I would encourage everyone to give it a workout in as many real-world
> > situations as possible.
> Hi, IMHO there is a problem in the way the recent man-in-the-middle
> vulnerability (you could call it that!) was handled.
> AFAICT, neither the program nor the documentation currently prevent 
> from making the mistake of not specifying the "tls-verify" option to 
> this problem. Was the HOWTO updated at all about this?

I agree that this issue should be amplified in the docs.

Having said that, there are currently three separate directives for
verifying the peer certificate:  tls-remote, tls-verify, and the new
ns-cert-type directive, and any one of these can be used by clients to
make sure they are connecting to a bona-fide server.

> The problem should also be mentioned prominently on the main web page.
> Additionally, it might even be a good idea to post a summary about this 
> Bugtraq.

I not averse to a bugtraq posting, though I see this more as a problem of
configuration than a bug in the code.  If you are signing certificates and
granting VPN access to individuals whom you don't fully trust, then you
are venturing into a part of the security configuration space where there
is going to be less margin for error, and you are certainly going to need
to configure clients to pay attention to the server's X509 certificate
fields even if you are acting as your own CA.

> You may not agree, but I think it would be beneficial to intentionally
> break people's setups with 2.0 to force them to fix their setup. For
> example, openvpn could demand an explicit "tls-verify any" to continue
> working the way it currently does.
> OpenVPN's _default_behaviour_ should prevent this vulnerability!

OpenVPN allows a lot of flexibility in terms of configuration, and some
users may purposely choose a configuration with less security than normal
simply because it makes sense for their application.  Normally, this kind
of usage gets a warning, and I think that running a TLS client without one
of tls-remote, tls-verify, or the new ns-cert-type directives should also
trigger a warning.  On the other hand, making it a fatal error would 
certainly get people's attention.  I'd want more feedback before taking 
that route, as it generally goes against the approach we've used so far of 
issuing warnings but otherwise assuming that people know what they're 


Openvpn-users mailing list