Cornell Will Reveal Secret Academic Journal Pricing - <AUTHOR> http://www.techdirt.com/articles/20110323/02473713592/cornell-library-rejects-non-disclosures-journal-pricing-will-reveal-all-prices.shtml

<comment><USER2> One of the most astounding aspects of academic research, to me, is the price of journal publication.

When you author a book, you earn some money. Not a lot, perhaps, but some. When you author a journal paper, not only do you not earn any money, but you _pay_ the publisher several thousands USD in fees! For example, Nature: <http://www.nature.com/ajg/open_access_faqs.html>. Even worse, you must sign a copyright form that transfers ownership to the publisher.

I understand that there is a staff behind the scenes that puts these publications together -- editors, admin. staff, etc. -- and they need to be paid. But some journals have acquired such prestige over the years that they can name their price, and the manuscript submissions will keep coming. So perhaps these prices are not so surprising.

In the debate over which makes the most impact -- journal vs. conference paper -- most academics will say the same thing: journal, journal, journal. That message has been beaten into our heads. But in my opinion, we are entering a new period of transition similar to what newspapers have been facing. I think it is possible that conferences and journals with new subscription models will slowly usurp a share of manuscript submissions away from journals with traditional models. For example, in ACM and certain IEEE disciplines, conference papers already reign as the preferred publication format among researchers.

Of course, in other areas such as law and medicine, there is probably no hope. Things will remain the way they are.

<comment><USER3> > we are entering a new period of transition

I certainly hope so. I cannot for the life of me understand the economics of academic journals. They do a bit of editing and send out the papers for peer review. And that's about it, right? Where's all the money going?

"Curators" are important, certainly. I want respected people to select articles worthy of publication. I _don't_ want them to then lock those articles up where they're only accessible to academics and those willing to pay obscene fees for individual access.

<comment><USER4> You claim not to understand, but I strongly suspect that you have correctly figured out exactly where all the money's going.

</comment></comment></comment><comment><USER4> "Topology" was the most prestigious journal in its field (i.e., mathematical topology). It and lots of other journals got bought up by Elsevier, who then proceeded to raise the prices to stratospheric levels.

The editors decided they didn't feel like playing along:

<http://math.ucr.edu/home/baez/topology-letter.pdf>

<comment><USER5> Thats awesome, the editors left and started the Journal of Topology, run at significantly lower cost:

<http://en.wikipedia.org/wiki/Topology_(journal)>

