41–50 of 547 posts
Earlier quoted context omitted.
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?
[deleted]
It could have implications for Bitcoin web services that use HTTPS, of course.
I 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…
A couple more data points: I'm running Fedora 19 and Arch on my main dev machines/VMs and as of this posting are considered up-to-date. Both are vulnerable: [Fedora19] $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [Arch] $ openssl version OpenSSL 1.0.1f 6 Jan 2014
It does take time for these things to be tested and deployed. Regardless of severity of bug, distributions must test packages before sending them out to all their users. It would be unfortunate if a new package were to be released immediately only to be soon masked/recalled due to unforeseen consequences. Of note, the Gentoo package was bumped approximately 2 hours after the advisory was published.
I 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…
Can attacker access only 64k of the memory? There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.
...so I guess the answer to 2 is only limited by how frequently you can change the heartbeat settings, and how frequently OpenSSL will send a heartbeat packet.
Does anyone know how Amazon's Elastic Load Balancers are affected? I can't find anything on the AWS site
Edit: I've posted on the support forum, hopefully they get back to us https://forums.aws.amazon.com/thread.jspa?threadID=149690
This thing has been in the wild for two years. What are the odds it hasn't been systematically abused? And what does this imply? To me it sounds kind of like finding out the fence in your backyard was cut open two years ago. Except in this case the backyard is two thirds of the internet.
So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.
If i got that right ALL openssl private keys are now potentially compromised.
I hope vendors push fixes soon, and then I guess I'm busy for a few days regenerating private keys.
Any chance this bug originated with the NSA? It seems like it would fall under their goal of subverting the infrastructure that keeps secrets on the internet. Of course this is exactly why such a goal is a bad idea - an unprotected internet causes widespread damage.