Tag Info

Hot answers tagged

55

Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there. Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012. So, I'm going to go ahead and assert that openssl version -a is the proper, cross-distro way to display the full version of OpenSSL that's installed on ...


38

Any service that uses OpenSSL for its TLS implementation is potentially vulnerable; this is a weakness in the underlying cyrptography library, not in how it's presented via a web server or email server package. You should consider all linked services vulnerable to data leakage at least. As I'm sure you're aware, it's quite possible to chain attacks ...


34

It seems your ssh-keys are safe: It's worth pointing out that OpenSSH is not affected by the OpenSSL bug. While OpenSSH does use openssl for some key-generation functions, it does not use the TLS protocol (and in particular the TLS heartbeat extension that heartbleed attacks). So there is no need to worry about SSH being compromised, though it is still a ...


32

Ubuntu 12.04, 12.10, and 13.10 Ubuntu has issued USN-2165-1, which states that updated packages are now available in the archives. Run the following two commands to grab the fix. sudo apt-get update sudo apt-get upgrade Ubuntu 14.04 I have uploaded a Debian package containing the new release (1.0.1g) to a PPA I have set up for this purpose. These three ...


28

Update 09/04/2014 1:00AM EST Amazon has stated that all Elastic Load Balancers have been updated and are now longer vulnerable. They recommend rotating certs as well. Update 08/04/2014 2:56PM CST Amazon has stated that all Elastic Load Balancers except those in US-EAST-1 have been updated, and the vast majority of those in US-EAST-1 have been updated. ...


21

Ensure that the libssl1.0.0 package has been updated as well (that package contains the actual library, the openssl package contains the tools) and that all services using the library have been restarted after the upgrade. You have to RESTART all services using openssl (service apache restart).


16

A certificate isn't vulnerable, or otherwise, to heartbleed. A certificate is just a certificate. There have been crypto issues in the past, particularly with respect to the RNG of choice, that caused weak keys (and thus vulnerable certificates) to be created, but heartbleed isn't a vulnerability of that type. A key/certificate pair can have been ...


14

RedHat 6.5 and CentOS 6.5 These are vulnerable. RedHat's erratum RHSA-2014-0376 says there are patched libraries available, and anyone affected should upgrade at the earliest opportunity. At the time of writing, CentOS did not yet have a fixed version, but Karanbir Singh's posting to CentOS-announce says that they've produced an updated version of openssl ...


13

Debian Wheezy Debian has issed DSA-2896-1 and patched libraries are available here. A shell script is available here. 1. Patch Apt-get repository was updated so now patched libraries are available via apt-get update && apt-get upgrade wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb wget ...


13