[http://www.oxfordjournals.org/our_journals/jtopol/editorial_...](http://www.oxfordjournals.org/our_journals/jtopol/editorial_board.html)

</comment></comment><comment><USER6> This reminds me of the Overprice Tags project by Benjamin Mako Hill of the MIT Media Lab/Sloan. See <http://mako.cc/fun/overpricetags/>

Students at MIT, Brown, and other schools labelled the journals in their libraries with pricetags showing the cost the university was paying for each journal. Nuclear Physics A&B <//elsevier.com/locate/nuclphysa> cost $25,888 in 2005.

Similarly, Students for Free Culture have been working on both the Open University Project and the Open Access Project, pressing universities to reform their use of journals. See <http://freeculture.org/>

Lastly, public universities have been known to disclose the cost of journals they subscribe to -regardless of NDA status- at the issuing of FOIA or CPRA type requests. See <http://en.wikipedia.org/wiki/California_Public_Records_Act>

</comment><comment><USER7> I'm surprised and relieved to see this coming from an Ivy. Huge kudos for moving science forward while leaving the money leeches behind.

<comment><USER8> It is Cornell. They run arXiv and host its primary mirror.

<comment><USER9> Indeed. From the university behind arXiv, this is less of a surprise. Having said that, however, it is obviously a big step and should be applauded by the scientific community at large.

</comment></comment></comment><comment><USER10> Forgive me for being a cynic, but with tuition bills at about $40k per year, ground getting broken on $X0 ~ $Y00 million construction projects yearly, and endowments which rival hedge funds (Cornell's is relatively modest at a mere $4.3 billion dollars), I have to wonder why $4,000 a year for a journal sparks moral outrage and why the solution isn't "Alright, screw it, this is so easy we'll just do it ourselves."

It's like California getting worked up about the number of free donuts they give state employees. I mean, OK, I get it: high symbolism, makes for a good headline. But _come on_ , one look at salaries, pensions, or health care shows where the actual problems are.

Similarly, if one wanted to look at the influence of money on the scientific community, it is highly nonobvious to me that academic journals are where the money is uniquely concentrating.

<comment><USER11> OK, I'll bite. Assuming an average figure of $4,000 per journal per year, how much does will a university like Cornell spend per year on all journals? I work at a smallish European university, and even in my smallish field of the humanities we have access to about a hundred journals (give or take); I dread to think how many journals the university library subscribes to in total, plus dissertation databases such as ProQuest, non-academic periodicals archives, yadda yadda. For something like Cornell, I suspect the figure has to be much higher (more journals, more subscribers).

Plus, it's fine to think that Cornell can afford it; but can a second-rank public university? It probably doesn't, it has neither the money nor the bargaining power. Which means that its academics have limited access to advances in their fields. How can that be fine?

<comment><USER12> It is not about second rank universities. It is about universities in the third world and people who cannot afford to go to universities at all, and it is about the support of universities for open access to learning.

<comment><USER11> Certainly. Everything that applies to second-rank universities in this respect applies to even less advantaged institutions and scholars, magnified.

</comment></comment></comment></comment><comment><USER13> Since copyright only protects expression (at least in countries which haven't introduced protections for databases), couldn't important papers be liberated through a cleanroom process? Say that person A reads the original paper and produces a paraphrase that's intended to be fully accurate and as clear as possible but contains whatever circumlocutions are necessary to avoid reusing the choice of expression in the original paper. This paraphrase is then handed to person B "in the cleanroom" who hasn't seen the original paper. B produces a concise and well-written paper from A's notes. A then reviews B's work, informing him of any misunderstandings that have crept in, still without using the wording in the original paper: this is repeated until A and B are satisfied. All communications between A and B are monitored and retained to prove that the cleanroom was not contaminated.

It would be a fairly slow process, so surely only a small proportion of papers could be put through it. But if the work were focussed on the most important/high-impact papers which are under restrictive copyrights, might it not have a meaningful effect?

<comment><USER14> >" _Since copyright only protects expression [...]_ "

Copyright law protects interests from the effects of copying. Derivative works are not the original expression but nonetheless are restricted by copyright laws and treaties.

In your example A is committing copyright infringement. They're creating a derivative work by copying the original (albeit not slavishly copying). Person B is arguably committing contributory infringement (commercially enabling A) and is certainly copying a work created tortuously; consider it like handling stolen goods.

It's a nice idea but I don't think that copyright law is naive enough to allow this sort of workaround in practice. If it were then foreign language copies wouldn't be infringing and I'm pretty sure that they are.

IANACL

<comment><USER13> Yes, I think you're probably right there.

(IANALAA)

</comment></comment></comment><comment><USER15> I'm a big fan of this move by Cornell, but not, I think for the same reasons as most. First, I can't fault journals for charging fees. After all, they need to make money, and as long as it's a good value, people will pay it.

I like it because it will add some much needed competition into the journal pricing. Most likely, Nature is not going to change their pricing. If you have an article worthy of being published there, most people are going to pay a few grand and be happy to do so just to have their paper published. Assuming publishing prices do become transparent, I don't think it will drastically change the pricing system, but it will allow people to evaluate the value of such a publication.

The best analog I can think of are colleges themselves (and not just because of the academic connection). The value of both colleges and journals are significantly affected by their reputation. The price of the colleges have not leveled out, nor have they gone to zero (closer the opposite of both), but the prices do reflect the perceived "value" of that education. Hopefully the same will happen for journals.

<comment><USER16> I wonder if the assumption "they need to make money" is necessary. If we agree that the actual value of a journal (or its 'profit') is the voluntary participation of renowned scholars, then the journal is at best an administrative function, or a 'cost center' that has to actually be minimized !!

</comment></comment><comment><USER17> It's about time, these idiot troll publishers are on the level of thugs charging store owners for "protection" against same thugs.

Who needs a paper journal anymore?</comment>


To IPO or not to IPO (or the IPO market is actually pretty good) - <AUTHOR> http://www.ustream.tv/recorded/9872677

<comment><AUTHOR> I think this was one of the more interesting discussions at TC Disrupt. At the core, what I got out of it was that the technology IPO market isn't really all that bad. It's just that most (75%) of the companies are outside Silicon Valley and so the SV press doesn't report on them.</comment>


STTR: A system for tracking all vehicles all the time at the edge of the network - <AUTHOR> https://blog.acolyer.org/2018/08/30/sttr-a-system-for-tracking-all-vehicles-all-the-time-at-the-edge-of-the-network/ <comment> d--b It's so sad to see that PhD students spend energy thinking about how to develop such policing systems. I don't understand it. Aren't these guys given any ethics class ? They should use their systems in their labs, tracking where everyone goes all the time, and store that data on one computer system available to the dean of the university (and his friends, the IT guys, and whoever knows about hacking)...

<comment><USER2> Law enforcement might not be the only use for this (although it's the one that springs most readily to mind). E.g. in London there's the congestion charge, which would probably be much more effective in reducing congestion + emissions (or at least loading more costs onto those causing the issue) by charging per mile instead of a flat per day fee.

A system like this would make that possible without requiring a tracker to be fitted to every car, although a growing number of people have these anyway for a reduced insurance premium.

</comment></comment><comment><USER3> STTR is a system designed to track all of the vehicles all of the time, and store their trajectories for ever.

Sounds like it's illegal in Europe due to the GDPR.

<comment><USER4> GDPR restrictions do not apply to government activity, only to private non- personal ones.

<comment><USER3> [http://blog-idcuk.com/are-public-sector-organizations-exempt...](http://blog- idcuk.com/are-public-sector-organizations-exempt-from-gdpr-compliance- absolutely-not/)

After further investigation it seems you are right though that exclusions can be introduced for: * national security; * defence; * public security; * the prevention, investigation, detection or prosecution of criminal offences; * other important public interests, in particular economic or financial interests, including budgetary and taxation matters, public health and security; * the protection of judicial independence and proceedings; breaches of ethics in regulated professions; * monitoring, inspection or regulatory functions connected to the exercise of official authority regarding security, defence, other important public interests or crime/ethics prevention; * the protection of the individual, or the rights and freedoms of others; or the enforcement of civil law matters.

<comment><USER5> At least in the Netherlands, I believe a system like this has been in operation for nearly a decade already. This is of course the only way to do "trajectcontrole" ("average speed checking").

[https://en.wikipedia.org/wiki/Automatic_number- plate_recogni...](https://en.wikipedia.org/wiki/Automatic_number- plate_recognition#Netherlands)

And no worries: there are exceptions.

[https://www.dutchnews.nl/news/2015/09/foreign-diplomats- will...](https://www.dutchnews.nl/news/2015/09/foreign-diplomats-will-no- longer-get-traffic-fines-in-the-netherlands/)

(note: there are more exceptions, like the royal family and the prime minister, but I couldn't find a good article pointing this out)

And of course, the same system is used to catch people with unpaid government bills (started with just tax bills, but has since been expanded).

Interesting aside: the government itself, of course, refuses to pay it's bills on time, instead having legislated that 2 months payment delay (and in some municipalities more) is all that can be expected of government. And of course, in any payment dispute with the government, private individuals and companies have no such options for redress. If you are 1 day late with your taxes however, you can be arrested and imprisoned, anything belonging to you can be impounded and sold with no recourse and of course extra charges for you.

Police have access to the database of all car plates seen anywhere on the system, and have of course been caught abusing this data, as well as using it in many cases where there was no justification, as determined by a judge afterwards. Needless to say, there is zero news on consequences for any police officer for these for some reason.

<comment><USER3> The system of ANPR (Automated Number Plate Recognition) is also used in Belgium. But the maximum retention period for ANPR data is 30 days. Storing this data for an unlimited period is illegal by Belgian law. "Bewaartermijn Indien de opgenomen beelden geen bijdrage kunnen leveren tot het bewijzen van een misdrijf, schade, overlast of tot het identificeren van een dader, een verstoorder van de openbare orde, een getuige of een slachtoffer, dan mogen deze maximaal 30 dagen bewaard worden (De Schepper, 2014). Wanneer de beelden wel bijdrage leveren in voornoemde gevallen, dan mogen deze langer bewaard worden en dienen ze neergelegd te worden ter griffie. In dit geval gelden de termijnen van het verval van de strafvordering. De beelden hebben dezelfde bewijswaarde als een getuigenverklaring (De Paepe et al., 2012)."

<comment><USER5> It seems to me utterly unrealistic that the police actually upholds this law. It never, ever happens that a complaint is correctly fired within 30 days and these images are occasionally reported to be used. The "griffie" is not involved until there is an actual complaint, so those images or data from them is no way deposited there. Furthermore, any action at the griffie will inform the accused, which the police doesn't want to happen in almost any case until they're ready.

This may be law, but it's ignored by law enforcement. I guarantee it. This is totally unrealistic.

</comment></comment></comment></comment></comment></comment><comment><USER6> Why vehicle info(plate, not video) can not be sent to server? I think that trajectory can be computed much easier on a server.</comment>


Show HN: We built Helprace, feedback portal and helpdesk. Do people need it? - <AUTHOR> http://helprace.com

<comment><AUTHOR> Hey there, we're a small team trying to make it big in the customer service software market. You probably know software such as Zendesk and UserVoice, which are designed to address customer service requests. We've created Helprace, which does the above and offers a feedback community to the business owner on top of that.

Issue 1: We don't know if people actually want a feedback community. We had ONE customer who encouraged us to develop it. So a user, would you want your questions & ideas be publicly visible, in other words would you go through the trouble of posting it? Would love to hear your take on this!!

Issue 2: We launched our homepage without much feedback. Upon visiting, -What do you think it can help you with -What's the number 1 reason that is stopping you from buying? -What's your biggest concern about this product or service? -Is there anything that is confusing on this page?</comment>


The Heartbleed Bug - <AUTHOR> http://heartbleed.com/ <comment><USER5> 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.

<comment><USER6> 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.

<comment><USER7> 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?

<comment><USER8> 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.

<comment><USER7> 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.

</comment></comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> 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/

<comment><USER11> 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.

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

<comment><USER11> 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.

<comment> 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)

</comment></comment></comment></comment></comment></comment><comment><USER12> 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.

<comment><USER13> Would love to see the code and test it against a rebuilt a patched nginx.

<comment><USER14> Just run it against it?

<comment><USER13> 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.

</comment></comment></comment></comment><comment><USER15> 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.

<comment><USER16> 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.

<comment><USER17> Shouldn't Perfect Forward Secrecy protect against exactly this kind of scenario where the server's primary keys are compromised?

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

<comment><USER17> 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.

</comment></comment></comment></comment></comment><comment><USER19> 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 :/

<comment><USER20> 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.

<comment><USER21> 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.

<comment> 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) ...

<comment><USER22> 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)

</comment></comment></comment></comment></comment><comment><USER23> 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).

</comment><comment><USER24> 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)

<comment><USER25> Sometimes things are time-critical.....

<comment><USER26> Ah, the old middle-management excuse: "We don't have time to write tests!"

<comment><USER25> When half the secure internet is on fire... yeah, i think that's an acceptable time.

<comment><USER27> 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.

</comment></comment></comment></comment></comment><comment><USER28>
      ./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 - <USER2>

</comment><comment><USER29> 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.

<comment><USER16> Writeup was too long. We need to know the short and sweet of what to fix.

<comment><USER30> Update to 1.0.1g, redo all crypto. That is, revoke certs and keys and regenerate.

<comment><USER31> 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.

<comment><USER32> 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.

<comment><USER31> Apologies, my mistake. I'd redact my comment if I was able to.

</comment></comment></comment></comment></comment></comment><comment><USER33> 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?

<comment><USER34> 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.

<comment><USER35> 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.

<comment><USER36> 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.

</comment></comment></comment></comment><comment><USER10> 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.

<comment><USER37> 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.

<comment><USER38> 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?

<comment><USER25> It might be able to read the memory of the ssl server that's making the response. Including maybe the ssl private key

<comment><USER38> 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).

</comment></comment></comment></comment></comment><comment><USER39> 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.

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

<comment><USER39> 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.

<comment><USER40> Perhaps its time will come soon. That would be really cool.

</comment></comment></comment></comment><comment><USER41> 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?

<comment><USER42> 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.

<comment><USER43> 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.

<comment><USER44> Would you mind emailing me the code? I'd like to learn from it.

<comment><USER43> 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.

<comment><USER44> Ah, understandable. Thank you anyway!

</comment></comment></comment></comment></comment></comment><comment> 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)

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

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

<comment><USER45> 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.)

