

The Heartbleed Challenge - jgrahamc
https://www.cloudflarechallenge.com/heartbleed

======
eastdakota
You can read more about the CloudFlare Challenge and our own tests on
obtaining SSL Private Key material here:

[http://blog.cloudflare.com/answering-the-critical-
question-c...](http://blog.cloudflare.com/answering-the-critical-question-can-
you-get-private-ssl-keys-using-heartbleed)

Matthew Prince Co-founder & CEO, CloudFlare

~~~
apaprocki
It seems like a "feature" that you'd want your process to store the private
key material as low as possible in the address space so that arbitrary read
overruns don't run the risk of hitting it. It seems to just accidentally be
this way in nginx, but I wonder if it should just be another (tiny) layer in
the overall security design.

~~~
pbhjpbhj
Shouldn't they be at the top of the address space then overruns would never
hit them as they'd start below or does it not work like that.

~~~
justincormack
Or you can put in a memory area with unmapped sections on both sides if you
are paranoid.

~~~
apaprocki
True.. I wonder if any specs/certifications actually require something like
that. Typically I mostly use tricks like that to track down bugs, but there's
nothing wrong with using it in production for something like a single key/cert
alloc. It becomes a bit unwieldy if you have lots of things to protect.
(Especially on machines with 64k pages :))

~~~
justincormack
Well it seems like Akamai were doing exactly that. If you have lots I would go
multi process though.

Someone else who uses Powerpc?

------
d0ne
We will add a $10,000 bounty for the first published and confirmed successful
completion of this challenge.

Conditions:

1) CloudFlare confirms success.

2) The winner publishes their solution, including source, publicly.

3) Promptly send the link to the publication to [adam | ionicsecurity | com]
(for tracking the order of submissions)

Good luck!

~~~
suyash
That is awesome Adam, please have it posted on the Challenge page so that more
people can see it. Hopefully someone solves it soon :)

~~~
blantonl
Hopefully someone _doesn 't_ solve this!

------
tptacek
Didn't Juliano Rizzo already post that he'd been able to extract keys from a
server? I'm not clear on the circumstances; for instance, it might have been
right after boot, and it might have been Apache, and it might have been
FreeBSD.

~~~
wglb
Errata security modified their original post to say that yes they are
extractable. And a moderator properly fixed the title after the article was
changed to reflect the retraction:

[https://news.ycombinator.com/item?id=7561399](https://news.ycombinator.com/item?id=7561399)

------
quasque
I wonder if Cloudflare is logging all data sent to and from the challenge
server, and then searching it for private key fragments. If not, they should
be! As it's not guaranteed that a lucky attacker will be aware of receiving
key material, if it is exposed.

------
danielweber
It's cool seeing other people's attempts to extract the key in my return
buffer.

It's like multiplayer microcorruption.com

~~~
tptacek
Which, FWIW, is in the works.

~~~
leigh_t
Please please please email out to past participants when it is available, the
first one was amazing amounts of fun.

~~~
tptacek
The new one is b-a-n-a-n-a-s.

~~~
just2n
What do you mean "multiplayer"?

In the spirit of this challenge? A single exploitable endpoint where any
number of N people are to go at the same implementation?

You can't tease this hard, man.

Also, Friday launch? :)

