As you may know, OpenVPN is vulnerable to the heartbleed attack. However, I can't find any guide online on how to fix it. The only source I've found is this:


Is just doing (in Ubuntu)

apt-get update; apt-get upgrade; apt-get dist-upgrade

enough to make sure that my OpenVPN is safe? I can confirm i have this version of openSSL:

# dpkg-query -l 'openssl'
ii  openssl                                   1.0.1-4ubuntu5.12                         Secure Socket Layer (SSL) binary and related cryptographic tools


  • 1
    No, as stated in the wiki article, you also have to rekey everything. – Michael Hampton Apr 25 '14 at 3:14
  • Yes, I'm aware of that. I'm talking about the exploit itself (i.e. making sure OpenVPN doesn't use a bad openSSL) – Jonny Apr 25 '14 at 3:22
  • You updated OpenSSL, and restarted all affected services, didn't you? – Michael Hampton Apr 25 '14 at 3:22
  • 2
    aptitude changelog openssl | grep -B10 CVE-2014-0160. OK, fixed? Now run ldd $(which openvpn) to see which libraries openvpn is using. – MikeyB Apr 25 '14 at 3:46
  • Please do not edit commentary into your post. If you have an issue with post closure in the future open a discussion on Meta. – voretaq7 Apr 25 '14 at 3:59

Let's follow the trail! What does openvpn use?

$ ldd $(which openvpn)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f464d630000)

OK, it's using libssl.1.0.0 provided by...?

$ dpkg -S /lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl1.0.0:amd64: /lib/x86_64-linux-gnu/libssl.so.1.0.0

... provided by libssl1.0.0:

$ apt-get changelog libssl1.0.0 | grep -B10 CVE-2014-0160

openssl (1.0.1-4ubuntu5.12) precise-security; urgency=medium

  * SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
    - debian/patches/CVE-2014-0076.patch: add and use constant time swap in
      crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
    - CVE-2014-0076
  * SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160

Looks good to me.


Or execute openssl version -a and make sure the build date is April 7th, 2014 or later for affected versions.

  • That's not a great solution, because I can compile a vulnerable SSL version today, and versions prior to 1.0.1 weren't vulnerable either. So this may be better than nothing, but just barely. – HopelessN00b Apr 25 '14 at 4:48
  • Good point, this is not a thorough enough solution. – xeon Apr 25 '14 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.