<comment><USER46> 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).

</comment></comment></comment></comment><comment><USER47> 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.

<comment><USER48> JESUS CHRIST, all sorts of private information. Patch your servers now!

<comment><USER49> 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.

<comment><USER48> There is going to be massive amounts of fraud all over the world for a while because of this bug.

</comment></comment></comment></comment><comment><USER50> 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?)

<comment><AUTHOR> 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.

<comment><USER51> Sooo in layman's terms - we only need to be worrying about HTTPS and not SSH ?

<comment><USER52> 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)

<comment><USER53> 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.

</comment></comment></comment></comment></comment><comment><USER51> 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 ?

<comment><USER54> Because it was already disclosed the instant the OpenSSL release went out and the fix was public.

<comment><USER51> 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)

</comment></comment></comment><comment><USER55> > 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.

<comment><USER56> In addition to that, it obviously disables the TLS heartbeat extension, which would break existing code that uses it.

</comment></comment><comment><USER57> Does anyone know how Amazon's Elastic Load Balancers are affected? I can't find anything on the AWS site

<comment><USER58> 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)

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

<comment><USER60> Any ELB deploys I've done in the last hour seem to be fixed.

</comment></comment></comment></comment><comment><USER61> 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?

<comment><USER62> 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)

</comment></comment><comment><USER63> 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; [...]_

