openvpn-users — OpenVPN users list

[Openvpn-users] OpenVPN 1.1-pre2 available

[James Y. <ji...@nt...>]

Another beta is available, please test.

1.1 final should be forthcoming in a couple days if I don't hear of any
problems.

pre1 -> pre2 changes:

* New option --shaper that does traffic shaping (i.e. bandwidth limiting).
This option could be used for example to build two tunnels between the same
peers, one running at full speed, and the other at reduced bandwidth for
batch-type transfers such as off-site-backups.  See the man page for more
info.

* Fixed "make install" to also install the man page.

* OpenBSD and --tun-af-inet fixes.

* Other minor fixes.

* CVS updated.

* Manual page updated.

http://openvpn.sourceforge.net/beta/openvpn-1.1-pre2.tar.gz

James

Re: [Openvpn-users] OpenVPN 1.1 beta available

[James Y. <ji...@nt...>]

 > Will this work politely with my (ahem) *other* tun-using VPN package?
I'm
> pretty sure that it won't stomp on tuns in use, but I want to be sure.

Yes, it should work fine.  Just make sure you use a unique UDP port number
(--port n) for each tunnel and that you don't use the same UDP port as the
"other" package.

As far as TUN devices are concerned, OpenVPN will fail gracefully if you try
to open a TUN device being used by another app.  Under the latest TUN/TAP
driver, if you say something like "--dev tun", OpenVPN will dynamically
allocate a TUN device.  Under all TUN/TAP drivers you can say "--dev tun2"
and then it will explicitly try to open that tun and fail if it's already
open by someone else.

James

[Openvpn-users] OpenVPN 1.1 beta available

[James Y. <ji...@nt...>]

Here's the latest beta...  Contains a lot of cool stuff including automake
configuration, a BSD 3.0 port, fixes for CFB/OFB IV, reworked replay
protection and IV based on IPSec,  --mlock (to disable paging), special
handling for all DES keys wrt. parity and weak keys, and an updated manual
page.

The only known issue right now is that for some reason (on my machine) "make
install" only installs the binary, not the man page.  I'm an automake newbie
and haven't really tried to figure it out yet.

Anyway, build it, test it, beat on it, etc.

http://openvpn.sourceforge.net/beta/openvpn-1.1-pre1.tar.gz

James

************************************

ChangeLog

2002.04.07 -- Version 1.1-pre1

* Strengthened replay protection and IV handling,
  extending it fully to both static key and
  TLS dynamic key exchange modes.
* Added --mlock option to disable paging and ensure that key
  material and tunnel data is never paged to disk.
* Converted to automake by The Platypus Brothers 2002-04-01.
* Ported to OpenBSD by Janne Johansson.
* Added --tun-af-inet option to work around an incompatibility
  between Linux and BSD tun drivers.
* Sequence number-based replay protection using the
  IPSec sliding window model is now the default,
  disable with --no-replay.
* Explicit IV is now the default, disable with --no-iv.
* Disabled all cipher modes except CBC, CFB, and OFB.
* In CBC mode, use explicit IV and carry forward residuals,
  using IPSec model.
* In CFB/OFB mode, IV is timestamp, sequence number.
* Eliminated --packet-id, --timestamp, and max-delta parameter to
  the --tls-auth option as they are now supplanted by improved
  replay code which is enabled by default.
* Eliminated --rand-iv as it is now obsolete with improved
  IV code.
* Eliminated --reneg-err option as it increases vulnerability
  to DoS attacks.
* Added weak key check for DES ciphers.
* --tls-freq option is no longer specified on the command line,
  instead it now inherits its parameter from the
  --tls-timeout option.
* Errata fixed in the man page examples: "test-ca" should be
  "tmp-ca".
* Other manual page changes.
* Preliminary work in porting to OpenSSL 0.9.7.

Re: [Openvpn-users] security advisory for 1.0.3 concerning CFB, OFB, and DES ciphers

[James Y. <ji...@nt...>]

On Tue, Apr 02, 2002 at 02:05:35PM -0700, James Yonan wrote:

>> * If you try to use a CFB or OFB mode cipher, OpenVPN fails to warn you
that
>> you also need to use the --rand-iv option.
>>
>> * The --rand-iv option currently does not guarantee that each IV is
unique
>> for a given key.  Uniqueness of IV is a requirement for for CFB and OFB
mode
>> ciphers.  OpenVPN normally uses IVs equal in size to the cipher block
size