Well, for starters You SHOULD NOT be using a snakeoil cert. In order to properly mitigate the heartbleed attack you MUST REVOKE the potentially compromised certificates, which you generally can't do with snakeoil or other self-signed certs. If you can't afford real Certificate Authority issued certificates (or you're working in a private environment) you ...


11

Unfortunately, I'm not sure there is a cross-platform way of doing this. As I discuss in a blog posting, the version of OpenSSL displayed on Ubuntu 12.04 REMAINS 1.0.1 after upgrading to a fixed version. For Ubuntu 12.04 ONLY, you can tell if you've been updated if all of the below are true: dpkg -s openssl | grep Version shows version 1.0.1-4ubuntu5.12 ...


11

Your understanding is correct. All other things being equal, it doesn't matter; but there are wrinkles. One advantage to generating them on the server in question is it minimises the chance of the key being compromised in transit. As long as you use a secure machine to generate them, and a secure method (immune to MITM attacks) to move them to the server, ...


10

If you want something truly cross-platform, check for the vulnerability itself rather than relying on version numbers. You might have code that reports a version number that is known to be vulnerable, but the actual code is not vulnerable. Many vendors who bundle open-source products like OpenSSL and OpenSSH will selectively retrofit urgent fixes to an ...


9

I'd like to point out that private keys are not the only assets that should be considered compromised. The bug has the potential to leak any memory running in the same address space (i.e., the same process) as OpenSSL. Therefore, if you are running a server process where a vulnerable version of OpenSSL is statically or dynamically linked, any piece of ...


8

FreeBSD 10.0 or openssl from ports The FreeBSD security team has issued an advisory regarding CVE-2014-0160 (aka "Heartbleed") and : FreeBSD-SA-14:06.openssl Updating FreeBSD Updating FreeBSD via a binary patch Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update ...


8

It somewhat matters. If you generate them on an another machine, the keys are vulnerable on the generating machine, and then on the server. If you use an infected machine to generate them, some virii might steal the keys, even before they are moved to the secure server. If you generate them on a secure server, and just move the CSR/cert around, the ...


8

As a general rule when mitigating a major vulnerability in a library which is used by many programs: rebooting your server is the easiest way to ensure you've restarted every affected program, and that nothing is using the old (vulnerable) code. You should not fear rebooting your systems (you should be doing it pretty regularly when you install patches ...


8

You can't do this, but there is no reason to. Unless you, for some strange reason, also used the CA certificate and key as an actual service-authorising certificate, on a machine exposed to the internet, on a service that supported TLS, it is not likely to have been compromised. You will notice that, in the mad flurry of updates post-heartbleed, one thing ...


7

No, you do not need to bother to update them. It is true that now that heartbleed bug (possibly) has exposed your private key, any third party on network path in between your users and your server ("man in the middle") can see all data as is it was not encrypted. However, for snakeoil certs, that does not differ much from regular usage case of ...


6

You could try: openssl s_client -connect domain.com:443 -tlsextdebug 2>&1 | grep 'server extension "heartbeat" (id=15)' || echo safe From https://devcentral.f5.com/questions/openssl-and-heart-bleed-vuln


5

Assuming that you (or clients, users, etc) have ever passed, or will pass, sensitive information over SSL, yes. Passwords, anything else that you wanted encrypted because you didn't want it in plaintext. Yes. If you truly don't care if those things are potentially in the wild as plaintext, then don't. If you do care, don't forget to change your private key ...


5

The point of the re-keying exercise is to make a new private/public key pair. The key.pem file referenced in that command is your new private key. You can create it with the openssl genrsa 2048 > newkey.pem command. You'll probably want to substitute the modulus (key size) you're currently using rather than just blindly using 2048. You can get the ...


5

With some providers of SSL certificates (Digicert as one) you can generate new private keys and CSRs to request certificates on each server. This allows you to maintain separate private keys (and also generate these certificates for subdomains using Subject Alternative Names.). This does increase the administrative burden, but decreases the risk of sharing a ...


5

The machine wants files like this. If you open the certificate you will see that the numbers match the hash provided within the certificate. This is so that the canonical hash of the certificate matches the name of the file. Remember: A certificate may contain multiple hostnames and aliaes, but it has only one hash. 50a694ac.0 5170a0d9.0 But me? I'm a ...


4

There are 2 possibilities: 1) Your compiled version of Apache uses a compiled version of OpenSSL from another location. Just use ldd on the binary of Apache and it shall tell you what OpenSSL shared library it used: # ldd /usr/sbin/nginx | grep -i ssl libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003816000000) If this gives you not output, then ...


3

Due to the nature of the heartbleed attack, there is no way to verify that your system has been compromised. Because of this reason, all System and network administrators are encouraged to assume you have been compromised. To recover, first you need to update your openssl version to the latest fix published (this varies depending on your system, for example ...


3

Your version of tar appears to be trying to write to the tape device by default, rather than standard output. It appears to be GNU tar. Autodetecting the tape drive was the default before version 1.11.5 of GNU tar and I suspect you have such an old version. Versions of tar on other UNIX systems may also attempt to write to the tape device by default. Force ...


3

I found it next to impossible to determine the versions of SSL in use on several of the appliances I work with. Although it's technically not mitigation being able to ID currently vulnerable hosts was at the top of my list. I put together a small VM that will perform checks against arbitrary hosts and ports using FiloSottile's test module. On preliminary ...


3

Yes those services can be compromised if they rely on OpenSSL OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. For a more detailed write up on the vulnerabilities, affected operating ...


3

There is a perl script that allows you to check our own services. There are also online tools. One more.



Only top voted, non community-wiki answers of a minimum length are eligible