</comment><comment><USER64> 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'?

<comment><USER65> The cost of a cryptography code review is about $5-10k per week.

<comment><USER64> 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_?

<comment><USER65> 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.

<comment><USER64> Thanks!

</comment></comment></comment></comment></comment><comment><USER66> 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?

<comment><USER67> 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 - <USER3> can't really assume those are safe either.

Fun times!

</comment></comment><comment><USER68> 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.

<comment><USER69> 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.

<comment><USER68> 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.

</comment></comment></comment><comment><USER70> 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)

</comment><comment><USER71> 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

<comment><USER29> 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.

<comment><USER72> 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-)

</comment></comment></comment><comment><USER73> Remember that checking services for the OpenSSL heartbleed vulnerability without permission is actually illegal in many countries (UK in particular).

</comment><comment><USER32> 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.

<comment><USER74> 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.

</comment></comment><comment><USER75> 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

</comment><comment><USER76> 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?

<comment><USER77> 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.

<comment><USER78> [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)

<comment><USER78> [https://rhn.redhat.com/errata/RHSA-2014-0376.html](https://rhn.redhat.com/errata/RHSA-2014-0376.html)

</comment></comment></comment></comment><comment> 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 - <USER4> unprotected internet causes widespread damage.

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

<comment><USER79> It is evil to make totally unsupported accusations, even against the NSA. I've downvoted you, twice.

<comment><USER80> 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.

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

<comment><USER80> The difference being I don't have a history of doing such things and then repeatedly lying about it....

</comment></comment></comment></comment></comment></comment><comment><USER81> 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.

<comment><USER82> > 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.

</comment></comment><comment><USER83> 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/)