>It is also required for CBC mode.

Yes, but CBC mode doesn't require that the IV be unique, so using --rand-iv
with CBC mode is still fine.

I'm thinking that it makes more sense to make IV the default, and make the
user explicitly disable and/or show a warning, since IV is really integral
to all modes where multiple messages are being encrypted with the same key.

What I will probably do is change the CBC IV to work like it does in IPSec:
carry forward the IV from the previous datagram but explicitly record it in
the datagram as well (since the datagrams are using an unreliable transport,
packets could get dropped or reordered).  The IPSec drafts advise against
using an IV generated pseudo-randomly because they worry it could reveal too
much about the inner workings of the random number generator.

The CFB/OFB IV needs to be unique, so I will probably use something like
[time_t (4 bytes), sequence number (4 bytes)] rather than the carried
forward IV.  Bruce Schneier says in "Applied Cryptography" that the IV can
be an incrementing index in these modes.

>> which is usually 64 bits.  There is a 50% probability that if you forward
>> 2^32 packets, there will be two packets that have the same IV.  The next
>> release of OpenVPN will ensure that each IV is unique when used with a
CFB
>> or OFB mode cipher.

>Ah, so actually the CFB and OFB modes do use an IV, but it's just 8 bits
>big? And by virtue of the birthday paradox, that would mean there's 50%
>change if you forward more than 16 packets.

Sorry, I meant the block size of the cipher, not the block size of the mode.
CFB and OFB modes use 8 byte IVs.

OpenVPN gets the IV size of a particular cipher by calling
EVP_CIPHER_CTX_iv_length in OpenSSL.

James

Re: [Openvpn-users] security advisory for 1.0.3 concerning CFB, OFB, and DES ciphers

[Guus S. <gu...@sl...>]

On Tue, Apr 02, 2002 at 02:05:35PM -0700, James Yonan wrote:

> * If you try to use a CFB or OFB mode cipher, OpenVPN fails to warn you t=
hat
> you also need to use the --rand-iv option.
>=20
> * The --rand-iv option currently does not guarantee that each IV is unique
> for a given key.  Uniqueness of IV is a requirement for for CFB and OFB m=
ode
> ciphers.  OpenVPN normally uses IVs equal in size to the cipher block size

It is also required for CBC mode.

> which is usually 64 bits.  There is a 50% probability that if you forward
> 2^32 packets, there will be two packets that have the same IV.  The next
> release of OpenVPN will ensure that each IV is unique when used with a CFB
> or OFB mode cipher.

Ah, so actually the CFB and OFB modes do use an IV, but it's just 8 bits
big? And by virtue of the birthday paradox, that would mean there's 50%
change if you forward more than 16 packets.

--=20
Met vriendelijke groet / with kind regards,
  Guus Sliepen <gu...@sl...>

[Openvpn-users] security advisory for 1.0.3 concerning CFB, OFB, and DES ciphers

[James Y. <ji...@nt...>]

This advisory is only relevant for people using the --cipher option to use
either a CFB or OFB mode cipher or a DES cipher.  It does not affect anyone
using OpenVPN's default cipher, BF-CBC.

* If you try to use a CFB or OFB mode cipher, OpenVPN fails to warn you that
you also need to use the --rand-iv option.

* The --rand-iv option currently does not guarantee that each IV is unique
for a given key.  Uniqueness of IV is a requirement for for CFB and OFB mode
ciphers.  OpenVPN normally uses IVs equal in size to the cipher block size
which is usually 64 bits.  There is a 50% probability that if you forward
2^32 packets, there will be two packets that have the same IV.  The next
release of OpenVPN will ensure that each IV is unique when used with a CFB
or OFB mode cipher.

* If you use a DES cipher, for example DES-EDE3-CBC, OpenVPN does not check
that its randomly generated key is of odd parity and is not a weak or
semi-weak key.

I will fix all these issues in 1.1.0 which I hope to have out by the end of
this weekend.

Thanks,
Jim Yonan

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[James Y. <ji...@nt...>]

Oops, this paragraph should read:

