openvpn-users

[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

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...>

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...tml



  - 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] 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 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

[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] 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
>