</comment><comment><USER60> 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.

<comment> rkuykendall-com The "known vulnerability window" is over 2 years.

<comment><USER60> 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.

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

<comment><USER84> Not you. But (someone connected to)+ you.

</comment></comment></comment></comment></comment><comment><USER85> _" Is there a bright side to all this?"_

"Yes, we can sell you our software!"

</comment><comment><USER86> Is it a problem for those using ssh keys on github ?

<comment><USER87> 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.

<comment><USER50> Answers in sibling threads suggest ssh/sshd is not affected, as ssh uses its own protocol other than TLS.

</comment></comment></comment><comment><USER88> 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.

</comment><comment><USER89> 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.

<comment><USER90> 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'

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

</comment></comment></comment><comment><USER91> 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/

</comment><comment><USER92> How widely implemented is certificate revocation?

</comment><comment><USER93> 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?

</comment><comment><USER94> Are people going straight to buying new domain names for every TLS bug discovered these days?

<comment><USER95> I'd be surprised if heartbleed.com was still available in 2014

<comment><USER51> 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)

<comment><USER96> They should probably get the guy who designed heartbleed.com to revamp their own website :)

<comment><USER49> lol.. good one.. agreed!

</comment></comment></comment></comment></comment><comment><USER97> 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= firstname.lastname@example.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

