I'll clarify my thoughts. > Am 08.04.2014 15:13, schrieb Joe Patterson: >> I think that what's being referred to here is that a VPN service with >> multiple independent clients could have one nefarious client who used >> a valid client key/cert to establish a session, then used that session >> plus this vulnerability to compromise the server's private key, plus >> usernames, passwords, and session keys of other clients of that VPN >> service. > But I think this only holds if the ***Server*** openssl library is still > vulnerable. The client never gets the server's private key, so it cannot > be proliferated in this way. Naturally we all need to update the servers > ASAP, but can we continue to use clients with old openssl DLL's? > > JC
Correct. The server's private key can only be extracted if the server side is vulnerable. The point I made about the tls-auth directive is that there are a lot of consumer VPN services (for censorship circumvention, anonymous IP, etc) that use tls-auth, but use the same tls-auth key with all customers. Since it's trivial to become a customer and gain access to the tls-auth key it provides no extra protection. Regarding the client side, in a high security environment you should consider all client credentials leaked as well. According to the RFC the TLS heartbeat extension can be used for both client and server. If the tunnel uses UDP and your adversary can eavesdrop on and spoof packets they can send you a heartbeat request and sniff the network for your response (with the leaked memory). On Tue, Apr 8, 2014 at 3:54 PM, Joe Patterson <j.m.patter...@gmail.com> wrote: > Very true. I mean, a malicious server could compromise clients, but I was > thinking more along the lines of malicious clients compromising servers, > which would require the server to be un-patched. If you run a server, > definitely patch. If you're a client, patch anyway, for reasons beyond > openvpn. But the frustrating thing here is that, as a client, it's hard to > be certain that the server you are connecting to has been patched, or even > if it has been, that its key was not compromised before it was patched. I'd say for most server admins the assumption should be that the private key, usernames, passwords etc has leaked. The only way to prevent a MITM using that private key is to revoke the server certificate, in which case a CRL (Certificate Revocation List) has to be distributed to all clients connecting to the server. Most clients don't seem to have such a feature, so it would have to be done manually. In which case you'd certainly notice. In our case we're revoking all server certificates and releasing a new client with the CRL bundled. Of course it'll also contain a safe OpenSSL version. // Fredrik P.S. In addition to this list I also contacted Jonathan Bullard (Tunnelblick dev), but he had already acted after reading my response to Yonan. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
