einaros

Sure. That's not really my issue though. I got a few thousand followers, in batches, after random press coverage through the years, but never had much of anything I wanted to share. Trying to communicate anything, to build further following, was stressful, unfruitful and ultimately meaningless.

I've never (within otherwise normal times) been more stressed out and miserable than during periods when I've tried to interact systematically with and through Twitter.

I’ve been meaning to translate the WebGL version embedded there, but never got that far. The downloadable versions (linked under the video) for Windows and Mac both have subtitles of the audio log, as well as the UI. And both have more correct lighting than the video clip that’s embedded on the page.

Not entirely sure what you mean by that. But I realised some time ago how lucky, and extremely privileged, I was to grow up with the unconditional support my mother gave me.

And I wasn't the only one to get her support. She was a social worker who dealt with the very heaviest of drug users. She worked tirelessly to help them get a grip on their lives, and often spent her spare time following up on their troubles.

She, and others like her, contribute actual good to this world. I, with all of my inhibitive worries and hollow ambitions, admire them infinitely for that.

Thank you. I'm very sorry to hear that your mother passed so early. Missing someone, even after many years, is a testimony to the strong bond you shared. The loving memory lives on.

Thank you, although I feel much more sorry for her loss, than I do for mine. Cancer stole her life at a time when everything was supposed to be getting better. A brutal reminder for everyone around her to make the most of their time. And to appreciate loved ones while they're there.

Mother's day or not, those who can make that call, should. My mother passed away one week ago. I really, really wish I could call her today.

https://encrypt.today - who said the new TLDs were useless?

Ah. Well if you want to dig, I've still got the 43 GB from CloudFlare!

I didn't actually write mine to collect primes :) I'm working with data dumped from other network devices, and for the most running various Yara rules during and after collection.

Doing realtime prime detection is trivial in mine as well. Either pipe the outfile or add to the lib. I didn't write the dump tool with keys as primary target; they just happened to be there.

No, the primes (and thus key) can be retrieved at any time, but it may be more frequently found right after reboot.

I would recommend you to gather at least a gigabyte before digging for the key - preferably more. I dumped 43 GB from CloudFlare on Sunday, and found the prime 194 times in that dump. It can be found in much less time, however. Here's a test I just did against the CloudFlare server, resulting in the full prime 34 times in 60 seconds: https://twitter.com/einaros/status/456136820913238016

The code from the second posted you noted (https://news.ycombinator.com/item?id=7577659) isn't mine. That one builds off of the original Python PoC, which fails for a lot of configurations.

The Github code is the first publication I've done. Let me know if you see a server that's vulnerable, that the Github code fails to detect.

I've published another toolset in Python here: https://github.com/einaros/heartbleed-tools

The final test I did before publishing yielded ~100Mbit/sec of bleed from the challenge server, and had the prime in a few secs.

I also detailed a couple of other challenge observations here: https://hacking.ventures/rsa-keys-in-heartbleed-memory/

Could you shed some light on how this research was conducted? From reading the OpenSSL source and docs it seems pretty clear that the RSA struct will be on the heap somewhere.

That would pretty much cover the use of CDNs that have proper versioning schemes.

Analytics, however, will remain something I'm not overly fond of. For many sites it's unnecessary. For others it's something they could nearly just as easily license and deploy to their own servers. Pulling scripts in from Google Analytics, Statcounter and others -- and especially into privacy concerned apps -- is downright irresponsible.

As I noted here: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve..., even Norway's tax returns site (which hosts info I'd rather not have in any foreign company's hands) use external analytic scripts. They and 90% of the rest of the internet.

No wonder the NSA claim they can circumvent most HTTPS encryption.

While an absolute necessity, it doesn't solve the immediate issue of NSLs and widespread use of unnecessary services.

Let's say that the NSA would like to track bitcoin transactions through MtGox. I don't know how easy it would be for them to plug a backdoor into a server in Japan, and let's assume that the NSA can't break the RC4 crypto their web server is configured to use ..

Since MtGox uses Google Analytics, and possibly pull other scripts from Google's CDN, they could either eavesdrop on whatever data comes back from them by default -- or insist that changes are made to ... pick up more.

Where did you read that it's mail traffic they were after? I'm beginning to strongly believe that it's Google's other services are considered for use in specific attacks.

Imagine if some foreign service, that is outside of an NSL's reach, has communication that the NSA wants to snoop on. If they can't break the crypto, but that service happens to load jQuery off of Google's CDN, or use Google Analytics, the NSA could pull a MITM attack and manipulate the content of the requested scripts.

Those scripts could rather easily act as proxies for the NSA or others, and either hijack sessions or pull data straight out of the protected services.

I'm tooting my own horn here, but that's exactly the kind of thing this blog post speculates on: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

This doesn't just affect services that are hosted by Google, but also encrypted sites that pull scripts in from Google Analytics, Google's CDN, etc.

I wrote a semiparanoid rant about this a couple of days ago ... but didn't think I'd be this close to the truth.

https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

And here I was thinking I was being an all paranoid nutter when I expressed privacy concerns with US hosted CDNs and analytics services ..

https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

Firefox: "about:config" and "media.peerconnection.enabled = false"

That works quite well.

I've been doing the same for http://einaros.github.com/http-tunnel for some time now; it essentially establishes a tcp tunnel over a custom http upgrade protocol and allows reverse http / https requests to pass through that - thus allowing nat'ed or heavily firewalled hosts to publish web stuff through a public address.

That is very strange, but sadly not unexpected. There has been a lot of noise lately, with the websocket draft changes in new browser versions.

Would you mind sending me a dump of whatever error messages the chrome console shows? If there are none, could you perhaps send a screenshot of the last page of connections from the chrome network tab? I'd be wickedly grateful!

My username at gmail.com is my email.

Here's an example replay: http://draw.2x.io/replay#/history/wt/978429455589549135/dl

The db should probably be split across more mongodb instances, as it quickly grows wickedly huge - but granted a bit of patience, it does work.

Uses node.js, socket.io and express.js as server. Strokes are stored in mongodb, and cached gzipped for replays. The current state is also preserved on the server, using node-canvas.

An example of the replay feature: http://draw.2x.io/replay#/history/Mulm/1441464748552271684/d...

This is arguably just a fun project, not aimed at anything commercial at all, so don't expect it to look like such.

Worth noting: socket.io currently doesn't support hybi10, the websocket protocol as implemented in Chrome 14 and later. The people behind socket.io are working on that.

Yes. Custom implementation I never updated beyond the very basics. There has since been released a better node.js canvas by LearnBoost.

The server had a hard time dealing with the load. I suspect running node.js on Cygwin contributes negatively in that regard. Furthermore, my custom serverside canvas could probably benefit from being asynchronous, and the server really should batch up updates within a certain time frame, to not hammer other clients.

The server is being hammered pretty hard at the moment. It's taken on 30-40 simultaneous users before, and worked without a glitch. Now it's around 50, and a few seem to be going beyond the normal update rate.

At some point I will have to enforce a harder rate limit, and/or build better spam protection. The app has been pretty much unused for the last 5 months though, so there hasn't been any real reason to focus on that part :)

Duely noted. For the next version of the public board I'll do that!

Sorry about that. FF has websocket support disabled for now, and I've been slow to move to socket.io. That, and plenty other updates, are in the works. :)

I feel conflicted about doing this: http://www.youtube.com/watch?v=jULOA7mSOac&fmt=22