------
aus_
Someone is submitting false keys in their POST data :D

    
    
      -----BEGIN RSA PRIVATE KEY-----
      MIIEowIBAAKCAQEAwYUYN1fR2/z+Net8DdDhNR7poeX608gwFNDVTQZNjldwi503
      cLCaFbPpGkkh84sxpsL0PqrMx9OprdNaMPe0ewuTjjZyb1MaqzfXz/XCiOaT7kWZ
      P9bRae2cI5CETZHD/CvWjsxZ+0exFRSGtph+3esDuvwGQprfYY8d2PIpPOFDgIW7
      gCX6/xTpB+3PCt8lQYbrYiOIogrI+1xpqp5WBCHRzL6La/Zhav1Q6rrSHk1woGdk
      gJBNr3k8NsOjFfNbJgLTgsOz7Yu7Wh6UiV7Y5BMxzuK0eMlJey9ODkyFwhG/pnMg
      qeMf4j1bfaA9AdI8sffSd+1hY9tbt4vfZhBphQIDAQABAoIBACGh/glwS9rN52h7
      mr3T9bADxVsL20H/YsvbV5bhZ407iSXalw4Qw1bOQ877stje8iwnaceSa7C3CqBZ
      QS2Nf2J7KpPmxpCugs4LEIjmD383g7I/iljb/t1IHIDZ1wScNtGW1N1QirrvRMmD
      Hb6SVko/VBClSHk+7V/JPci8nYok1vWytXyi/QJ8EaQ5FPglm3n+QHBnFdl3A8qn
      cWpK3t6BYijkJAK5PNIc1g0YxkSerG5hwCqWleRt29V5QPZqgEc0raSFolN0XOo6
      8us1z37IDRGvm0sHbGgKfi3/Mj+b3Npa+0cQgsGVmymLjyMSf/cLiF0c3rDpHamY
      NqsFj8ECgYEA4JHeIM0M/MVCbUaqCFOtGYmRK9CL8eoAGVJgXa96Z+gP7W/bAjw9
      IEe9NeGIwr2KidZljyv23CwK1Fn7nDuloG5ZXvzpP3jNRJ62Z0Y6RkICpWgpN1HL
      uUG6R4LlB3mXyYE4UGoNAxfgWRcPAn0vsKIuY5/N69FBXiE9h6cjHVkCgYEA3Jq8
      v/qx7T73p9iUFAFDUNF/poQShqimGdfubMSbhUBXGkx5hPyKYUrzUwwZTlLwo4SB
      +nP1cuJUdnEY+ZlzSxvh/EADvxiq20aUm7R+o+GXc68JZBmUKg+tQVSTw+Us8uds
      w1jhFa+b4UpSR+ZHOhR5Hhiw1mdRPu5TAwdtzA0CgYBJpQxnTVdY/YePNoFEQcye
      d1K4P6flKYvmwfEASC+oK54ti2UTEpYpI92U8eVbl7T7Bug/T3ehNIBIq0msLpNe
      TVHZqK8FNaR7QGEo9QrfR35+p+38SkK4+ikQkohxLxrr5giFtoGV5hqYnMs7Ubp1
      /nmgCiQJlZIOQHBhMBp/4QKBgEog3OgNz5gPHp0SE8AdJIeVvjUwECGbriTlAEMg
      VboTArHdnL/pNH649sajPCWrjR0FO7/zEzlFgGhEXMYSoEFO30MqJ5ghK9h/ARTJ
      M/zRo1jGKnuudLElj2xyhSzAZ7g/t7Z0uT3WQqUTmk56vNhxZLmORm3lTdG9t7s+
      1dBJAoGBAJWKz/T/0PQLOOggof0KzEciehWuLcV0eLid16DaNWwiVkm88zt54MdB
      FkbsXWJpQxYpKCxt4XaZGBVP5yLIkrWjElWMtrZPh3pYR8WJQTwosv74n7roBt80
      9ejTR8GQ7401BS7foMjCnVevrl2UwN5SPvtYsLLEMxYGGgSwfz9D
      -----END RSA PRIVATE KEY-----

------
tomvangoethem
Note that by visiting, your IP and referer become accessible by anyone running
an heartbleed exploit:

    
    
      93.142.x.x - - [11/Apr/2014:10:44:36 -0400] "GET /heartbleed HTTP/1.1" 200 1148 "https://news.ycombinator.com/" "Mozilla/5.0 (Windows NT 6.1; WOW64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"

~~~
webXL
Whoops, too late. Were you able to get that info from actually running the
exploit?

~~~
tomvangoethem
Yes, I was. I extracted access-log entries from 23 unique IPs in a few hours,
though most came from a single IP

------
conformal
what i am expecting ppl to see is that you can't actually get to the tls
private key itself. we have done some testing with our backup service,
cyphertite, and have yet to attack and actually compromise any keying
material.

EDIT: forgot to cite neel mehta
[https://twitter.com/neelmehta/statuses/453625474879471616](https://twitter.com/neelmehta/statuses/453625474879471616)

~~~
jnbiche
You all are involved in so many great open source projects -- just wanted to
give a shout-out to Conformal. People do notice and appreciate your
contributions.

How many full-time people are working there?

~~~
conformal
we appreciate your supportive comments :)

there are about 10 of us at conformal.