Getting back to RFC 2065, given that OpenVPN offloads key management to the
OpenSSL library, it's really up to OpenSSL whether or not they will support
DNS-based key management.  This is in keeping with OpenVPNs modular
philosophy (let TUN/TAP do the tunneling, let OpenSSL do the security).  If
I were to implement it, I would do it as a patch to OpenSSL.

----- Original Message -----
From: "James Yonan" <ji...@nt...>
To: "bishop" <bi...@pl...>; <ope...@li...>
Sent: Sunday, March 31, 2002 3:34 PM
Subject: Re: [Openvpn-users] Features that should be in OpenVPN or VTun


> >   - public-key encryption based on KEY records in DNS
> >
> > Hit the DNS, get the key, now you don't have to store it any place, and
> you
> > can discover it.  If you can think of an easier way to discover a KEY,
> then
> > I'm all ears.
>
> Well the fundamental problem with key management is that nobody has
figured
> out a way for two parties on the internet to prove their identity to each
> other without the use of either a centralized authority (i.e. verisign,
> thawte, etc.), a web of trust (i.e. PGP), or the model of a small-scale
> certificate authority such as one that authenticates the certificates of
all
> members of a small business so they can work from home over a secure link.
>
> But the combination of TLS and RSA certificates goes a long way in
creating
> a useful public key infrastructure (PKI) where people can prove their
> identities to each other without the use of pre-shared secrets.  OpenVPN,
by
> its reliance on TLS, also supports a full PKI.  OpenVPN also supports
> pre-shared keys as well, so you have a choice on whether or not you want
to
> use TLS.
>
> Now I'm not too familiar with KEY records but I took a look at RFC 2065
and
> I don't see any reason why it couldn't be done.  After all, you're just
> distributing public keys which are designed for public distribution.  If
> anybody tries to spoof them, the certificate authority test will fail.  In
> order to spoof, an attacker would need access to the private key which was
> used to sign the public key certificate.
>
> That's one of the reasons why Versign is riding high and the CEO of Thawte
> is training to be the world's second space tourist, paying the $20 million
> fare to the Russians using pocket change he received for selling Thawte
(and
> all this while the .coms were falling like flies).  All that money comes
> from the need of millions of secure web site operators to be able to
present
> a public certificate that proves their identity and cannot be forged
(unless
> you figure out how to crack some pretty intractable problems in number
> theory and factoring).
>
> Getting back to RFC 2065, given that OpenVPN offloads key management to
the
> OpenSSL library, it's really up to OpenSSL whether or not they will
support
> DNS-based key management.  This is in keeping with OpenVPNs modular
> philosophy (let TUN/TAP do the tunneling, let OpenVPN do the security).
If
> I were to implement it, I would do it as a patch to OpenSSL.
>
> >   - on-demand connections.
> >
> > Keep the IFaces up all the time.  Route data to it, and connect the
actual
> > TUNs with the high-water mark is reached.
>
> OpenVPN supports persistent TUN/TAP devices if you want to keep the
> interfaces up all the time.  See the --mktun option.
>
> >
> >   - Dynamic on-demand default tunnels using discovered Keys
> >
> > Send all data out via the TUN, except data that's already encapsulated.
> If
> > a tunnel cannot be established, then send it in the clear.  Otherwise,
set
> > up tunnel and shoot data.
>
> Sending in the clear is dangerous for any VPN package, because people
might
> mistakenly use it without realizing it.  Because of this, OpenVPN requires
> you to explicitly disable either encryption or authentication if you don't
> want it, and then it warns you in big capital letters if that is what you
> really want.
>
> Jim
>
>
>
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[James Y. <ji...@nt...>]

>   - public-key encryption based on KEY records in DNS
>
> Hit the DNS, get the key, now you don't have to store it any place, and
you
> can discover it.  If you can think of an easier way to discover a KEY,
then
> I'm all ears.

Well the fundamental problem with key management is that nobody has figured
out a way for two parties on the internet to prove their identity to each
other without the use of either a centralized authority (i.e. verisign,
thawte, etc.), a web of trust (i.e. PGP), or the model of a small-scale
certificate authority such as one that authenticates the certificates of all
members of a small business so they can work from home over a secure link.

But the combination of TLS and RSA certificates goes a long way in creating
a useful public key infrastructure (PKI) where people can prove their
identities to each other without the use of pre-shared secrets.  OpenVPN, by
its reliance on TLS, also supports a full PKI.  OpenVPN also supports
pre-shared keys as well, so you have a choice on whether or not you want to
use TLS.

