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.
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.
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.
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?
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 :).
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.
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.
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 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?
36 comments
[ 3.0 ms ] story [ 175 ms ] thread* Live version: http://filippo.io/Heartbleed/
* Code: https://github.com/FiloSottile/Heartbleed
OpenSSL 1.0.1e-fips
One came up positive, One negative. Shouldn't it be negative for both?
0 - https://github.com/FiloSottile/Heartbleed
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.
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 $
Heh. Eliding the hex values of the password might have been a good idea.
https://www.ssllabs.com/ssltest/index.html
$ ./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.
http://filippo.io/Heartbleed/#trustcenter.websecurity.symant...
It's vulnerable as well.
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?
(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)
Has anyone a link to test client implementations? (E.g Browsers,... Windows,... Android, Apps, etc)
Other OpenSSL-using clients are definitely vulnerable though - best bet to tell if you're vulnerable is to check the OpenSSL version.
I tested it using openssl's s_server (with a quickly generated cert using tinyca) and then connecting to https://localhost:12345