~~~
dfc
I like spectrwm but it really needs a NEWS/CHANGELOG. Users can not quickly
get an idea of what has changed in between release X and Y. I went to update
the debian "please package latest spectrwm" bug and there is no easy way to
post the changes between 1.0.0 (yes the debian package is that old) and 2.5.0.

------
simias
It's a good idea but even if nobody successfully exploits this particular
website with the heartbleed bug doesn't mean much for the rest of the
vulnerable sites.

Since the bug exposes a few kilobytes of uninitialized malloc() memory the
kind of data the attacker will retrieve is heavily dependent on the software
the server is running.

~~~
ygra
I read elsewhere that the bug exposes first and foremost memory that OpenSSL
itself used before (because OpenSSL has its own allocator running on top of
malloc).

------
51Cards
Is this really an accurate challenge? I have wondered if the true exposure
risk from Heartbleed may be over-stated* due to memory separation between
processes, etc. This however is probably a clean server with a fairly static
install. There isn't a risk of things like session leakage which I think is
the true risk of Heartbleed. Nor would there be the memory fragmentation that
would occur in a production system. While intriguing I'm not sure how much it
proves?

(* this is still good though as any risk is unacceptable and shouting Fire
makes everyone move... and they need to on this issue)

~~~
jgrahamc
There's no memory separation between a web server that incorporates OpenSSL
and... itself.

~~~
danielweber
It might be more accurate if this server ran some services, though, like a
real server would.

------
mikeash
I wonder if one could use this server (or, of course, any other vulnerable
server, but the hostname on this one is nice) for phishing people. For
example, e-mail them the link, then try to snarf the referer header out of the
server's memory in the hopes that their webmail URL contains something juicy,
or give them a fake form that POSTs interesting data to it. Probably far-
fetched, but it's amusing to consider.

------
apaprocki
I seriously don't expect anyone will find anything (reasons mentioned in the
blog post), but that doesn't mean I haven't pointed my exploit that searches
for private key material in the return buffer at it on a one second interval.
If anything I suppose CloudFlare will be able to produce some pretty pictures
of the amount of incoming heartbeats they received!

