Can some people who are smarter than me give us the flags we would like to compile this with manually?
The Heartbleed Bug
21–30 of 547 posts
Re: The Heartbleed Bug
#22How widely implemented is certificate revocation?
Re: The Heartbleed Bug
#23Are people going straight to buying new domain names for every TLS bug discovered these days?
I'd be surprised if heartbleed.com was still available in 2014
Re: The Heartbleed Bug
#24Does SSH (specifically sshd) on major OSes use affected versions of OpenSSL? [answer pulled up from replies below: since sshd doesn't use TLS protocol, it isn't affected by this bug, even if it does use affected OpenSSL versions] What's the quickest check to see if sshd, or any other listening process, is vulnerable? (For example, if "lsof | grep ssl" only shows 0.9.8-ish version numbers, is that a good sign?)
The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn't exposed in applications that just use TLS for crypto primitives.
Re: The Heartbleed Bug
#25I don't quite understand how this bug works. I would appreciate any input from someone knowledgeable.
It sounds like the heartbeat code is sending some data in the handshake. That data should be harmless (padding? zeroes?) but the bug results in reading off the end of an array and from whatever other data happens to be there. Someone sniffing the connection can then see those bytes fly by. If they happened to contain private info, game over.
Is that a correct read on the situation? If so, my followup questions are: 1) Why is there any extra data being sent at all beyond a simple command to "heartbeat"? 2) How much data is being leaked here and at what rate? Is it a byte every couple of hours, is it kilobytes per minute, or what?
I am particularly interested in #1, since that's the part I really don't get at the moment. I suspect the answer to #2 will be implied by the answer to #1.
Re: The Heartbleed Bug
#26Does SSH (specifically sshd) on major OSes use affected versions of OpenSSL? [answer pulled up from replies below: since sshd doesn't use TLS protocol, it isn't affected by this bug, even if it does use affected OpenSSL versions] What's the quickest check to see if sshd, or any other listening process, is vulnerable? (For example, if "lsof | grep ssl" only shows 0.9.8-ish version numbers, is that a good sign?)
The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn't exposed in applications that just use TLS for crypto primitives.
Does sshd only use TLS/OpenSSL "for crypto primitives"? Or not use OpenSSL at all?
Re: The Heartbleed Bug
#27Does SSH (specifically sshd) on major OSes use affected versions of OpenSSL? [answer pulled up from replies below: since sshd doesn't use TLS protocol, it isn't affected by this bug, even if it does use affected OpenSSL versions] What's the quickest check to see if sshd, or any other listening process, is vulnerable? (For example, if "lsof | grep ssl" only shows 0.9.8-ish version numbers, is that a good sign?)
The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn't exposed in applications that just use TLS for crypto primitives.
Sooo in layman's terms - we only need to be worrying about HTTPS and not SSH ?
Re: The Heartbleed Bug
#28> Recovery from this bug could benefit if the new version of the OpenSSL would both fix the bug and disable heartbeat temporarily until some future version... If only vulnerable versions of OpenSSL would continue to respond to the heartbeat for next few months then large scale coordinated response to reach owners of vulnerable services would become more feasible.
This sounds risky to me. I'm afraid attackers would benefit more from this decision than coordinated do-gooders.
Re: The Heartbleed Bug
#29Great writeup but I guess I'm still a bit confused. As someone responsible for rails servers I can see that I need to update nginx and openssl as soon as packages become available or compile myself. What about keys though? Do I need to get our SSL certs re-issued? regenerate SSH keys? Anything else that I should be doing?
If you're running a vulnerable version of OpenSSL and want to be truly careful, assume your private keys (not just certs) are already compromised. Once new packages are available, you need to update and then re-roll your crypto.
Also, if you're using those keys to protect other secrets like passwords - say, DB credentials or AWS keys stored in an HTTP-hosted Git repo behind - you can't really assume those are safe either.
Fun times!
Re: The Heartbleed Bug
#30What a great writeup. Comprehensive without being overly verbose, answers to "what does this mean?" and "does this affect me?", and clear calls to action. While I'm not happy at having to spend my Monday patching a kajillion machines, I welcome more vulnerability writeups in this vein.
Writeup was too long. We need to know the short and sweet of what to fix.