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

Re: [Openvpn-users] openvpn -vs- masquerading


  • Subject: Re: [Openvpn-users] openvpn -vs- masquerading
  • From: "James Yonan" <jim@xxxxxxxx>
  • Date: Fri, 26 Jul 2002 15:05:06 -0600

> In 070801c234d5$c4c52cd0$1000000a@mocha, "James Yonan" <jim@xxxxxxxx>
wrote:
>
> > Right now the only way to make this work with SSL/TLS mode would be to
> > use --ping and --ping-restart to force a timeout and renegotiate the
SSL/TLS
> > session.  That is because SSL/TLS mode will not accept a source IP/port
> > change without a new SSL/TLS key negotiation.
>
>   Urgh.  I'll see if I can figure out which end needs the ping-restart.
>
> > You raise a good point, it would be useful if SSL/TLS mode could handle
a
> > mid-session source IP/port change without a full renegotiation.  I will
look
> > into ways of doing this that are secure.
>
>   Well, actually, I'll condone a full renegotiation.  I just wish it
> would detect "hey, my stupid peer just changed port numbers.  I
> should tell him to negotiate some new keys".

That may be the way to go, but it's tricky because you want to protect
against a DoS attack that would exploit an explicit renegotiation
capability.

>   If you have time, could you outline the attack scenario the current
> operating mode is designed to repel?  I have a vague feeling it's
> either not dangerous, or there are easier attacks that are more
> dangerous/effective.  There's probably some ankle-biting monster in
> there that I hadn't thought to fear.

SSL/TLS mode requires a multi-packet handshake in order to authenticate.
Between the reception of the initial packet and the final proof of
authentication, SSL/TLS is vulnerable to DoS attacks.  OpenVPN adds
the --tls-auth option to protect this pre-authenticated exchange, but its
use is optional, and therefore OpenVPN tries to secure as much as possible
the non --tls-auth case.

If an attacker had read access to an SSL/TLS session that is in the process
of authentication but has not yet authenticated, he could throw a wrench
into the machinery by sending corrupted packets to either of the SSL/TLS
peers which would cause the authentication to fail.  If an attacker had
enough information about IP address and ports being used, he might even be
able to stage a DoS attack without read access to the link, but at least
forcing IP address/port consistency during an SSL/TLS session makes such an
attack more difficult.

>   For something completely different:
>
> You're going to transmit a digest to make it evident when someone has
> tampered with the packet.
>
> If you had a choice between
> a) computing a digest of the plaintext
> b) computing a digest of the ciphertext
> which one would be "better"? and list the "goodness" metrics.

The current research seems to indicate that encrypt-then-authenticate (b) is
the more secure choice, and this is the method employed by OpenVPN.

For more info, see this paper by Hugo Krawczyk.

http://eprint.iacr.org/2001/045/

See also Sheffer and Krawczyk's IETF draft on the working group
"IP Secure Remote Access":

http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-05.txt

And here's a paper that outlines an ssh exploit due to ssh's use of (a)
above:

http://openvpn.sourceforge.net/papers/ssh-security.pdf

James



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users