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