------
forgotAgain
A different CloudFlare post on HN
[https://news.ycombinator.com/item?id=7572666](https://news.ycombinator.com/item?id=7572666)
claimed that they had a fix for the HeartBleed bug 12 days ago.

 _At CloudFlare, we received early warning of the Heartbleed vulnerability and
patched our systems 12 days ago._

I commented on that post that the date of discovery was 7 days ago
[http://www.vocativ.com/tech/hacking/behind-scenes-
crazy-72-h...](http://www.vocativ.com/tech/hacking/behind-scenes-
crazy-72-hours-leading-heartbleed-discovery/)

For whatever reason that HN post was deleted and resubmitted so it now has no
comments on it.
[https://news.ycombinator.com/item?id=7572796](https://news.ycombinator.com/item?id=7572796)

Was the bug discovered 12 days ago or 7?

~~~
dcu
I'm sure this bug was discovered at least 1 month ago. I would not trust my
keys are safe even if using cloudflare.

~~~
jgrahamc
From the related blog post: [http://blog.cloudflare.com/answering-the-
critical-question-c...](http://blog.cloudflare.com/answering-the-critical-
question-can-you-get-private-ssl-keys-using-heartbleed)

"While we believe it is unlikely that private key data was exposed, we are
proceeding with an abundance of caution. We’ve begun the process of reissuing
and revoking the keys CloudFlare manages on behalf of our customers. In order
to ensure that we don’t overburden the certificate authority resources, we are
staging this process. We expect that it will be complete by early next week."

------
umrashrf
Look what I found...

    
    
      0390: 00 00 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  ..OLOLOLOLOLOLOL
      03a0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      03b0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      03c0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      03d0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      03e0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      03f0: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      0400: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      0410: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL
      0420: 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C 4F 4C  OLOLOLOLOLOLOLOL

------
dredge
For the command to match the description, shouldn't that be "echo -n"?
Otherwise the signed string would include a trailing newline.

I do not expect this will make a material difference to the challenge -
presumably you used the quoted commands to generate the answer.

~~~
pornel
There is no portable way to echo without a newline. Use printf instead.

~~~
jgrahamc
Meanwhile over in a Makefile...

    
    
        # Automatically figure out what echo options to use so that echo
        # '\r\n' actually just outputs the characters CR and LF and nothing
        # else. This is very shell dependent.
    
        ECHO_OPTIONS := -e -n -en
        ECHO :=
        $(foreach o,$(ECHO_OPTIONS),$(if $(call seq,$(shell echo $o '\r\n' | wc -
        c),2),$(eval ECHO := echo $o)))
        ifeq ($(ECHO),)
        $(error Failed to set ECHO, unable to determine correct echo command, 
        tried options $(ECHO_OPTIONS))
        endif

------
koliber
So out of curiosity, I ran the python heartbleed tester against their server.
Surprisingly, the first (and every response thereafter) returned a memory dump
which contained at least part of what looked like a private key. I immediately
became skeptical when each of these apparent private keys ended in LOLJK.

    
    
      0690: 79 37 70 71 31 76 63 2F 74 70 49 67 68 4C 4F 4C  y7pq1vc/tpIghLOL
      06a0: 4A 4B 3D 3D 2D 2D 2D 2D 2D 45 4E 44 5F 52 53 41  JK==-----END_RSA
      06b0: 5F 50 52 49 56 41 54 45 5F 4B 45 59 2D 2D 2D 2D  _PRIVATE_KEY----
    

Seems like a clever setup to return hand-crafted responses.

~~~
zenojevski
Got that too:

    
    
      1ef0: 4E 63 46 39 33 51 75 34 64 2F 48 6E 47 6D 4B 50  NcF93Qu4d/HnGmKP
      1f00: 51 42 72 4A 43 50 53 69 54 67 70 2F 63 79 37 70  QBrJCPSiTgp/cy7p
      1f10: 71 31 76 63 2F 74 70 49 67 68 4C 4F 4C 4A 4B 3D  q1vc/tpIghLOLJK=
      1f20: 3D 2D 2D 2D 2D 2D 45 4E 44 25 32 30 52 53 41 25  =-----END%20RSA%
      1f30: 32 30 50 52 49 56 41 54 45 25 32 30 4B 45 59 2D  20PRIVATE%20KEY-
      1f40: 2D 2D 2D 2D 20 48 54 54 50 2F 31 2E 31 0D 0A 48  ---- HTTP/1.1..H

Curiously enough, one of the first responses, after which they became somewhat
predictable (with the occasional "herring").

Seems like some experimenting (based on differing offset, and `%20` vs `_`).

------
AshleysBrain
Would a multi-process server engine help protect against this? Think what
Chrome does with tabs. If the network request is received by a dedicated IO
process which then uses IPC to communicate with other parts of the server,
then perhaps sensitive information like keys would not be in the same address
space so could not be leaked? I guess if the bug was in a sensitive process
then it would still happen. Disclaimer: I have no idea how modern servers are
architected, perhaps they already do this :) Would be interested to hear from
anyone more knowledgeable.

~~~
X-Istence
The keys would be in the same process as the one doing the SSL in the first
place, and that is the part that is vulnerable.

Even communicating over IPC you would still be vulnerable.

------
rubiquity
If what CloudFlare is saying is true (and I think it is), that the only
possibility of Nginx/Apache leaking the private key is on start up due to how
low of a memory address the private key is given, is there anything in
Nginx/Apache to fire a bunch of dummy requests at itself before accepting
public connections? This should effectively bury the memory address that the
private key is stored in. Would this be useful if it doesn't exist or would it
only be useful in hindsight?

~~~
diminoten
Anyone know of a quick way to force nginx to restart?

~~~
rubiquity
Haha, that's what I've been thinking about since this was posted as well :)

------
kurokikaze
Someone POSTs the "BEGIN SECRET KEY" strings and such to server. Funny thing
is, key is probably stored as binary and without file header/footer.

------
Robadob
Where it might not be possible to get SSL private keys directly via
heartbleed. Is there not also the possibility of exposing reused credentials
or something that exposes a further exploit that could provide root access or
similar to a server, allowing the retrieval of these keys?

It may not be possible in this clean minimal install, but in a real production
environment, it should still be treated as a threat?

------
daedalus2027
I have got this header:

OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 Host:
www.cloudflarechallenge.com Accept: _/_ PrivateKey:
EiS3mdBFanVEaeRkk4otJRRHFTGi6tVZUJKl5v7rGpjJnY0gTn4PWSlOJqA2l32o Content-
Length: 1721 Content-Type: application/x-www-form-urlencoded Expect:
100-continue