Now I'm not too familiar with KEY records but I took a look at RFC 2065 and
I don't see any reason why it couldn't be done.  After all, you're just
distributing public keys which are designed for public distribution.  If
anybody tries to spoof them, the certificate authority test will fail.  In
order to spoof, an attacker would need access to the private key which was
used to sign the public key certificate.

That's one of the reasons why Versign is riding high and the CEO of Thawte
is training to be the world's second space tourist, paying the $20 million
fare to the Russians using pocket change he received for selling Thawte (and
all this while the .coms were falling like flies).  All that money comes
from the need of millions of secure web site operators to be able to present
a public certificate that proves their identity and cannot be forged (unless
you figure out how to crack some pretty intractable problems in number
theory and factoring).

Getting back to RFC 2065, given that OpenVPN offloads key management to the
OpenSSL library, it's really up to OpenSSL whether or not they will support
DNS-based key management.  This is in keeping with OpenVPNs modular
philosophy (let TUN/TAP do the tunneling, let OpenVPN do the security).  If
I were to implement it, I would do it as a patch to OpenSSL.

>   - on-demand connections.
>
> Keep the IFaces up all the time.  Route data to it, and connect the actual
> TUNs with the high-water mark is reached.

OpenVPN supports persistent TUN/TAP devices if you want to keep the
interfaces up all the time.  See the --mktun option.

>
>   - Dynamic on-demand default tunnels using discovered Keys
>
> Send all data out via the TUN, except data that's already encapsulated.
If
> a tunnel cannot be established, then send it in the clear.  Otherwise, set
> up tunnel and shoot data.

Sending in the clear is dangerous for any VPN package, because people might
mistakenly use it without realizing it.  Because of this, OpenVPN requires
you to explicitly disable either encryption or authentication if you don't
want it, and then it warns you in big capital letters if that is what you
really want.

Jim

Re: [Openvpn-users] Interaction with Windows VPN Server/Client

[James Y. <ji...@nt...>]

> > Actually, that wasn'y my question - weither OpenVPN will be ported to
> > Windows or not. The question was, is OpenVPN able to communicate and
> > establish a VPN connection with other VPN products (such as Windows VPN
> > clients, Cisco routers, etc.) or ONLY other OpenVPN's.

Well the compatibility question is an interesting one.  OpenVPN uses TLS
(the latest generation of SSL) for session authentication and key exchange.
It's the same protocol used by all the secure web browsers out there in the
world.  That means that you have full access to the public key
infrastructure that currently exists with respect to the secure web.  You
can use SSL certificates, certificate authorities, use the openssl tool to
create your own certificates, keys, etc.

The problem is that to my knowledge, OpenVPN is the first open source VPN to
actually use the TLS protocol.  Up until now, TLS has mostly been used by
secure web browsers such as Apache/ModSSL.  Why TLS hasn't been more widely
used in VPNs is a mystery to me.  It is solid, it is secure, it has
withstood the test of time.

Perhaps the reason is IPSec.  A great deal of effort has been expended over
the last few years in making IPSec the standard security solution for IP in
the same way that SSL has been the security solution for the web.  The IPSec
effort looks promising, but some of the results have been mixed.  To use
IPSec under linux for example, you must patch your kernel.  IPSec is also
very complex and is just starting to see more widespread usage, but it is
hampered by its complexity.  Because of this, it will probably be some time
before IPSec is as mature or stable as SSL/TLS.

For some criticisms of IPSec security, see:

http://alternic.net/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html

http://www.off.net/~jme/ietf/

So to answer your question, right now OpenVPN is the only VPN to use the TLS
protocol (OpenVPN uses the TLS protocol for session authentication and key
exchange, but it uses the OpenSSL EVP cipher library to actually encrypt the
tunnel data packets using the key it negotiated over TLS.) and therefore if
you want to use OpenVPN, you must run it on both peers.  If you want a VPN
that is more standardized, check out IPSec.  But I will maintain that
OpenVPN accomplishes a lot of what IPSec sets out to do, but with a
dramatically lighter footprint.

Now of course, once you set up an OpenVPN link between two peers, you can
route any IP over it, regardless of where that IP orginates (Windows, Unix,
Cisco, etc.).  For example, I use Windows NT extensively for my work, and my
NT laptop routes packets over the OpenVPN link without even knowing it's
there.

