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