It might be possible for an openvpn server to initiate a heartbeat sequence with a client. And therefore for a rogue server to exploit this. I don't believe this to be the case however and I can't think of any other way of exploiting this.
If you can get openvpn to use named sockets, you should be able to easily test this with existing scripts. On Apr 14, 2014 3:24 AM, "Alan Murrell" <li...@murrell.ca> wrote: > Hello All, > > I am not entirely sure if this is right place to ask, but I thought I > would start here. > > We have a client who has several dozen remote locations all connected to > the head office via OpenVPN tunnels. OpenVPN is form the Debian packages. > > The version of OpenSSL on the head office firewall running the OpenVPN > server is a non-vulnerable version (it runs Debian 6.0.2, which has OpenSSL > 0.9.8 installed). However, the remote locations are mix of Debian 6 and > Debian 7 installations (the Debian 6 would not have a vulnerable version of > OpenSSL, while the Debian 7 ones would, and can be "patched" by running > 'apt-get update && apt-get upgrade' to install a patched version of OpenSSL) > > My question sis this, really: while it is understood that the systems > running the vulnerable versions of OpenSSL should be updated (and in fact > are in process of doing just that), is there really any immediate danger of > information being leaked from those tunnels? > > The certificate were all generated on the head office firewall running the > OpenVPN server, and all the clients are making their connections to that > non-vulnerable server (as far as Heartbleed goes, anyway), so are the > tunnels themselves in fact in any danger of compromisation, even if the > "clients" are running a vulnerable version of OpenSSL? > > I guess I am wondering if *all* those SSL tickets need to be revoked and > re-generated (I know it is likely best-practice to do so, but is it likely > necessary? It should likely be done anyway, but is there any immediacy > about it that has to be done?) > > Thanks for your input. > > A. > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.orgwith a > subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20140414001250. > 60861ub65uhaw0w0@imap.murrell-van.local > >