Hope that helps.

James Yonan

Re: [Openvpn-users] Interaction with Windows VPN Server/Client

[bishop <bi...@pl...>]

Theepan wrote:
>>Theepan wrote:
>>
>>>Hello,
>>>
>>>Can OpenVPN for Linux connect to a Windows NT/2000 VPN Server, and vice
>>>versa - can a Windows VPN Client connect to OpenVPN?
>>
>>OpenVPN uses the Linux TunTap driver, version 1.1 for kernel 2.2 and
>>version 1.4 delivered with kernel 2.4 .
>>
>>The TUN interface has not been delivered for Windows.  There is an effort,
>>and the vtun-users or vtun-devel list tracks the progress.  Go search.
>>
>>The TUN device is a sub-project or co-project of the VTun project, which
> 
> is
> 
>>why it uses the same lists.
>>
> 
> Actually, that wasn'y my question - weither OpenVPN will be ported to
> Windows or not. The question was, is OpenVPN able to communicate and
> establish a VPN connection with other VPN products (such as Windows VPN
> clients, Cisco routers, etc.) or ONLY other OpenVPN's.
> 
> I don't know much about VPN, and maybe I was wrong asking the question, but
> I thought there existed some kind of standards (like RFC) describing how VPN
> connections are established and "used", just like FTP, WWW, IRC, you name
> it.

Oh!  I'm sorry!  Yes, I misunderstood, completely.  The common question I 
hear is "Will XX be ported to windows", and I made a bad guess.

To the best of my knowledge, no : OpenVPN may only, at this time, connect 
with other OpenVPN nodes.

Here's also what I have heard:

  - PPTP is a rather established protocol, although I've not seen the RFCs 
describing it.  I've linked Windows to Linux servers.

  - VTun is the other Tun-using implementation.  It's the closest to 
OpenVPN, but is not compatible.  VTun may also only connect to other VTuns.

  - IPSec hosts can, usually, connect to other IPSec hosts.  These include 
Cisco hardware, Win2k (I think that's the version), PIPSec under linux, 
FreeS/WAN under linux, several smaller VPN hardware devices and a few 
software implementations.

Note that some mangling is usually required, however.  For instance, 
FreeSWAN needs an optional x.509 patch before the windows IPSec will talk 
with it appropriately, I hear.  Also, the amoung of configuring is 
inversely proportional to how broad the support is - FreeSWAN, for 
instance, is far too complex for my little brain.  I tested a FreeSWAN 
kernel RPM with the help of a friend's comfig pair.

The PIPSec IPSec shows the most promise for getting OpenVPN to use IPSec. 
It's an older TUN-using user-space IPSec implementation that's been 
unsupported for about 3-4 years, from what I hear.

  - bish

-- 
	Excellent... rime ice, a summit ridge, small trees blanketed in
	snow and ice like legions of twisted killer mutant deranged snow
	goons.			-- Erick DeOliveira 20020208
  	 
		   Describing his first Winter Ascent

Re: [Openvpn-users] Interaction with Windows VPN Server/Client

[Theepan <to...@li...>]

> Theepan wrote:
> > Hello,
> >
> > Can OpenVPN for Linux connect to a Windows NT/2000 VPN Server, and vice
> > versa - can a Windows VPN Client connect to OpenVPN?
>
> OpenVPN uses the Linux TunTap driver, version 1.1 for kernel 2.2 and
> version 1.4 delivered with kernel 2.4 .
>
> The TUN interface has not been delivered for Windows.  There is an effort,
> and the vtun-users or vtun-devel list tracks the progress.  Go search.
>
> The TUN device is a sub-project or co-project of the VTun project, which
is
> why it uses the same lists.
>

Actually, that wasn'y my question - weither OpenVPN will be ported to
Windows or not. The question was, is OpenVPN able to communicate and
establish a VPN connection with other VPN products (such as Windows VPN
clients, Cisco routers, etc.) or ONLY other OpenVPN's.

I don't know much about VPN, and maybe I was wrong asking the question, but
I thought there existed some kind of standards (like RFC) describing how VPN
connections are established and "used", just like FTP, WWW, IRC, you name
it.

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[bishop <bi...@pl...>]

Guus Sliepen wrote:
> On Sun, Mar 31, 2002 at 08:55:19AM -0500, bishop wrote:
> 
> 
>>Should I have mentioned explicitly that I was not thinking of active 
>>attacks, and only about passive attacks?  Sorry, bad me.  In this day and 
> 
> That would've put things into perspective, and I wouldn't have replied
> to your mail in that case.

Is that all I had to mention?  I reasearched and wrote for 6 hours,
deleted 8 drafts, and all I needed to do was duly emphasize the known
weakness inherent in a system that may or may not encrypt an outgoing
packet?

Glad we found the problem, but I'm going back to rolling RPMs;  this
is just too stressful for me 8-)

  - bish
