Anyone know what the comodoca cert are all about?
The Heartbleed Challenge
61–70 of 125 posts
Re: The Heartbleed Challenge
#62Earlier quoted context omitted.
Cloudfare isn't making the same claim - they're just saying it doesn't seem to happen on their (modified) Nginx setup.
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?
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.
Re: The Heartbleed Challenge
#63I 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
Re: The Heartbleed Challenge
#64Someone POSTs the "BEGIN SECRET KEY" strings and such to server. Funny thing is, key is probably stored as binary and without file header/footer.
Re: The Heartbleed Challenge
#65[deleted]
Re: The Heartbleed Challenge
#66Would 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.
Re: The Heartbleed Challenge
#67I 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.
Re: The Heartbleed Challenge
#68Earlier quoted context omitted.
I'm disgusted they chose to share it with you early and not the major Linux distros...
There's no way to share such a bug with the major Linux distros and let them deploy a fix to users without making it public at the same time. Even assuming that the distros commit to handle the fix submission and silently repackage openssl (which they don't always do, depending on their policy), the word would get out minutes after it's pushed to the update servers. So telling major Linux distros == telling the publi…
You would think that they could easily work on in advance of incidents who they can trust to with early information. I'd be amazed if Canonical (Ubuntu), Redhat (RHEL) and The Attachmate Group (SUSE) wouldn't show discreet discretion. I don't know about Debian and similar projects, but you would think they could determine this in advance.
Re: The Heartbleed Challenge
#69Earlier quoted context omitted.
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?
we appreciate your supportive comments :) there are about 10 of us at conformal.
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.
Re: The Heartbleed Challenge
#70Earlier quoted context omitted.
I'm disgusted they chose to share it with you early and not the major Linux distros...
There's no way to share such a bug with the major Linux distros and let them deploy a fix to users without making it public at the same time. Even assuming that the distros commit to handle the fix submission and silently repackage openssl (which they don't always do, depending on their policy), the word would get out minutes after it's pushed to the update servers. So telling major Linux distros == telling the publi…
The fix wasn't a massive one. Even without giving details they could have let the distros know that an emergency release of OpenSSL was coming.