</comment><comment><USER98> Has anybody seen or created a PoC for this yet?

<comment><USER98> 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)

</comment></comment><comment><USER99> 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)

<comment><USER80> 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 :/

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

<comment><USER100> It's been patched since, and is no longer vulnerable.

</comment></comment><comment><USER101> 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.

<comment><USER102> Is openssl in nginx statically linked by default? If so: ouch.

</comment></comment><comment><USER50> 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?)

<comment><USER54> 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.

<comment><USER103> Sidenote, OS X machines, by default, are not affected by this bug.

$ openssl version -a OpenSSL 0.9.8y 5 Feb 2013

</comment></comment></comment><comment><USER104> Some Facebook servers are vulnerable for the Heartbleed bug: [http://pastebin.com/dmYYpx2y](http://pastebin.com/dmYYpx2y)

</comment><comment><USER105> 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/)).

<comment><USER106> 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.

</comment></comment><comment><USER107> 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?

<comment><USER108> 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.

</comment></comment><comment><USER109> 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.

</comment><comment><USER110> 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.

<comment><USER111> 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

</comment></comment><comment><USER112> 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.

</comment><comment><USER113> Can some people who are smarter than me give us the flags we would like to compile this with manually?

<comment><USER114> 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

<comment><USER113> Figured there might be more than just that flag you'd want to compile with.

<comment><USER77> 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.

</comment></comment></comment></comment><comment><USER115> 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.

<comment><USER116> How do you know your CA isn't vulnerable?

<comment><USER115> 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.

</comment></comment></comment><comment><USER117> So now that NSA can steal private keys, all the logs they collected over the years can be decrypted?

</comment><comment><USER118> 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)

</comment><comment><USER119> 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)

</comment><comment><USER120> 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)

<comment><USER121> 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.

</comment></comment><comment><USER122> 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 ?

<comment><USER123> 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?

<comment><USER122> Its only a development environment so my risk is fairly low, However I was just curious, its an Amazon ELB.

</comment></comment></comment><comment><USER124> 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.

<comment><USER120> Got links?

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

</comment><comment><USER126> 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.

</comment><comment><USER127> 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?