RPM Lackey

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[Guus S. <gu...@sl...>]

On Sun, Mar 31, 2002 at 08:55:19AM -0500, bishop wrote:

> Should I have mentioned explicitly that I was not thinking of active=20
> attacks, and only about passive attacks?  Sorry, bad me.  In this day and=
=20

That would've put things into perspective, and I wouldn't have replied
to your mail in that case.

--=20
Met vriendelijke groet / with kind regards,
  Guus Sliepen <gu...@sl...>

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[bishop <bi...@pl...>]

Guus Sliepen wrote:
> On Sun, Mar 31, 2002 at 06:09:54AM -0500, bishop wrote:
> 
> 
>> - public-key encryption based on KEY records in DNS
>>
>>Hit the DNS, get the key, now you don't have to store it any place, and you 
>>can discover it.  If you can think of an easier way to discover a KEY, then 
>>I'm all ears.
> 
> 
> Really, that is not very secure. Somebody could take over the DNS
> server, or spoof one, and change both IP and KEY to one of his own
> servers and vpn daemons. The only way to make sure you get the right KEY
> is to have the DNS replies signed. You can do that with DNSSEC for
> instance. But, in order to verify the reply you get you'd need yet another
> public key.
> 
> There is just no way to make sure the other end is who he is if you
> don't have a public or shared private key IN ADVANCE.
> 
> 
>> - Dynamic on-demand default tunnels using discovered Keys
>>
>>Send all data out via the TUN, except data that's already encapsulated.  If 
>>a tunnel cannot be established, then send it in the clear.  Otherwise, set 
>>up tunnel and shoot data.
> 
> 
> Hmz... very hard to do, because in addition to accessing the TUN device,
> which is relatively easy, you must send the "clear" packets out via the
> real interfaces, which means using operating system dependent hooks.
> Furthermore, there are serious security implications even when just
> sending the first few packets in the clear. Why bother to encrypt the
> rest at all then?

First off, I guess I should have polished it up a bit.  Foolish me for 
thinking that people wouldn't run away with the weak case and try to attack 
on the strongest case.

Back up a bit.

Note there, above, that I'm proposing a system that encrypts some, not all, 
packets.  Consider that I'm suggesting that the machine decide what's 
encrypted and what's not.  For what kind of security are you hoping? 
You're attacking it like you'd want to use such a scheme to transmit your 
plans for world domination, a plan that apparently involves beating each 
government head over their head with your Masters Degree in Mathematics, 
Cryptography minor.

Stop that.  It makes a noise over which it is difficult to speak.

Should I have mentioned explicitly that I was not thinking of active 
attacks, and only about passive attacks?  Sorry, bad me.  In this day and 
age of hijacked security vans, code-talking navajo and CSIS documents 
negligently left behind in a car (and the quiet lockdown of a hockey arena 
it caused), what manner of perfect key exchange, outside military 
procedure, are you intending to use?  Exactly when do *you* exchange your 
keys?

May I put down my rifle so I can install cipher Blue-5-helix-London?  I'm 
in the lead-lined room, it's dark, and don't think I'm being observed.

Hey, look.  Opportunistic encryption is not meant as something upon one 
relies;  it's meant to introduce maintenance-free, light privacy into a 
gateway, perhaps, something for which an IT group needs not budget extra 
manpower to set up and manage, and it's meant to deter casual eavesdroppers.

Why did people toss their PGP fingerprints in USENET posts?  isn't that 
entirely untrustworthy, a procedure full of holes and exploits and 
therefore pointless?

http://it.jamida.com.au/phoenix/faq.shtml
http://www.usenix.org/events/lisa99/full_papers/bentley/bentley.pdf
http://www.freeswan.org/freeswan_trees/freeswan-1.94/doc/intro.html#goals