[http://pastebin.com/FLcsYDfE](http://pastebin.com/FLcsYDfE)

~~~
loopdoend
That is somebody trolling you by modifying their request headers.

------
alienvenom
hmm, all I'm getting is a bunch of dicks...

    
    
      0600: 20 38 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 44 20 20   8===========D
      0610: 20 38 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 44 20 20   8===========D
      0620: 20 38 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 44 20 20   8===========D
      0630: 20 38 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 44 20 20   8===========D

------
NKCSS
Too bad the link they give on that page doesn't exist (yet):
[http://blog.cloudflare.com/the-heartbleed-
challenge/](http://blog.cloudflare.com/the-heartbleed-challenge/)

~~~
jgrahamc
Sorry about that. It's meant to redirect to:
[http://blog.cloudflare.com/answering-the-critical-
question-c...](http://blog.cloudflare.com/answering-the-critical-question-can-
you-get-private-ssl-keys-using-heartbleed)

------
kaivi
Found this among the returned data:
[http://cl.ly/image/2o391V1T2R46](http://cl.ly/image/2o391V1T2R46) Who would
request that much lorem ipsum nonsense and for what purpose?

~~~
spydum
perhaps to push the memory allocation for url out a bit wider, to get a
segment of memory in a different place?

------
benmmurphy
so i assume any intermediate values from the RSA computations will end up in
the heap and may be accessible by an attacker. is it possible to reconstruct
the key from these values?

i could be missing something but it looks like signing does m mod p and m mod
q and part of these operations involves doing a left shift on the divisor (p,
q) and this is allocated to a temporary buffer. if these buffers are allocated
near the heartbeat buffers then they could be leaked.

i'm looking at crypto/rsa/rsa_eay.c and it is possible that this code is not
the code that is being used to do the signing in ssl.

    
    
        /* signing */
        static int RSA_eay_private_encrypt(int flen, const unsigned char *from,
                 unsigned char *to, RSA *rsa, int padding)
            {
    
        ..
        ..
    
                if ( (rsa->flags & RSA_FLAG_EXT_PKEY) ||
                    ((rsa->p != NULL) &&
                    (rsa->q != NULL) &&
                    (rsa->dmp1 != NULL) &&
                    (rsa->dmq1 != NULL) &&
                    (rsa->iqmp != NULL)) )
                    {
                    if (!rsa->meth->rsa_mod_exp(ret, f, rsa, ctx)) goto err;
    
    
      static int RSA_eay_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
            {
    
      ..
      ..
    
    
              /* compute I mod q */
            if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
                    {
                    c = &local_c;
                    BN_with_flags(c, I, BN_FLG_CONSTTIME);
                    if (!BN_mod(r1,c,rsa->q,ctx)) goto err;
                    }
            else
                    {
                    if (!BN_mod(r1,I,rsa->q,ctx)) goto err;
                    }
    
    
      ..
      ..
    
    
              /* compute I mod p */
            if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
                    {
                    c = &local_c;
                    BN_with_flags(c, I, BN_FLG_CONSTTIME);
                    if (!BN_mod(r1,c,rsa->p,ctx)) goto err;
                    }
            else
                    {
                    if (!BN_mod(r1,I,rsa->p,ctx)) goto err;
                    }
    
      #define BN_mod(rem,m,d,ctx) BN_div(NULL,(rem),(m),(d),(ctx))
    
    
      int BN_div(BIGNUM *dv, BIGNUM *rm, const BIGNUM *num, const BIGNUM *divisor,
               BN_CTX *ctx)
    
      ..
        sdiv=BN_CTX_get(ctx);
      ..
        if (!(BN_lshift(sdiv,divisor,norm_shift))) goto err;
    
    
      BN_lshift() shifts a left by n bits and places the result in r (r=a*2^n).
    

EDIT: obviously if you leak p and q you can trivially reconstruct the private
key :) but it is possible other intermediate values might be leaked as well
that allow for key reconstruction.

though, considering left shifted p and q look a lot like normal p and q i'm
surprised no-one has found this by just searching through the leaked data. so
maybe this is not leaked or it requires a read at the correct time because
these buffers might be trashed by another computation.

~~~
daeken
> maybe this is not leaked or it requires a read at the correct time because
> these buffers might be trashed by another computation.

As far as I can tell, it's certainly possible for intermediate data to be
leaked, but it'd require pretty spectacular timing.

That said, I'm having a bit of a hard time understanding why this challenge
exists. If the possibility (even remote) exists that key material was leaked
in any form, it should be assumed that the key material was leaked in the
worst possible way, and that everything is compromised. They seem to agree,
having rolled their keys.

The only real effect I can see from this challenge existing is that people
will see it and make the assumption that Heartbleed is "not a big deal,
because Cloudflare's keys weren't leaked".

In other words, I think this challenge is harmful to security overall;
Cloudflare seems to be doing the right thing, but the messaging here is going
to cause people to not follow suit.

~~~
benmmurphy
i've locally tested the BN_div function and the sdiv buffer is intact at the
end of the function with a p or q value. however, the BN values seem to be
allocated in some kind of pool and they are reused so the private keys get
clobbered by another BN function soon after. also, at the end of the
RSA_eay_private_encrypt function the BN values are zeroed (or written over
with crap data) so unless there is another implementation bug it should be
impossible to leak the intermediate values in a single threaded
implementation.

leaking the intermediate values in nginx to recover the private key looks like
a dead end. however, i think this could be quite promising for apache
mpm_worker. :)

~~~
makomk
So it looks like you might be right. Debian uses Apache mpm_worker by default,
and after getting a test install running and using ab to provide load I
managed to get the private key in under a minute on the first run:
[http://t.co/nYvIw7q4M8](http://t.co/nYvIw7q4M8) (I was lucky the first time,
usually it seems to take a little longer.)

------
livid
ssl_certificate /home/nick/ssl-bundle.crt

ssl_certificate_key /home/nick/server.key

~~~
fla
Got that one too. Also got this [1] but it looks like public keys maybe ?
I'dont have time to check right now.

[1] [http://pastebin.com/KiVNV0c6](http://pastebin.com/KiVNV0c6)

~~~
M4v3R
I got this, but I have too little time to verify whether it actually contains
key information or not:
[http://pastebin.com/0CRw6hSy](http://pastebin.com/0CRw6hSy)

Edit: It seems that these are only trusted CA certs, there is no server cert
in there.

------
batmansbelt
Don't be surprised when the winner has an @nsa.gov email address.

~~~
dfc
I would be shocked if Neel was wrong about private key exposure AND it is a
nation state that highlights his misunderstanding.

~~~
fulafel
Cloudfare isn't making the same claim - they're just saying it doesn't seem to
happen on their (modified) Nginx setup.

~~~
dfc
I do not understand what you are trying to convey in your message. I never
mentioned Cloudflare and neither did the comment I was responding to. What
part of my comment led you to believe I was presenting/responding-to a claim
made by cloudflare?

~~~
fulafel
The article is about Cloudfare saying their keys are safe. We were discussing
implications of someone winning the Cloudfare challenge. You suggested the
fall of the challenge would confirm Neel being wrong? I was alluding to Neel's
position that that any key leaking is "unlikely" \- a much more tenuous
position than Cloudfare's.

But maybe you meant that he's alrady been proven wrong, and the nsa would be
another? Then I did misinterpret that bit.

~~~
dfc
Too often you seem lame jokes like the original comment that require the
belief that NSA is leaps and bounds ahead of the world in infosec AND yet NSA
is composed of bumbling morons. NSA would be grossly incompetent if they knew
how to retrieve the private key AND then informed the world of their offensive
capability. This is a basic tenet of intelligence operations, you do not
publicize your capabilities to your adversaries.

The renowned clandestine operative B.Smalls, eloquently stated rule #2:

    
    
      Never let 'em know your next move
      Don't you know bad boys move in silence and violence?

~~~
batmansbelt
> leaps and bounds ahead of the world in infosec AND yet NSA is composed of
> bumbling morons

That's the joke. It's a nutty professor situation.

------
ig1
Is this running on an off-the-shelf nginx or your custom version ?

~~~
jgrahamc
The challenge web site is running stock NGINX.

------
Diastro
Anyone know what the comodoca cert are all about?

------
remon
I must be the only one that's pretty much done with having to read about
heartbleed.

~~~
SchizoDuckie
My guess is that if this gets exploited this is going to be used in
combination with another (yet unknown) bug. Now all we can do is set back and
hope the white hats prevail

------
attheodo
perfect attempt to steal 0day spl0its :P