<comment><USER128> 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.

</comment></comment><comment><USER129> 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?

<comment><USER130> 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.

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

</comment><comment><USER132> Scary what the implications of this will be for OpenVPN traffic that has been captured and stored over the past 2 years.

<comment><USER133> 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.

</comment></comment><comment><USER134> gentoo has a flag for the TLS heartbeat, so its easy to turn off.

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

<comment><USER135> 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).

</comment></comment><comment><USER136> Any scope here for SSL companies to actually have to make good on warranties they offer here?

</comment><comment><USER137> So, many certificate authorities will need to re-issue certificates?

</comment><comment><USER138> We use openvpn. Does that need to be updated?

<comment><USER139> 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.

</comment></comment><comment><USER140> Love this

> Is there a bright side to all this?

</comment><comment><USER141> Does linux sshd have this bug ?

</comment><comment><USER142> Mirror please?

</comment><comment><USER143> They should call their team AnttiMattR

:"(Riku, Antti and Matti)

</comment><comment><USER144> 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?

</comment><comment><USER145> "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

</comment><comment><USER146> 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)</comment>


Local Topological Analysis of Complex Systems (2017) [video] - <AUTHOR> https://www.youtube.com/watch?v=1Id3Gu18MME <comment><USER2> Thanks for posting the sheaf talks a while back, been getting into em. Also found this he made [https://arxiv.org/abs/1603.01446](https://arxiv.org/abs/1603.01446)

<comment><AUTHOR> Thanks. You might also like this talk by Edward Kmett on Propagators (not a talk on sheaf theory, but it touches on similar ideas) -- I having been thinking on how to unify the ideas in _sheaf theory_ with _propagators_ and would be curious if others see similar connections:

