[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: Bob <thoth@xxxxxxxxxxxxxx>
  • Date: Fri, 26 Jul 2002 15:16:05 -0400

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

  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.




  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.

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