Then again, maybe Opportunistic Encryption is a pointless effort that's 
been swimming upstream for too long:
http://www.ukuug.org/newsletter/61/ne...@uk...



  - bish
-- 
	Excellent... rime ice, a summit ridge, small trees blanketed in
	snow and ice like legions of twisted killer mutant deranged snow
	goons.			-- Erick DeOliveira 20020208
  	 
		   Describing his first Winter Ascent

Re: [Openvpn-users] Interaction with Windows VPN Server/Client

[bishop <bi...@pl...>]

Theepan wrote:
> Hello,
> 
> Can OpenVPN for Linux connect to a Windows NT/2000 VPN Server, and vice
> versa - can a Windows VPN Client connect to OpenVPN?

OpenVPN uses the Linux TunTap driver, version 1.1 for kernel 2.2 and 
version 1.4 delivered with kernel 2.4 .

The TUN interface has not been delivered for Windows.  There is an effort, 
and the vtun-users or vtun-devel list tracks the progress.  Go search.

The TUN device is a sub-project or co-project of the VTun project, which is 
why it uses the same lists.

> If so, can anyone mention any VPN clients (or servers), that is compatible
> with OpenVPN?

As above may imply, no.

> Thanks in advance,
> 
> 
> --
> Theepan
> 
> 
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


-- 
	Excellent... rime ice, a summit ridge, small trees blanketed in
	snow and ice like legions of twisted killer mutant deranged snow
	goons.			-- Erick DeOliveira 20020208
  	 
		   Describing his first Winter Ascent

Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[Guus S. <gu...@sl...>]

On Sun, Mar 31, 2002 at 06:09:54AM -0500, bishop wrote:

>  - public-key encryption based on KEY records in DNS
>=20
> Hit the DNS, get the key, now you don't have to store it any place, and y=
ou=20
> can discover it.  If you can think of an easier way to discover a KEY, th=
en=20
> I'm all ears.

Really, that is not very secure. Somebody could take over the DNS
server, or spoof one, and change both IP and KEY to one of his own
servers and vpn daemons. The only way to make sure you get the right KEY
is to have the DNS replies signed. You can do that with DNSSEC for
instance. But, in order to verify the reply you get you'd need yet another
public key.

There is just no way to make sure the other end is who he is if you
don't have a public or shared private key IN ADVANCE.

>  - Dynamic on-demand default tunnels using discovered Keys
>=20
> Send all data out via the TUN, except data that's already encapsulated.  =
If=20
> a tunnel cannot be established, then send it in the clear.  Otherwise, se=
t=20
> up tunnel and shoot data.

Hmz... very hard to do, because in addition to accessing the TUN device,
which is relatively easy, you must send the "clear" packets out via the
real interfaces, which means using operating system dependent hooks.
Furthermore, there are serious security implications even when just
sending the first few packets in the clear. Why bother to encrypt the
rest at all then?

--=20
Met vriendelijke groet / with kind regards,
  Guus Sliepen <gu...@sl...>

[Openvpn-users] Interaction with Windows VPN Server/Client

[Theepan <to...@li...>]

Hello,

Can OpenVPN for Linux connect to a Windows NT/2000 VPN Server, and vice
versa - can a Windows VPN Client connect to OpenVPN?

If so, can anyone mention any VPN clients (or servers), that is compatible
with OpenVPN?

Thanks in advance,


--
Theepan

[Openvpn-users] Features that should be in OpenVPN or VTun

[bishop <bi...@pl...>]

  - public-key encryption based on KEY records in DNS

Hit the DNS, get the key, now you don't have to store it any place, and you 
can discover it.  If you can think of an easier way to discover a KEY, then 
I'm all ears.

  - on-demand connections.

Keep the IFaces up all the time.  Route data to it, and connect the actual 
TUNs with the high-water mark is reached.

  - Dynamic on-demand default tunnels using discovered Keys

Send all data out via the TUN, except data that's already encapsulated.  If 
a tunnel cannot be established, then send it in the clear.  Otherwise, set 
up tunnel and shoot data.

-- 
	Excellent... rime ice, a summit ridge, small trees blanketed in
	snow and ice like legions of twisted killer mutant deranged snow
	goons.			-- Erick DeOliveira 20020208
  	 
		   Describing his first Winter Ascent