Edward Kmett on Propagators [https://www.youtube.com/watch?v=DyPzPeOPgUE](https://www.youtube.com/watch?v=DyPzPeOPgUE)

"Propagators" as introduced by Sussman et al. from MIT a few years back:

The Art of the Propagator [http://groups.csail.mit.edu/mac/users/gjs/propagators/](http://groups.csail.mit.edu/mac/users/gjs/propagators/)

We Really Don't Know How to Compute [https://www.infoq.com/presentations/We- Really-Dont-Know-How-...](https://www.infoq.com/presentations/We-Really-Dont- Know-How-To-Compute) (Sussman at StrangeLoop)

Constraints and Hallucinations: Filling in the Details [https://www.youtube.com/watch?v=mwxknB4SgvM](https://www.youtube.com/watch?v=mwxknB4SgvM) (Sussman at Google)</comment></comment>


Companies Start to Think Remote Work Isn't So Great After All - <AUTHOR> https://www.wsj.com/articles/companies-start-to-think-remote-work-isnt-so-great-after-all-11595603397 <comment><USER2> Take Linux for example, or Wikipedia, they all go to the office, hence their success :P

Now seriously, my company is too big and it is split across different US states and continents, there is not such a thing as an office, everything is done by email, teams and Git.</comment>


Stanford Class2Go - <AUTHOR> https://github.com/Stanford-Online/class2go

<comment><USER2> This is intriguing:

Professors have access to the classes' data to learn how their students learn. We will facilitate experiments. For example, we intend this to be the best plaform for running A/B/N tests to measure the impact of different teaching methods on student outcomes

That they're giving data driven decision making such a prominent place is great. I would like to know more, though.

Having taught before at the University level I know it's a ton of work. It's even more work if you're developing parallel versions of a course for testing purposes. So the A/B feature had better be really easy to use.

There is also the ethical issue of giving students a worse performing variant of the class. The solution here is to use a bandit algorithm or an early stopping method to find the best variant as quickly as possible.

Finally, I think the Coursera model where everyone runs through the course on the same schedule is not optimal for experimentation. It doesn't allow for a tight feedback loop, because you have to wait N weeks before you can experiment with changes on the next cohort.

</comment><comment><USER3> Stanford is hosting the Intro to Databases class [1] on class2go, while the previous run was hosted on Coursera.

[1] <http://news.ycombinator.com/item?id=4880112>

<comment><USER4> I thought this was pretty annoying, actually. I was used to Coursera already, but had to create new logins, etc. Then I was confused because Coursera listed (and still lists) the DB course as coming soon at the same time leading up to the Class2Go version. :-( I'm slightly disappointed by the muddled way it was carried out.

</comment></comment><comment><USER5> The main objects in the code base can be examined here: [https://github.com/Stanford- Online/class2go/blob/master/main...](https://github.com/Stanford- Online/class2go/blob/master/main/c2g/models.py) It looks like nice functionality that any online educational product could use. I certainly hope to use

Also of interest is the urls.py which shows you all the different aspects of the web application. [https://github.com/Stanford- Online/class2go/blob/master/main...](https://github.com/Stanford- Online/class2go/blob/master/main/urls.py)

Good stuff.

</comment><comment><USER6> We were able the 'main' app booted after adding a requirements.txt: <http://class2go.a.pogoapp.com/>

It would be nice if you could separate out the ops infrastructure from the actual application, to suit a wider variety of deployment scenarios.</comment>


I would appreciate it if you take a look to my ios mobile game - <AUTHOR> https://itunes.apple.com/app/id1436205855?ls=1&mt=8 <comment><AUTHOR> I want to increase the number of my new ios game's downloads,but I have a very limited advertising budget. I would appreciate it if you download it.It is free to download. The style of the game is similar to the <Rise Up> game.</comment>


RT's Abby Martin speaks out against Russian invasion of Crimea 3/3/2014  - <AUTHOR> https://www.youtube.com/watch?v=ZolXrjGIBJs

<comment><USER2> I love the RT news channel but cannot comprehend what good any military action by Russia will bring.

Well done to Abby for adding her strong personal opinion, not to be outvoiced by that of the state.

</comment><comment><USER3> Well done. That is a real free and open media</comment>


Backbone.js sample app with Sinatra Backend - <AUTHOR> http://afewgoodlines.com/post/1329452279/a-backbone-js-demo-app-sinatra-backend

<comment><USER2> That was quick! I was wanting to see some sample apps with backbone, thanks for sharing.

By the way, if you have the .0.1.1 release, you can call this.handleEvents(); inside of the initialize() function on the template instead of the render() function. This prevents having to rebind the element every time you call render. This probably won't be a huge issue considering that you are only binding one event each time, but it is probably best practice anyway.

</comment><comment><USER3> Unfortunately, the example app is fairly broken and quickly XSS'd at the moment. Hopefully Ryan can fix it up.

EDIT: Yep -- quickly fixed and deployed. Thanks, Ryan.

<comment><AUTHOR> thanks for the making me aware of .html() and .text() :)

</comment></comment><comment><USER4> Another one chiming in to say thanks. Backbone is really intriguing and this post does a nice job of walking through the basics of how to use it.

</comment><comment><USER5> Thanks for this. Just in the process of migrating my app to Backbone.js.</comment>


How do you find team members for your projects? [RESULTS] - <AUTHOR>

Hi everyone,
As promised,  I wanted to share the results of the survey that I posted a couple of days earlier.
In total, we collected a 142 responses, with some very interesting and helpful feedback!
To see the complete rundown of the answers, go here: http://infogr.am/CoCreately-Survey/ (Conclusion and summary at the bottom).
Also, if you want to find out how we're planning on solving these dreadful challenges in finding suitable team members, you can sign up to be notified when we launch at http://cocreately.com (we might even ask you if you want to beta test the thing!).
We are planning on doing another survey soon, to gather some insight on how we can best engage people who are looking for projects to work on that are not their own. We would love to hear your thoughts on the matter!
Love, Martin @ CoCreately <comment><USER2> Clickable link: <http://infogr.am/CoCreately-Survey/>

<comment><AUTHOR> Thanks!</comment></comment>