The one posted in a previous thread is significantly more clarifying. It features a web server and a command line version:

* Live version: http://filippo.io/Heartbleed/

* Code: https://github.com/FiloSottile/Heartbleed

We have the same version of OpenSSL on 2 different test nodes.

OpenSSL 1.0.1e-fips

One came up positive, One negative. Shouldn't it be negative for both?

Weird. Can you try "openssl version -a" on both? Like this:

  $ openssl version -a
  OpenSSL 1.0.1 14 Mar 2012
  built on: Mon Apr  7 20:33:29 UTC 2014
  platform: debian-amd64
  options:  bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx)
  compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
  -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4
  -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 
  -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,
  --noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 
  -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
  -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM 
  -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
  OPENSSLDIR: "/usr/lib/ssl"

In any case, it could be that something else (not built with OpenSSL) is listening on port 443 in the one that's "safe".

I think it's also possible you are getting a false positive, because it's timing out or whatever. The newer version of that check tells you if it's timing out.

Tried again. Still get the same result.

Different build flags? Might one of them have been built with -DOPENSSL_NO_HEARTBEATS?

Did you "service httpd restart" after applying the update?

I'm surprised that I haven't been contacted by any sites yet with advice to reset my password. Is it the case that not many sites were actually running 1.0.1? Or are they just patching, creating new certs, and calling it a day?

I may be wrong, but I think that your credentials with a site are only vulnerable if they had the heartbeats extension turned on.

As for re-issuing certs Namecheap is sucking in that department last night and today (it could be upstream with RapidSSL and PositiveSSL). GoDaddy seems to be speedy even though it looks like the notification emails are not being sent. Fun times :).

It appears so. Many sites that were vulnerable earlier today haven't even inactivated sessions.

I got contacted by Heroku 1h ago to reissue certificate and update my SSL endpoint.

Tools like this and FiloSottile's[0] are great. But given how serious of a vulnerability this is, anything short of manually verifying your OpenSSL version is probably not enough.

0 - https://github.com/FiloSottile/Heartbleed

True, but it's extremely useful when you're terminating SSL on Amazon's Elastic Load Balancer and want to know if they've fixed it yet or not.

Or, another example, when you want to know for sure that you've restarted your webserver and you weren't doing something stupid like running a version of nginx that was statically linked against openssl.

How about Symantec? Those of you logging in to renew Verisign certificates might want to take note:

http://filippo.io/Heartbleed/#trustcenter.websecurity.symant...

It's vulnerable as well.

And this is what really makes me mad:

$ ./heartbleeder yahoo.com

VULNERABLE - yahoo.com:443 has the heartbeat extension enabled and is vulnerable to CVE-2014-0160

I can understand when some random service has vulnerability like this. But big corporations like yahoo should resolve this immediately.

But isn't it because they're big & complex that it's more difficult to quickly resolve ... on the other hand, since they're so big & important (and have the means) they should have plans in place already to deal with such things.

I see a funny thing when I test it against yahoo.com:

  $ ./Heartbleed yahoo.com:443
  (bunch of returned bytes)
  2014/04/08 12:59:46 yahoo.com:443 - VULNERABLE

Near the front of the returned bytes is the sequence "yheartbleed.filippo.ioYELLOW SUBMARINE". That is some padding buried inside the Heartbleed source code.

I assume that the returned bytes are a peek inside the memory of a yahoo.com server, and we can see the padding supplied by Heartbleed, followed by some more bytes that depend on the server state.

Am I interpreting that correctly?

Interestingly, I just got that for HackerNews, but not on a second try. I thought they were using CloudFlare anyway?

(And yes, you interpreted that correctly. Notice that this online test does not request even a fraction of the 64k possible, and you can always repeat it to get more)

The Qualys SSL Lab server test is also checking for Heartbleed now:

https://www.ssllabs.com/ssltest/index.html

The bug also leaves the client vulnerable.

Has anyone a link to test client implementations? (E.g Browsers,... Windows,... Android, Apps, etc)

The vulnerability is in OpenSSL only, and no major browser uses OpenSSL. Firefox and Chromium use NSS, IE uses a Microsoft library, and Safari uses Apple's SecureTransport.

Other OpenSSL-using clients are definitely vulnerable though - best bet to tell if you're vulnerable is to check the OpenSSL version.

What about Opera 12, still major browser in CIS countries? OpenSSL license is listed on opera:about page, but version is not specified. How to find out?

Opera 12 should be safe, as it doesn't support the heartbeat extension

I tested it using openssl's s_server (with a quickly generated cert using tinyca) and then connecting to https://localhost:12345

  openssl s_server -accept 12345 -tlsextdebug -cert cert.pem | grep ^TLS
  TLS client extension "server name" (id=0), len=14  
  TLS client extension "renegotiation info" (id=65281), len=1  
  TLS client extension "status request" (id=5), len=5  
  TLS client extension "next protocol" (id=13172), len=0

Here it is: https://reverseheartbleed.com/

Yahoo mail appears to be vulnerable

Well, Here we go... https://twitter.com/WarrenGuy/status/453510021930680320

pikachu@BATTLEGYM ~/heartbleeder $ date

Tue Apr 8 08:37:08 PDT 2014

pikachu@BATTLEGYM ~/heartbleeder $ ./heartbleeder mail.yahoo.com

INSECURE - mail.yahoo.com:443 has the heartbeat extension enabled and is vulnerable

pikachu@BATTLEGYM ~/heartbleeder $

> https://twitter.com/WarrenGuy/status/453510021930680320

Heh. Eliding the hex values of the password might have been a good idea.

An online tester: http://possible.lv/tools/hb/

Does heartbleed affect ssh or only TLS?

This does not impact SSH, see http://heartbleed.com/

There is no information about SSH on this page. OpenSSH is a program depending on OpenSSL the library, specifically OpenSSH uses the libcrypto part of OpenSSL. So after updating OpenSSL ssh service should be restarted anyway.

ssh doesn't need to be restarted. As you said, OpenSSH never uses the vulnerable part of OpenSSL code. When the ssh service was started, libcrypto (which isn't vulnerable) was loaded into memory and made available to OpenSSH code. That memory isn't going to be invalidated if libcrypto's on-disk copy changes.

Oh, this time, the (free)ssl cert provider(s) is/are vulnerable!