
The Heartbleed Bug - tptacek
http://heartbleed.com/
======
yaakov34
There was a discussion here a few years ago
([https://news.ycombinator.com/item?id=2686580](https://news.ycombinator.com/item?id=2686580))
about memory vulnerabilities in C. Some people tried to argue back then that
various protections offered by modern OSs and runtimes, such as address space
randomization, and the availability of tools like Valgrind for finding memory
access bugs, mitigates this. I really recommend re-reading that discussion.

My opinion, then and now, is that C and other languages without memory checks
are unsuitable for writing secure code. Plainly unsuitable. They need to be
restricted to writing a small core system, preferably small enough that it can
be checked using formal (proof-based) methods, and all the rest, including all
application logic, should be written using managed code (such as C#, Java, or
whatever - I have no preference).

This vulnerability is the result of yet another missing bound check. It wasn't
discovered by Valgrind or some such tool, since it is not normally triggered -
it needs to be triggered maliciously or by a testing protocol which is smart
enough to look for it (a very difficult thing to do, as I explained on the
original thread).

The fact is that no programmer is good enough to write code which is free from
such vulnerabilities. Programmers are, after all, trained and skilled in
following the logic of their program. But in languages without bounds checks,
that logic can fall away as the computer starts reading or executing raw
memory, which is no longer connected to specific variables or lines of code in
your program. All non-bounds-checked languages expose multiple levels of the
computer to the program, and you are kidding yourself if you think you can
handle this better than the OpenSSL team.

We can't end all bugs in software, but we can plug this seemingly endless
source of bugs which has been affecting the Internet since the Morris worm. It
has now cost us a two-year window in which 70% of our internet traffic was
potentially exposed. It will cost us more before we manage to end it.

~~~
pbsd
This sort of argument is becoming something of a fashion statement amongst
some security people. It's not a strictly wrong argument: writing code in
languages that make screwing up easy will invariably result in screwups.

But it's a disingenuous one. It ignores the realities of systems. The reality
is that there is currently no widely available memory-safe language that is
usable for something like OpenSSL. .NET and Java (and all the languages
running on top of them) are not an option, as they are not everywhere and/or
are not callable from other languages. Go could be a good candidate, but
without proper dynamic linking it cannot serve as a library callable from
other languages either. Rust has a lot of promise, but even now it keeps
changing every other week, so it will be years before it can even be
considered for something like this.

Additionally, although the parsing portions of OpenSSL need not deal with the
hardware directly, the crypto portions do. So your memory-safe language needs
some first-class escape hatch to unsafe code. A few of them do have this,
others not so much.

It's fun to say C is inadequate, but the space it occupies does not have many
competitors. That needs to change first.

~~~
codygman
I believe Haskell could be up to the job, but I heard that there were some
difficulties in guarding against timing attacks. However those could have just
been noise. I know that a functional (I believe and haha) operating system was
made in Haskell.

Aren't Operating Systems lower level than OpenSSL?

~~~
nknighthb
I look forward to reading the hilarious threads that will be spawned when you
take to linux-kernel, freebsd-hackers, openbsd-misc, etc. and inform them they
should be developing their kernels in Haskell.

Functional programming's unpopularity is not rooted in any real or imagined
inability to write operating systems.

~~~
codygman
Well you also have to account for the fact that they've spent a lot of time
working with their tools and are quite invested in them.

Perhaps they would balk at the idea of writing a kernel in Haskell, but it has
been done before.

------
phillmv
Given the severity of this bug, the UX of the site is failing anyone who isn't
a fulltime sysadmin.

Suggestion: big, bold TLDR ("The sky is falling. Check your OpenSSL version
right now") with a link on what to do sorted by OS vendor.

Step 1: Here's a command to spit out your OpenSSL version. If it is the
following string, go to step 2.

Step 2: Here's how to update your OpenSSL. Here are links to guides on
reissuing keys.

Probably OK the whole remediation bit links to a wiki that gets updated as the
various vendors push their patches.

~~~
lawl
Agree. This needs a big fat _the world is coming to an end_ stlye of warning.

I've just shut down the webservers running SSL that I can control. If you are
vuln and don't want to build openssl from source and can afford the outage.
I'd reccomend to do the same.

 _OTHERWISE BUILD FROM SOURCE IMMEDIATELY, PATCH, AND GET NEW KEYS!_

Let's hope CA's don't get swamped by all the CSR's. Or rather let's hope they
do so we see people are doing something...

For me right now these are just my hobby projects. So I don't care if they're
down. But I imagine it will be fun tomorrow.

And when it's fixed, get new keys.

Btw: I'm a dev. Not a sysadmin though :P

Edit: Debian is patched. I'm online again \o/

~~~
M4v3R
Ok, anyone could assist me on how to update openssl without breaking anything?
I've fetched newest sources from openssl.org and compiled them, but "make
install" doesn't actually install it, it only got compiled, but issuing
"openssl version" still gives me the old version.

What I want to do is to patch it so our webserver uses new version.

~~~
josh-wrale
I would tread lightly here if you aren't comfortable with compiling. Rather
than break your website, it might be better to take it down until your
distro's packages are available.

You should probably spend your time investigating a good method of reissuing
keys for when you get to a stable OpenSSL version.

Some apps have OpenSSL statically compiled into the binaries. Beware that what
you think is fixed may not be.

~~~
M4v3R
Well, I'm not really in position of taking the whole service down at this
moment, I would really like to have a way to patch it instead.

~~~
josh-wrale
Depending on the distro on which you're based, you may find that making a new
package from a source package (e.g. srpm) would be the safest route even if
you're in a hurry.

If you're on Ubuntu, it would appear at least the updated base (OpenSSL
itself) packages are now in the repos.

[http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-2014-0160.html)

------
FiloSottile
I've built a web tester for this bug, find it at

[http://filippo.io/Heartbleed/](http://filippo.io/Heartbleed/)

It actually exploit the bug, since it was quite trivial, and echo some memory.

It's written in Go, no more than 100 lines. I'll release code in some time.

~~~
chirayuk
Would love to see the code and test it against a rebuilt a patched nginx.

~~~
danielhlockard
Just run it against it?

~~~
chirayuk
Well, I was interested in actually testing it out in code. I got it working
with the pyOpenSSL bindings (I had to expose struct ssl_method_st,
SSL_get_ssl_method, ssl_write_bytes and rebuild cryptography for pyOpenSSL.)
Fun times.

------
oskarth
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.

~~~
ams6110
Worse, it's retroactively unfixable: _Even doing all this [revoking certs, new
secret keys, new certificates] will still leave any traffic intercepted by the
attacker in the past still vulnerable to decryption._

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.

~~~
this_user
Shouldn't Perfect Forward Secrecy protect against exactly this kind of
scenario where the server's primary keys are compromised?

~~~
makomk
It does, assuming you don't have any way to extract the session keys from
server RAM - which is kind of the problem here.

~~~
this_user
I was thinking of the scenario of old traffic being recorded by someone.
Unless they also extracted the session key at that time, that traffic should
be secure if PFC was enabled even if someone where to extract the server key
now.

------
MartinMond
As of now (21:04 UTC) this isn't fixed in Debian [https://security-
tracker.debian.org/tracker/CVE-2014-0160](https://security-
tracker.debian.org/tracker/CVE-2014-0160) nor Ubuntu
[http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-2014-0160.html)

Got a long night ahead :/

~~~
mfwoods
I just installed update openssl_1.0.1e-2+deb7u5 and
libssl1.0.0_1.0.1e-2+deb7u5 on debian wheezy, so it seems the fix is now
available.

~~~
sjaak_trekhaak
Just received an upgrade on Ubuntu 12.04 LTS as well, apt-get clean issued
before updating.

EDIT: If you are using DigitalOcean, the update is not yet on their mirrors.
Issue 'sudo sed -i "s/mirrors\\.digitalocean/archive.ubuntu/g"
/etc/apt/sources.list;sudo apt-get clean;sudo apt-get update;sudo apt-get
upgrade' to get the patch. Check the comment by 0x0 above (
[https://news.ycombinator.com/item?id=7549842](https://news.ycombinator.com/item?id=7549842)
) to find any services which need restarting.

~~~
josh-wrale
I can confirm this for vanilla Ubuntu 12.04 LTS. I've been checking for the
past hour. The updates for the following just appeared:

Setting up libssl-doc (1.0.1-4ubuntu5.12) ... Setting up libssl-dev
(1.0.1-4ubuntu5.12) ... Setting up openssl (1.0.1-4ubuntu5.12) ...

~~~
jhealy
Yup, in Ubuntu 12.04 LTS version 1.0.1-4ubuntu5.12 is what you need.

Here's the changelog:
[http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...](http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1-4ubuntu5.12/changelog)

------
perturbation
Node.js sort-of dodged a bullet here. It includes a version of openssl that it
links against when building the crypto module (and, I would think, the tls
module). Node.js v0.10.26 uses OpenSSL 1.0.1e 11 Feb 2013.

However (in openssl.gyp):
[https://github.com/joyent/node/blob/master/deps/openssl/open...](https://github.com/joyent/node/blob/master/deps/openssl/openssl.gyp#L1068)

It disables the heartbeat with the compile time option due to a workaround for
Microsoft's IIS, of all things.

So the affected window for node would have been Sep 11, 2012 to Mar 27, 2013
(based on the commit history).

------
mattparlane
What worries me about this is that the commit that fixes it [0] doesn't
include any tests. Is that normal in crypto? If I committed a fix to a show-
stopper bug without any tests at my day job I'd feel very amateur.

[0]
[http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...](http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3)

~~~
rmc
Sometimes things are time-critical.....

~~~
colinbartlett
Ah, the old middle-management excuse: "We don't have time to write tests!"

~~~
rmc
When half the secure internet is on fire... yeah, i think that's an acceptable
time.

~~~
Rizz
When half the internet is going to install your code without much additional
testing in the next day it had better be properly tested beforehand.

------
Donch

      ./bin/Heartbleed openssl.org:443
      2014/04/08 12:15:44 ([]uint8) {
       00000000  02 00 79 68 65 61 72 74  62 6c 65 65 64 2e 66 69  |..yheartbleed.fi|
       00000010  6c 69 70 70 6f 2e 69 6f  59 45 4c 4c 4f 57 20 53  |lippo.ioYELLOW S|
       00000020  55 42 4d 41 52 49 4e 45  47 69 05 e8 90 a6 60 d6  |UBMARINEGi....`.|
       00000030  b4 18 c3 f0 4a 20 40 3a  ef dd 06 8b 87 32 42 00  |....J @:.....2B.|
       00000040  00 00 10 00 0e 00 00 0b  6f 70 65 6e 73 73 6c 2e  |........openssl.|
       00000050  6f 72 67 00 05 00 05 01  00 00 00 00 00 0a 00 08  |org.............|
       00000060  00 06 00 17 00 18 00 19  00 0b 00 02 01 00 00 0d  |................|
       00000070  00 0a 00 08 04 01 04 03  02 01 02 03 09 14 ce 7c  |...............||
       00000080  6d 0c f5 a0 3b cc 16 aa  3b d4 b1 b8              |m...;...;...|
      }
    
      2014/04/08 12:15:44 openssl.org:443 - VULNERABLE

------
cheald
What 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.

~~~
ams6110
Writeup was too long. We need to know the short and sweet of what to fix.

~~~
sexmonad
Update to 1.0.1g, redo all crypto. That is, revoke certs and keys and
regenerate.

~~~
ehPReth
Just a note to others: all crypto includes things like SSH keys, SSH host
keys, and GPG keys. Anything in memory could have been read.

~~~
mpyne
Well, I don't think it's _anything_ in memory, but whatever was up to 64k from
wherever the downloaded packet was put in userspace (Edit: Er, 64k at a time,
but the attacker can try again over and over). Since the kernel should be
handing only zeroed pages to userspace to use as a buffer then it should only
be memory used by the process using openssl at risk.

The big problem is that this is still a gigantic range of processes (and
possible memory buffer contents). But SSH at least would appear to be fine,
unless you've ever transferred an SSH key over TLS using OpenSSL.

~~~
ehPReth
Apologies, my mistake. I'd redact my comment if I was able to.

------
chomp
How did Cloudflare get access to this bug a week before it was made public,
yet no distro has a package ready?

How's that for responsible disclosure?

~~~
rincebrain
I believe the reason they got access was one of their customers found it and
reported it to them, and they reported it to OpenSSL, and then it somehow
leaked (either with the OSSL release, or someone else) and then they posted
their now-public writeups of it.

~~~
eastdakota
That's not correct. One of the individuals who discovered the bug contacted us
as a large provider of SSL termination services. We were asked not to further
disclose the details until it was officially patched and announced by OpenSSL.
The official announcement occurred today after which we put up a post to let
our customers know that they were protected.

~~~
NelsonMinar
I wonder who else was notified early? I noticed Apple's ocspd was downloading
an unusual amount of data back on March 31. Could be unrelated, but Apple and
other big software vendors would make sense for early notification.

------
lawl
Holy shit. That seems worse than the debian openssl debacle.

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.

~~~
sp332
Oh it's even _worse_ , basically every secret you had in your server
processes' RAM was potentially read in real-time by an attacker for the last 2
years.

~~~
e12e
Isn't there any memory protection on Linux? Something running as www-data
shouldn't be able to read the ssh-server's RAM?

So it's bad, but it's not _that_ bad unless something exposing this bug
(webserver with ssl, vpn, or other service) runs as root?

~~~
rmc
It might be able to read the memory of the ssl server that's making the
response. Including maybe the ssl private key

~~~
e12e
Yes, to be clear (esp. for others reading this thread) this is _really bad_ ,
but shouldn't be able to compromise your _ssh_ server keys.

However -- ssl certs and session keys are a likely target, and combined with
passively logging traffic that is enough to compromise all data going over
ssl, such as login/passwords and data.

Problem servers include not only web servers, but also imap/pop and smtp
servers supporting tls (via openssl -- afaik gnutls isn't vulnerable to this
bug).

------
dkarapetyan
Honestly, why aren't the formal verification people jumping on this? I keep
hearing about automatic code generation from proof systems like Coq and Agda
but it's always some toy example like iterative version of fibonacci from the
recursive version or something else just as mundane. Wouldn't cryptography be
a perfect playground for making new discoveries? At the end of the day all
crypto is just number theory and number theory is as formal a system as it
gets. Why don't we have formal proofs for correct functionality of OpenSSL?
Instead of a thousand eyes looking at pointers and making sure they all point
to the right places why don't we formally prove it? I don't mean me but maybe
some grad student.

~~~
orblivion
You may be interested in Quark, which is a browser kernel written using Coq
[http://goto.ucsd.edu/quark/](http://goto.ucsd.edu/quark/)

~~~
dkarapetyan
Yes, why doesn't the same thing exist for SSL? The fact that quark was funded
by the NSF means that there is interest in actually doing stuff like this.

~~~
orblivion
Perhaps its time will come soon. That would be really cool.

------
userbinator
I think the summary is a bit _too_ sensationalistic in terms of what the
actual security implications are:

 _The Heartbleed bug allows anyone on the Internet to read the memory of the
systems protected by the vulnerable versions of the OpenSSL software._

Yes, while that's true, it's not a "read the whole process' memory"
vulnerability which would _definitely_ be cause for panic. The details are
subtle:

 _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._

The address space of a process is normally far bigger than 64KB, and while the
bug does allow an arbitrary number of 64KB reads, it is important to note that
_the attacker cannot directly control where that 64KB will come from._ If
you're lucky, you'll get a whole bunch of keys. If you're unlucky, you might
get unencrypted data you sent/received, which you would have anyway. If you're
_really_ unlucky, you get 64KB of zero bytes every time.

Then there's also the question of knowing exactly what/where the actual
secrets are. Encryption keys (should) look like random data, and there's a lot
of other random-looking stuff in crypto libraries' state. Even supposing you
know that there is a key, of some type, somewhere in a 64KB block of random-
looking data, you still need to find _where_ inside that data the key is, what
type of key it is, and more importantly, whose traffic it protects before you
can do anything malicious.

 _Without using any privileged information or credentials we were able steal
from ourselves the secret keys_

It really helps when looking for keys, if you already know what the keys are.

In other words, while this _is_ a cause for concern, it's not anywhere near
"everything is wide open", and that is probably the reason why it has remained
undiscovered for so long.

Edit: downvotes. Care to explain?

~~~
atomicUpdate
I agree entirely with your post, and I can't quite understand the hysteria in
this thread. The odds of getting a key using this technique are incredibly low
to begin with, let alone being able to recognize you have one, and how to
correlate it with any useful encrypted data.

Supposing you do hit the lottery and get a key somewhere in your packet, you
now have to find the starting byte for it, which means having data to attempt
to decrypt it with. However, now you get bit by the fact that you _don 't have
any privileged information or credentials_, so you have no idea where
decryptable information lives.

Assuming you are even able to intercept some traffic that's encrypted, you now
have to try every word-aligned 256B(?) string of data you collected from the
server, and hope you can decrypt the data. The amount of storage and
processing time for this is already ridiculous, since you have to manually
check if the data looks "good" or not.

The odds of all of these things lining up is infinitesimal for anything worth
being worried about (banks, credit cards, etc.), so the effort involved far
outweighs the payoffs (you only get 1 person's information after all of that).
This is especially true when compared with traditional means of collecting
this data through more generic viruses and social engineering.

So, while I'll be updating my personal systems, I'm not going to jump on to
the "the sky is falling" train just yet, until someone can give a good example
of how this could be practically exploited.

~~~
jsmthrowaway
I have successfully extracted a key and decrypted traffic in a lab. I'm
refining my automatic process. You're forgetting analysis of the runtime
layout of OpenSSL in RAM which is quite predictable on machines without
defensive measures. I have a 100% success rate extracting memory and about a
20% success rate programmatically extracting the secret key of the server. I'm
nearly 100% against a certain version of Apache with standard distribution
configuration.

I did this with no formal CS education and about 400 lines of code. I'm an
operations engineer, not a security expert. Once I get it 100% and review my
situation legally, I'll probably publish what I have.

Now is not the time to be conservative. Efforts to downplay this vulnerability
are directly damaging to the Internet's security and, given that you are a
single-issue poster, suspicious.

~~~
sillysaurus3
Would you mind emailing me the code? I'd like to learn from it.

~~~
jsmthrowaway
Given the power of this code as a weapon and certain circumstances in my
personal life, I will be consulting legal advice before doing anything with
it. There's a pretty good chance I will be advised against releasing it.

All you need is a debugger against your target service and an ability to
recognize patterns. And no, ASLR doesn't help much.

~~~
sillysaurus3
Ah, understandable. Thank you anyway!

------
iso8859-1
Here's the patch/commit, I don't know why it's not linked form the OpenSSL
changelog or heartbleed.com. A suspicious lack of transparency.

[http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...](http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3)

~~~
brown9-2
_if (1 + 2 + 16 > s->s3->rrec.length)_

I don't know C well - why write 19 like this?

~~~
scintill76
Probably to make it more clear what you're referring to, and double-check
yourself. There are probably components that are 1 byte, 2 bytes, and 16 bytes
long. Writing it out makes it clear and eliminates a chance for human error in
the sum, more than a magic 19 does. (I guess 16 is pretty magical too, though.
At least it's a "round" number, and in context may be a well-known field size
of something in the protocol.)

~~~
georgemcbay
Yeah, this. It is fairly common to see things like this in C-like languages
when it comes to times, like when including the milliseconds in a day you
might see:

int timeout = 1000 * 60 * 60 * 24;

(milliseconds in a second * 60 for minute, * 60 for hour, * 24 for hours in a
day).

Much more obvious than just putting in 86400000, and the compiler will
optimize away the math and putting the math in there explicitly is arguably
better than a comment that could easily become unanchored from the real value
(if someone changes the value and forgets to update the comment).

When it comes to byte-sizes of things, though, most code will use sizeof() to
both make it more clear where these numbers are coming from and to make them
automatically adjust if the structure sizes change (granted this is unlikely
to happen on a mature protocol).

At the very least having them be preprocessor defines would certainly make
things a lot more clear here, so even for C I'd consider this a bit of a "code
smell" (though the people who work on this code regularly are probably versed
enough in the ssl3 record structure enough that they immediately grok this
when they see it).

------
Gygash
Found a Python PoC:
[http://s3.jspenguin.org/ssltest.py](http://s3.jspenguin.org/ssltest.py)

Edit: and just used it to dump 64K from a known-vulnerable device we control.
Got a session cookie. Jeez.

~~~
cdelsolar
JESUS CHRIST, all sorts of private information. Patch your servers now!

~~~
vinhboy
After reading your comment, I started looking back at the packets I got using
the script on a site I knew was not patched. Damn.. there are plaintext
passwords in there for paypal.

This shit is scary.

~~~
cdelsolar
There is going to be massive amounts of fraud all over the world for a while
because of this bug.

------
gojomo
Does 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?)

~~~
tptacek
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.

~~~
whyleyc
Sooo in layman's terms - we only need to be worrying about HTTPS and not SSH ?

~~~
rurban
If it would be that easy. ssh not, but all those. Some of them actually use
the heartbeat feature. curl seems to be the worst.

$ apt-cache showpkg libssl1.0.0 =>
[http://perl514.cpanel.net/libssl1.0.0.depends](http://perl514.cpanel.net/libssl1.0.0.depends)
(186 deps)

~~~
dfc
I am having a lot of trouble figuring out what you were attempting to convey
in the first four sentences in your comment.

The one thing that I can discern is that you printed a list of every package
that depends on libssl1.0.0 for your configured repositories. But you have no
idea if those programs make use of heartbeat. ssh (and everything related like
libpam-ssh) is on that list and does not use TLS. The same can be said for
many others such as tpm-tools, ntp/ntpdate/openntpd, xca and so on.

------
whyleyc
This doesn't sound like "responsible disclosure" to me - how can Codenomicon
dump this news when all the major Linux vendors don't have patches ready to go
?

~~~
gsnedders
Because it was already disclosed the instant the OpenSSL release went out and
the fix was public.

~~~
whyleyc
Well _someone_ was able to give Cloudflare a heads up last week [1].

It would have been nice if the package maintainers could have had time to
build ready-to-roll solutions with Heartbeat compiled out prior to the
official OpenSSL fix.

[1] [http://blog.cloudflare.com/staying-ahead-of-openssl-
vulnerab...](http://blog.cloudflare.com/staying-ahead-of-openssl-
vulnerabilities)

------
halter73
> 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.

~~~
AnthonyMouse
In addition to that, it obviously disables the TLS heartbeat extension, which
would break existing code that uses it.

------
zmillman
Does anyone know how Amazon's Elastic Load Balancers are affected? I can't
find anything on the AWS site

~~~
earless1
That is my concern as well. We are still running CentOS 6.4 which does not
have the affected version of OpenSSL, but we terminate SSL at the ELB so if
they are affected then are keys are not safe.

Edit: I've posted on the support forum, hopefully they get back to us
[https://forums.aws.amazon.com/thread.jspa?threadID=149690](https://forums.aws.amazon.com/thread.jspa?threadID=149690)

~~~
snewman
I opened a support ticket, and Amazon just responded to say that yes, ELBs are
vulnerable. I've posted their reply into that thread.

~~~
syncsynchalt
Any ELB deploys I've done in the last hour seem to be fixed.

------
IgorPartola
What are the chances that the NSA is having a field day with this in the 24-48
hours that it will take everyone to respond? Also, is it possible that CA's
have been compromised to the point where root certs should not be trusted?

~~~
rst
What are the odds that the NSA didn't already know about it? Even if you don't
think they would have deliberately monkeywrenched OpenSSL (as they are widely
believed to have done with RSA's BSAFE), they certainly have qualified people
poring over widely used crypto libraries, looking for missing bounds checks
and all manner of other faults --- quite likely with automated tooling.

As to CAs, there have been enough compromises already from other causes that
serious crypto geeks like Moxie Marlinspike are trying to change the trust
model to minimize the consequences --- see [http://tack.io](http://tack.io)

------
ahomescu1
What's interesting is that RFC 1122 from 1989 warned about problems like
these, and gave a very good approach to prevent them from occurring:

 _At every layer of the protocols, there is a general rule whose application
can lead to enormous benefits in robustness and interoperability

[IP:1]: "Be liberal in what you accept, and conservative in what you send"

Software should be written to deal with every conceivable error, no matter how
unlikely; sooner or later a packet will come in with that particular
combination of errors and attributes, and unless the software is prepared,
chaos can ensue. In general, it is best to assume that the network is filled
with malevolent entities that will send in packets designed to have the worst
possible effect. This assumption will lead to suitable protective design,
although the most serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events; [...]_

------
hf
Over 300.000 LoC:

    
    
        ~/tmp/openssl-1.0.1g $ find . -name "*.c" | xargs wc -l  | tail -n1
          349834 total
    

This is too much by _at least_ one order of magnitude. What's the going price
for a crypto-level code review (I'm not even saying audit) these days?

Is all this code necessary for state-of-the art encryption or isn't it rather
backwards compatibility baggage? If the latter: how much could be gained by
splitting the project into '-current' and '-not'?

~~~
eliteraspberrie
The cost of a cryptography code review is about $5-10k per week.

~~~
hf
Thanks! So how does this work: Say I have this project and I want it audited
-- would you (or the company/person that you had in mind) give me an estimate
like "I'd need 3 weeks for 25, 5 weeks for 50 or 10 weeks for 95% coverage" or
do you simply analyse away for a week (or whatever time I'm willing to pay
you) and try to find _something_?

~~~
eliteraspberrie
I don't have personal experience with it, but apparently these things are
booked months in advance, on a contract basis. The engineer doing the audit
spends an agreed number of weeks finding as many problems as they can, and
hand you a report at the end.

~~~
hf
Thanks!

------
te_chris
Great 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?

~~~
rcoder
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!

------
mikeash
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 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.

~~~
bm1362
I'll give it a shot. Quoting a poster above.

>>> TLS heartbeat consists of a request packet including a payload; the other
side reads and sends a response containing the same payload (plus some other
padding).

So, what happens is that the payload comes in as a pointer and a size (up to
64kb). The server then prepares a response and copies the memory block
[pointer, pointer+payloadSize] into the request.

The attack happens when the payload is smaller than the payload size passed in
the request. This results in the response preparation dumping the memory block
[pointer+realPayloadSize, pointer+payloadSize] into the response.

Any data in this block is now exposed to the callee; and could contain any
data from the process.

~~~
mikeash
Thanks. That lines up with what I've seen elsewhere too. I think the main
thing I was missing was that this is not a _sniffing_ attack, but rather an
active attack where you talk to a peer over SSL and basically trick it into
sending you some content from its memory.

------
kseifried
RHEL updates are available:
[https://rhn.redhat.com/errata/RHSA-2014-0376.html](https://rhn.redhat.com/errata/RHSA-2014-0376.html)

CentOS updates are available: [http://lists.centos.org/pipermail/centos-
announce/2014-April...](http://lists.centos.org/pipermail/centos-
announce/2014-April/020249.html)

Fedora updates are available, hitting the mirrors, but you can get it earlier,
instructions here:
[https://lists.fedoraproject.org/pipermail/announce/2014-Apri...](https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html)
[https://lists.fedoraproject.org/pipermail/announce/2014-Apri...](https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html)

------
ineedtosleep
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

~~~
cheald
Yeah, I haven't seen any new RPMs for RHEL/CentOS/Fedora yet. Kinda
concerning, since I'd expect vendors to be given advance notice and the chance
to prep updates to coincide with the announcement.

All my RHEL5 boxes are running 0.9.8, though, at least.

~~~
fastest963
I've built RPMs for 1.0.1g for CentOS 6. Based of 1.0.1e source rpms.
[https://www.dropbox.com/sh/7s1fiuvfwma16ra/iSz3Jfh1o-](https://www.dropbox.com/sh/7s1fiuvfwma16ra/iSz3Jfh1o-)

------
comice
Remember that checking services for the OpenSSL heartbleed vulnerability
without permission is actually illegal in many countries (UK in particular).

------
mpyne
Whoa, this seems horrifying.

One (selfish) question I have is whether this can affect primary key material
stored in an HSM. I'm assuming not, but that the session key generated by the
HSM would still be susceptible.

~~~
ctz
If you are using a HSM your long-term authenticity key won't be in the memory
space of the process with openssl inside it. So that should be OK.

However, everything else in that process (like, all the traffic you were
hoping to protect) is basically toast.

------
ParadisoShlee
Note that this bug affects way more programs than just Tor — expect everybody
who runs an https webserver to be scrambling today.

"If you need strong anonymity or privacy on the Internet, you might want to
stay away from the Internet entirely for the next few days while things
settle." \- torProject

------
mstrem
From the CloudFlare blog: "This bug fix is a successful example of what is
called responsible disclosure".

I just discovered this now and

    
    
        yum info openssl
    

Yields 1.0.1e as available package which is vulnerable. I guess not all
"stakeholders" have been warned properly - or am I jumping to conclusions?

~~~
jlgaddis
Apparently Red Hat, Debian, and Ubuntu weren't (from what I gather from
reading mailing list posts) -- no idea who else.

That's not responsible at all, IMO. Whoever was in charge of this (NCSC-FI?)
isn't very good at coordinating.

~~~
tiagocruz
[https://access.redhat.com/security/cve/CVE-2014-0160](https://access.redhat.com/security/cve/CVE-2014-0160)

[https://bugzilla.redhat.com/show_bug.cgi?id=1084875](https://bugzilla.redhat.com/show_bug.cgi?id=1084875)

~~~
tiagocruz
[https://rhn.redhat.com/errata/RHSA-2014-0376.html](https://rhn.redhat.com/errata/RHSA-2014-0376.html)

------
mark-r
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.

~~~
mark-r
I knew I was going to be attacked for saying this, but isn't it a real
possibility? We already know that they tried to weaken RSA.

~~~
javajosh
It is evil to make totally unsupported accusations, even against the NSA. I've
downvoted you, twice.

~~~
Karunamon
Asking "did they do this?" is not an accusation, seriously.

And even then, the NSA has had their fingers in enough places and lied about
it enough times (infiltrating FOSS projects was explicitly one of their goals,
IIRC) that the sane default position would be to assume shenanigans on their
part unless proven otherwise.

The vetting process does absolutely nothing to prevent something like this
from happening, especially since some _very sneaky and pernicious_ bugs can be
introduced in the guise of simple mistakes. It would be foolish to assume this
isn't part of the standard playbook, and just as foolish to discount the
possibility of maliciously introduced bugs just because the evidence doesn't
immediately point to malicious intent - that is the nature of the attacker.

The alternative is remaining ignorant and vulnerable to the single most well
funded and experienced adversary a crypto user will ever likely face.

~~~
javajosh
_> Asking "did they do this?" is not an accusation, seriously._

Nonsense. Are you a child-molester? I'm just asking, not accusing you of
anything.

~~~
Karunamon
The difference being I don't have a history of doing such things and then
repeatedly lying about it....

------
malandrew
We really need to see some of the big companies take down their services until
they've fixed this and call out for every company out there to audit
themselves and confirm to users that this is serious and should be checked and
that no service should stay online until they've patched their systems. This
should get attention beyond just techies. Business as usual is not acceptable
since every day that goes by is the opportunity for someone to take advantage
of this and get the keys to your service and all past traffic.

I would not be surprised if people at the NSA, GHCQ and most state security
services are going into overdrive right now to get access to anything and
everything that is vulnerable to this bug.

~~~
morgante
> I would not be surprised if people at the NSA, GHCQ and most state security
> services are going into overdrive right now to get access to anything and
> everything that is vulnerable to this bug.

I assume the NSA has known about this bug for a long time and has been
actively exploiting it.

------
thursley
Snort IDS rules to detect abuse can be found here: [http://blog.fox-
it.com/2014/04/08/openssl-heartbleed-bug-liv...](http://blog.fox-
it.com/2014/04/08/openssl-heartbleed-bug-live-blog/)

------
syncsynchalt
Note: if you use mint.com, it's likely hitting your banks with your login on
your behalf today. You'll still want to change those passwords even if you
didn't use banking sites during the known vulnerability window.

~~~
rkuykendall-com
The "known vulnerability window" is over 2 years.

~~~
syncsynchalt
The window in which the vulnerability was publicly known.

I'm trying to come up with a personal security model that doesn't end with me
living in a cabin in the woods.

~~~
rkuykendall-com
Ah, comforting lies. Here's mine: "My data isn't important enough for any of
this to affect me. "

~~~
nadahalli
Not you. But (someone connected to)+ you.

------
tlrobinson
_" Is there a bright side to all this?"_

"Yes, we can sell you our software!"

------
huherto
Is it a problem for those using ssh keys on github ?

~~~
flym4n
You'll need to replace them ASAP, once github updated their version of ssh .
But if they run on 0.9.8 branch, you don't have to worry.

~~~
gojomo
Answers in sibling threads suggest ssh/sshd is not affected, as ssh uses its
own protocol other than TLS.

------
lkbm
So, Google and Codenomicon independently found this two-year-old vulnerability
at approximately the same time? How does that happen? Are they both looking at
the same publicly-shared fuzzing data, or was there a patch that suddenly made
it more obvious?

The obvious concern would be that one found it a good while ago, and just
didn't bother announcing it until the other team was anyway. I don't believe
that's what happened here, but I'm curious what the mechanism actually was.

------
jeffDef
Is there a way to tell if a third-party site has patched the bug? (Upgraded to
1.0.1g) Not much point in changing your password on that site before the
vulnerability is fixed.

~~~
elliottcarlson
echo -e "quit\n" | openssl s_client -connect <HOSTNAME>:443 -tlsextdebug 2>&1|
[ "` grep -c 'TLS server extension \"heartbeat\" (id=15), len=1'`" -gt 0 ] &&
echo 'Vulnerable'

~~~
jsmthrowaway
That can false-positive, for what it's worth, in servers with fixed TLS
heartbeats (instead of removing them).

------
bch
All references I see recommend (for 1.0.1-series) to move to 1.0.1g - but the
OpenSSL homepage[0] says that 1.0.1g is a Work in Progress. There _is_ a
download[1] link for it though. Anybody have definitive answer for what's
going on here? It's a little confusing.

    
    
      [0] http://www.openssl.org/news/state.html
      [1] http://www.openssl.org/source/

------
46Bit
How widely implemented is certificate revocation?

------
jbailo
I used the OpenSSL library for building a SAML token parser in JBoss (java).
All the front end stuff was java and OpenSSL was used for public/private key
decryption and validation of SAML tokens and signatures. I'm not sure exactly
what an OpenSSL "server" \-- it sounds like there is a feature which you can
implement (or not) in your webserver to test the SSL/TLS listener.

However, you could -- as I did -- use anything else as your interface for the
web. Why would you specifically include a heartbeat for just SSL is beyond me.
If a website is up and running, you'll know it with the usual methods, the
https codes. You don't need a separate "heartbeat" for telling you that an
internal mechanism for processing a protocol is running...do you?

------
astrange
Are people going straight to buying new domain names for every TLS bug
discovered these days?

~~~
rguldener
I'd be surprised if heartbleed.com was still available in 2014

~~~
whyleyc
It was - registered 2 days ago by Marko Laakso from Codenomicon, the guys
credited (by themselves it seems !) with finding the bug:

[http://www.networksolutions.com/whois/results.jsp?domain=hea...](http://www.networksolutions.com/whois/results.jsp?domain=heartbleed.com)

~~~
Gigablah
They should probably get the guy who designed heartbleed.com to revamp their
own website :)

~~~
vinhboy
lol.. good one.. agreed!

------
abc123xyz
rapidbleed! search rapidshare for "enc"

[http://api.rapidshare.com/cgi-
bin/rsapi.cgi?sub=getaccountde...](http://api.rapidshare.com/cgi-
bin/rsapi.cgi?sub=getaccountde..).

accountid=46048788 firstname=mandeep lastname=sihag servertime=1397038309
addtime=1359871506 username=heavenlybeast directstart=1 country=IN mailflags=n
language=en jsconfig= email=heavenlybeast@live.com curfiles=36
curspace=1213591844 rapids=0 billeduntil=0 nortuntil=0 maxspacegb=10
additionalspacegb=0 maxdaytrafficmb=100 additionaldaytrafficmb=0
traffictoday=20511350 accounttype=0 valid=1 payabo=0 promocode=0 promotype=0
promovaliduntil=0 maxfilesize=300000000

------
Mizza
Has anybody seen or created a PoC for this yet?

~~~
Mizza
UPDATE: I've found one! Shouts to the venerable FiloSottile!

[https://github.com/FiloSottile/Heartbleed/blob/master/bleed/...](https://github.com/FiloSottile/Heartbleed/blob/master/bleed/heartbleed.go)

------
oskarpearson
It seems that this is likely to impact OpenVPN too, since it uses TLS -
[https://openvpn.net/index.php/open-source/337-why-openvpn-
us...](https://openvpn.net/index.php/open-source/337-why-openvpn-uses-
tls.html)

Using a tls-auth key may help mitigate this (especially if you use UDP) since
it should stop anything reaching the TLS handshake layer.
[https://openvpn.net/index.php/open-
source/documentation/howt...](https://openvpn.net/index.php/open-
source/documentation/howto.html#security)

~~~
Karunamon
Testing my externally-accessible OpenVPN server revealed that it is indeed
vulnerable. I just powered the box off, going to be a long day at work before
I can get home and fix it :/

------
calvins
heartbleed.com itself is still using a vulnerable OpenSSL, according to
[http://filippo.io/Heartbleed/#heartbleed.com](http://filippo.io/Heartbleed/#heartbleed.com)

~~~
calvins
It's been patched since, and is no longer vulnerable.

------
WhiteDawn
I've posted this link in a separate article but I think it is more useful
here.
[https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx_conf...](https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx_configuration_details)

How to build openSSL statically into a source build of Nginx, just finished
running this with nginx-1.4.7 and openSSL-1.0.1g and it compiled just fine.
You'll have to tweak it to your environment of course.

~~~
egeozcan
Is openssl in nginx statically linked by default? If so: ouch.

------
gojomo
What popular SSL client software uses the vulnerable OpenSSL? (Any web
browsers, for example on popular linuxes? How about 'curl' when connecting to
HTTPS sites?)

~~~
gsnedders
Web browsers all by default use other crypto libraries. (Chromium can be
linked to OpenSSL, some distros may ship this — I haven't looked.)

Email clients may be more vulnerable — Thunderbird doesn't, Mail.app doesn't,
but I'm unaware what most use.

~~~
hrrsn
Sidenote, OS X machines, by default, are not affected by this bug.

$ openssl version -a OpenSSL 0.9.8y 5 Feb 2013

------
thefox
Some Facebook servers are vulnerable for the Heartbleed bug:
[http://pastebin.com/dmYYpx2y](http://pastebin.com/dmYYpx2y)

------
lxgr
Android versions 4.1 and higher seem to be vulnerable (check the
openssl.version file for every version in
[https://android.googlesource.com/platform/external/openssl.g...](https://android.googlesource.com/platform/external/openssl.git/+refs)
and compare with the vulnerable versions listed on
[http://heartbleed.com/](http://heartbleed.com/)).

~~~
biafra
I looked at the 4.4 (Kitkat) source code and it seems to me that the HEARTBEAT
is disabled.
[https://android.googlesource.com/platform/external/openssl.g...](https://android.googlesource.com/platform/external/openssl.git/+/android-4.4.2_r1/build-
config.mk) contains -DOPENSSL_NO_HEARTBEATS

I am also unclear whether Dalvik or ART use OpenSSL for TLS connections.

------
Kiro
A lot of doomsayers here but I'm running a service which could just as well be
http. https is only there for show. Why do I need to upgrade?

~~~
MichaelGG
If your process space is public, you don't.

There's probably the potential for segfaults, though, since the code might
read past all allocations.

------
bad_user
What I find strange is that I have a VPS setup on Digital Ocean, with Ubuntu
LTS + OpenSSL 1.0.1 + a manually compiled Nginx. This combination should have
been vulnerable, yet my website is not reported as vulnerable by the tools I
tried for detecting the vulnerability.

Maybe DigitalOcean issued a fix without me noticing? I also updated my Ubuntu
packages, yet OpenSSL is still at 1.0.1.

------
BrandonMarc
Tinfoil-hat time: is it interesting that within hours (?) of public disclosure
of the bug, there's a domain, a logo, a full writeup, everything. The paranoid
part of me says the nefarious powers-that-be _want_ me us to use the latest
version, as though that would further their goals somehow.

Common sense says I'm just being silly. I just wonder.

~~~
sukuriant
A close reading of this thread shows that CloudFlare(?) knew about the
vulnerability for a week. It's been known for at least that long

------
panzi
How feasible would it be to write things like nginx, Apache, web browsers etc.
so that they can use both OpenSSL and NSS, where you could choose what to use
via config switch? Then it would be easy to "fix" such a bug when it occurs.
The probability that both libraries have a vulnerability at the same time is
probably very low.

------
SmileyKeith
Can some people who are smarter than me give us the flags we would like to
compile this with manually?

~~~
elwell
says how to on the official notice:
[http://www.openssl.org/news/secadv_20140407.txt](http://www.openssl.org/news/secadv_20140407.txt)

    
    
      recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS

~~~
SmileyKeith
Figured there might be more than just that flag you'd want to compile with.

~~~
jlgaddis
There probably are but since no one can know what features you do/don't need,
you're probably gonna have to RTFM and decide for yourself.

------
digitalabyss
OK well I just updated about 40 servers. Has anyone started working with CAs
to reissue SSL certificates signed with a new key? Are they willing to do the
reissue for free? In particular I use RapidSSL for most things and Verisign
for a few bigger clients who prefer it.

~~~
rodgerd
How do you know your CA isn't vulnerable?

~~~
digitalabyss
I don’t; but I do not know how I could ever be sure. I’m a generalist sys
admin and my knowledge of crypto is limited to the basics. That being said my
understanding is that this vulnerability is in the code that creates the
sessions not in the certificates themselves. The risk is that my key already
was compromised when I was using the vulnerable version. For me this means two
things:

1) There is no easy way for me to confirm or deny the CA is fixed short of
attempting to exploit them.

2) Even if the CA is not fixed the vulnerability appears to in the routines
used for session management not in the SSL certificate itself. While there is
cc information and other stuff I would not like to be leaked, the CSR itself
only contains my public key not my private key. As long as my servers are
patched and I have a SSL cert using a new keypair that I know has not being
compromised; I am not sure if the CA's version of openssl maters or not.

I am in no way trying to pretend I am an expert. I am sure there are problems
with my analysis but it still feels like its time to be pragmatic and get a
fix in place before asking all the what-ifs. Not that those questions should
not be asked but it’s a mater of prioritizing.

------
jaseemabid
So now that NSA can steal private keys, all the logs they collected over the
years can be decrypted?

------
ArloL
I believe that everyone should at least consider donating to the openssl
software foundation:
[https://www.openssl.org/support/donations.html](https://www.openssl.org/support/donations.html)

------
dahjelle
In case it is useful to anyone: here's my notes on rebuilding RPMs for Fedora
18:
[https://gist.github.com/dahjelle/10151097](https://gist.github.com/dahjelle/10151097)

------
zizee
Heroku is working on it, but as of 07:02 UTC (30 mins ago) they have not
released a fix:
[https://status.heroku.com/incidents/606](https://status.heroku.com/incidents/606)

~~~
klapinat0r
Since their own (status.heroku.com and heroku.com) certs are from 2013-10-03,
this illustrates a bad situation post-heartbleed:

Were they using a 1.0.1* vulnerable OpenSSL, or not? or did they (unlikely but
possible) not adequately fix the issue.

This is information only the service provider has, and thus poses a dilemma
(in terms of transparency at least).

Here's hoping for the best.

------
markwakeford
Would you be somewhat better protected i.e. (not loosing private keys, etc) if
your machine sat behind a load balancer ? The memory exposed would be that of
the load balancer correct ?

~~~
marshray
Depends on if the LB was doing the SSL termination (offload).

But still, the private keys are at risk. There are worse scenarios, but just
barely.

You _were_ using [EC]DHE cipher suites, weren't you?

~~~
markwakeford
Its only a development environment so my risk is fairly low, However I was
just curious, its an Amazon ELB.

------
wpeterson
There are open support tickets in both Heroku and AWS about the impact of this
bug but no answers yet.

I hope folks will promote a warning if either platform is effected both on
HackerNews and twitter.

~~~
zizee
Got links?

------
Klundro
Here is an online tool to check if a site is affected by it:
[http://possible.lv/tools/hb/](http://possible.lv/tools/hb/)

------
allochthon
How is it that Google and Hotmail were not vulnerable? Were they using their
own implementations of SSL? I would have figured Google would make use of
OpenSSL.

------
betadreamer
I'm not a security guru... So what kind of attack can this cause? Does this
mean https will not be secured if the site uses vulnerable OpenSSL?

~~~
dijit
it means if you're running a bad version of openssl then someone can dump the
entire contents of your ram, including public/private keys, and anything that
is in memory such as passwords and even DB connections.

------
bogwog
Who the hell went through the trouble of buying a domain name, building a
website, and designing a logo just to talk about one bug?

~~~
psquid
Someone who wanted to be sure that bug stuck in people's minds enough that
they wouldn't just ignore it? Seems at least feasible.

------
borrowedtime
I haven't seen a discussion about whether this can also bypass those using
2-step verification. Does anyone here know?

------
lox
Scary what the implications of this will be for OpenVPN traffic that has been
captured and stored over the past 2 years.

~~~
blrgeek
None really.

Exploiting this requires a client that sends a malicious Heartbeat packet with
a large payload size.

This is unlikely to have happened in the past without any malice.

------
donpdonp
gentoo has a flag for the TLS heartbeat, so its easy to turn off.

root# USE='-tls-heartbeat' emerge openssl

~~~
stefantalpalaru
Remember to add it to /etc/portage/package.use for a permanent fix (unless you
use ~arch for which 1.0.1g is now available).

------
TomGullen
Any scope here for SSL companies to actually have to make good on warranties
they offer here?

------
jydarche
So, many certificate authorities will need to re-issue certificates?

------
joevandyk
We use openvpn. Does that need to be updated?

~~~
nwf
As far as I can tell, openvpn with TLS authentication is vulnerable as it just
uses the usual TLS suite. If you use PSKs or the (mis-named?) --tls-auth PSK
additional MAC, then you are only owned if one of your own legitimate nodes
revealed the PSK (or was coopted into performing this attack) in which case
you're already owned.

------
alxndr
Love this

> Is there a bright side to all this?

------
watermarkcamera
Does linux sshd have this bug ?

------
danielweber
Mirror please?

------
samstave
They should call their team AnttiMattR

:"(Riku, Antti and Matti)

------
dschiptsov
So, basically, it is the consequence of "quickly adding an implementation" of
an extension of the TLS protocol to otherwise mature, more-or-less solid and
"slightly" audited (at least by OpenBSD and FreeBSD teams) code base. OK. It
happens.

btw, is OpenBSD affected or they did the job well by _not_ blindly adding an
unnecessary stuff (extensions) and bumping the versions without auditing the
changes?

------
pearjuice
"goto fail;" doesn't seem that bad now huh. Lovely how these GNU/Linux freedom
fighters were LOLling their asses off earlier, but when it happens to them
they sweat themselves and cry for spoon-fed instructions to compile a software
package from its sources.

\- sent from my Mac

------
AndrewBissell
I found this video of security researchers publicly announcing the existence
of the heartbleed bug:
[https://www.youtube.com/watch?v=7CkTYPnJS0E&list=PL0ECC73C46...](https://www.youtube.com/watch?v=7CkTYPnJS0E&list=PL0ECC73C46561F930&index=2#t=0m33s)

