[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
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>
> > 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
> > 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
> > mid-session source IP/port change without a full renegotiation.  I will
> > 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

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


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


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



Openvpn-users mailing list