This is an archive of past discussions about Heartbleed. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I like the last paragraph that explains what providers (hardware and software) have learned from the Heartbleed stealth and evil attack. But there are also lessons that could be noted concerning what Internet users have learned. How can we be more vigil? What have we learned? A new concluding section could be added, or noted elsewhere in the article herein. — Charles Edwin Shipp (talk) 01:01, 20 April 2014 (UTC)
An example: Wikipedia is on the 'affected' list. What I've learned is to logout and disconnect my ethernet cable. The option upon logging in to Wikipedia, "Stay connected for 30 days" is not a good option, in my opinion. Charles Edwin Shipp (talk) 19:30, 21 April 2014 (UTC)
I've removed this[1] for a number of reasons. First of all, it is original research to connect it to this article's topic. It doesn't even mention Heartbleed. See WP:SYN. Second, it is poorly sourced. Citing press releases is usually not a good idea. Instead we should rely on third-party reliable sources which have a reputation for accuracy and fact-checking. Third, it is out of date and was written before Heartbleed. A Quest For Knowledge (talk) 06:08, 21 April 2014 (UTC)
I think this should be a pretty noncontroversial removal. It seems quite obvious that the content was added as an originally researched counterargument to the preceding claim. – FenixFeather(talk)(Contribs)07:06, 21 April 2014 (UTC)
I'd be inclined to throw out the whole paragraph based on the article by Damien Choizit. Mr. Choizit's article seems to be a lot of platitudes but without much in the way of hard facts. And anyone who considers "open-source code" and "outsourced code" to be the same or similar doesn't know what he's talking about. RenniePet (talk) 13:52, 21 April 2014 (UTC)
He seems to conflate open source and nonproprietary too. In any case, I think the paragraph is a bit too long and redundant. It could be reduced to one sentence saying "It has also been suggested that because OpenSSL is developed by volunteers, it has not undergone the rigorous testing that proprietary software would undergo." or something. No need to mention this guy by name multiple times when we don't even know how he's connected or especially qualified to talk about the issue. – FenixFeather(talk)(Contribs)14:06, 21 April 2014 (UTC)
It may be possible to shorten the paragraph but the suggestion is inappropriate. The implication that proprietary software undergoes rigorous testing would have required sourcing. Furthermore, while we may not need multiples mentions of the author, I oppose to removing all mentions. The current formulation is a bit shorter but much vaguer, suggesting that many may have suggested that conclusion while we only know of one person who has. I prefer the previous version or no paragraph to that short form. I am going for no paragraph to avoid controversy, considering the source's limited reputation, the suggestion's weakness, and considering that the section already offers several other explanations. --Chealer (talk) 23:33, 21 April 2014 (UTC)
Coverity is a third-party source with regard to this article. The statement is not "out of date" just because it wasn't published this year, unless there are hints of an unlikely fast change in the area. The mention does not constitute original research. There is no need for everything in this article to be ulterior to Heartbleed's disclosure. Choizit's argument is a generalization from Heartbleed/OpenSSL to open-source is general. Such a generalization can be questioned and will inevitably be with the debate around this controversial topic (which we cover very briefly in [2]). This topic is old and has obviously been debated years before Heartbleed. Heartbleed's disclosure does not make all anterior material obsolete.
There is one issue with the statement's relevance - it is focused on C. While Heartbleed is written in C, proprietary equivalents could be written in safer languages, which would reduce the likeliness of equivalent vulnerabilities. I believe C is indeed overrepresented in free software, weakening the report's relevance, but I do not think this suffices to completely ignore the findings. --Chealer (talk) 23:33, 21 April 2014 (UTC)
QUOTE: “Security experts worldwide have deemed the so-called Heartbleed bug one of the most dangerous security flaws ever to crop up on the Web. While we don't know the full extent of Heartbleed's menace, the bug has the potential to cause catastrophic data breaches. When news of Heartbleed broke, Internet users were advised to change all their online passwords as a precaution, and enterprise IT security teams scrambled to neutralize the immediate threat by applying a patch. But like many serious conditions, the real danger posed by the Heartbleed bug is longer term and much more quiet than the initial hoopla might suggest. ” ["Patches are just band-aids. Heartbleed's long-term effects will force companies to reassess how they deploy and manage technology."] — Charles Edwin Shipp (talk) 14:24, 21 April 2014 (UTC) — PS: FYI for future editing.
Headine-2: Why Heartbleed May be more Troubling for Healthcare.gov in the Long Run
QUOTE: “Users of HealthCare.gov are being asked to change their passwords due to the federal exchange’s potential vulnerability to the Heartbleed security flaw, and the warning is troubling, analysts say, as medical information is hotter than ever for criminals looking to make a quick profit.” [Helathcare.gov and relating Obamacare websites and methodologies were never known for tight security!] — Charles Edwin Shipp (talk) 00:27, 23 April 2014 (UTC) — PS: FYI for future editing.
Headine-3: The U.S. Needs to Stop Running Internet Security Like a Wikipedia Volunteer Project
QUOTE: “ One lesson of the Heartbleed bug is that our government is paying to undermine Internet security, not to fix it.” [Comment-1: The left-handed compliment to Wikipedia is interesting; Comment-2: There is more to security than passwords—such as encrypted-transmission. Comment-3: This article is headlined for Google News; Comment-4: The last paragraph of the Article herein (WP) covers this aspect, to some extent.] — Charles Edwin Shipp (talk) 11:54, 23 April 2014 (UTC) — PS: FYI for future editing.
It would be interesting to include an approximation of the cost of Heartbleed. According to [3], "Even if there hasn’t been any malicious exploitation of the bug, the costs of people’s time will likely run into the hundreds of millions of dollars."
There aren't details on how that was computed. I wonder if this is realistic. --Chealer (talk) 20:07, 20 April 2014 (UTC)
That number is pretty speculative but not completely crazy imho. You could compute as 500k sites spending 2 hours each dealing with upgrades and cert replacement at $100 an hour = $100 million. More likely though, most of those sites will just do a standard update and not bother replacing their certs, and in most cases nothing will happen if they did it soon enough. Then there will be some unpatched sites that suffer actual cert theft, and a small fraction of those will have some sessions compromised through MITM attacks on (e.g.) public wifi networks, causing more hassles. I think large scale MITM attacks are less likely. Then there may also be client compromises from malicious servers (see "reverse heartbleed" above) etc. The article linked is reasonably good. 70.36.142.114 (talk) 20:48, 20 April 2014 (UTC)
Failing a better source, I've added a very rough estimation of 500 million USD from eWEEK. I'd love to see a real calculation replace that. --Chealer (talk) 02:02, 24 April 2014 (UTC)
Removing XKCD
Regrettably, I am removing the XKCD 1354 explanation of the bug. We really can't replace a suitably licensed drawing with non-free content and then claim that "no free equivalent is available, or could be created, that would serve the same encyclopedic purpose." as our policy WP:NFCC demands in criteria 1. Furthermore, the reduced resolution image that was uploaded isn't even legible. If it were up to me, I'd allow NC content and tag it so commercial users would be warned not to copy it, but it is not up to me and attempts to change the policy have failed in the past. Maybe the author could be persuaded to release this strip under a compatible license, but absent that it can't stay.--agr (talk) 10:17, 18 April 2014 (UTC)
That's insane. If we created a free equivalent of the XKCD comic, we would be ripping them off, thus violating their copyright. I would think that XKCD would want credit for their work, and that we not rip them off, which is apparently what you are saying.
Further, it's published under this license which says that we are free to copy and redistribute the material in any medium or format as long as we give credit and we use it for non-commercial purposes. A Quest For Knowledge (talk) 11:15, 19 April 2014 (UTC)
The image may be considered freely licensed by common standards, but if the image does not allow for free commercial use, then it is considered non-free by Wikipedia's standards (which means the XKCD comic would have to meet the criteria for using non-free content, which it does not). ~SuperHamsterTalkContribs19:00, 19 April 2014 (UTC)
Again, that's insane. I do not see that there is any way to replicate this comic without violating XKCD's copyright. Are we seriously suggesting that in order to protect XKCD's copyright, we must violate XKCD's copyright? If not, can someone please provide a free equivalent graphic that of the XKCD comic withhout violating their copyright? A Quest For Knowledge (talk) 19:34, 19 April 2014 (UTC)
Who said anything about replicating the comic? The point is that Heartbleed can be perfectly explained through just text, or with another sort of graphic, such as this one that does a great job of explaining the bug much more compactly than the XKCD comic. No one said anything about creating a duplicate version of the XKCD comic. ~SuperHamsterTalkContribs20:08, 19 April 2014 (UTC)
However, compact does not mean understandable by the non-technical user. That is the beauty of Randal Munroe's comic. It explains Heartbleed simply and elegantly to the non-technical user. With all due respect, File:Heartbleed bug explained.svg just does not do it for me nearly as well, & I have been working in I.T. for nearly a ¼ century.
Going back to another part of this discussion, I think the relevant guidelines can be found at WP:FAIRUSE & a section of that page, WP:Image resolution.
The strict interpretation of WP:IMAGERES is "At the low pixel count end of the range, most common pictorial needs can be met with an image containing no more than about 100,000 pixels (0.1 megapixels)." I attempted to do that at File:Xkcd - Heartbleed Explanation by Randall Munroe.png with a 216 × 460 (82 KB) image. While that was largely unreadable at that low resolution, my main intent was to drive traffic to the comic where it could be freely viewed as the creator, Randall Munroe, intended. However, a subsequent author removed it.
My real interest is to raise awareness about this vulnerability, including among non-technical audiences. Given WP:IMAGERES calls for "no more than about 100,000 pixels", & that going to that resolution leaves it illegible for nearly all, the best that I could hope for was to use the graphic to indicate "hey, there's is something worth looking at here." The comic is a simple & elegant non-technical explanation of the Heartbleed vulnerability & how it is exploited. Getting peiople to read it is in the public interest. WP:NOTPROMO would not even play into this if WP:IMAGERES allowed a readable image. Peaceray (talk) 23:13, 19 April 2014 (UTC)
Regardless, I still fail to see how the use of the comic meets non-free content criteria, particularly points 1 and 8. The free comic I linked to earlier does serve as a free equivalent, per OP. If it doesn't, well, a better one could certainly be created. Its presence may help with the understanding of the subject, but its omission is definitely not detrimental to the understanding of the subject, either, when free alternatives (or simply explaining the bug through text) will suffice. ~SuperHamsterTalkContribs21:47, 19 April 2014 (UTC)
I have seen no free alternatives that are nearly as simple & elegant an explanation for non-technical audience as the xkcd: Heartbleed Explanation comic. Many more people would quickly grasp what Heartbleed does than through the technical explanations in the article. The free content graphic File:Heartbleed_bug_explained.svg is not nearly as lucid.
You state that if the free comic that you linked to earlier does not serve well as a free equivalent, then a better one could certainly be created. Well, get at it!
Here's a rough draft of a simplified version of the graphic I've done so far, integrating the content of the original graphic with the conversation style of the xkcd comic. Let me know what you think.
Oops, yeah I think the svg version doesn't work well in browsers (it should look identical to the rasterized version). I'll have to flatten the layers before uploading, if we decide to use the picture. The server graphic might need some more detail too. – FenixFeather(talk)(Contribs)02:35, 20 April 2014 (UTC)
Would be good to have some text inside the server box, as in the XKCD cartoon, to illustrate where exactly this "secret server info" is coming from. Bigger text to make it more thumbnail-legible would help, too. But the current version is already much clearer than the existing user-made cartoon - I'll add it to the article. --McGeddon (talk) 10:32, 20 April 2014 (UTC)
Heartbleed can in fact affect a client, not just servers. I would therefore suggest more generic labels - perhaps "Vulnerable party" on one end and "Unmalicious/Legitimate/Harmless/? party" and "Malicious party" on the other. By the way, I find the size of circles out of proportion. If easy, I'd appreciate to see them smaller. --Chealer (talk) 19:34, 29 April 2014 (UTC)
That is stated in the body of the article. The picture merely provides an example of a Heartbleed request; it is not intended to describe Heartbleed in its entirety. Thus it is more useful to arbitrarily assign the attacking party to a user and the victim as the server without loss of generality, especially because normal Heartbleed is much more dangerous and received more coverage in reliable sources than reverse Heartbleed. I enlarged everything so that the thumbnail would be more visible. – FenixFeather(talk)(Contribs)20:27, 29 April 2014 (UTC)
Table Alternative
Here is the same content (give or take a few minor details) as a table:
Heartbleed in action, as a table
Normal Heartbeat
Server, send me this 4 letter word if you are there: "Blah"
"Blah"
Heartbleed
Server, send me this 16,004 letter word if you are there: "Blah"
A discussion at the end of the article summarizing Dan Kaminsky's opinion says,
After learning about donations to the OpenSSL project totaling $841, he commented "We are building the most important technologies for the global economy on shockingly underfunded infrastructure."[144] Other sources cite yearly donations of about US$ 2000.[145]
Last year, the foundation took in less than $1 million from donations and consulting contracts.
Donations have picked up since Monday, Mr. Marquess said. This week, it had raised $841.70 as of Wednesday afternoon.
I'm not disputing that OpenSSL has historically had a very small budget. But there's a big difference between "less than $1 million", "$2000", "$841", and "$841 in the last 3 days". The summary of Kaminsky's opinion should be revised to accurately reflect OpenSSL's actual budget and donations. --Bigpeteb (talk) 20:27, 28 April 2014 (UTC)
Resolved
Ah, that explains it. Kaminsky wasn't too clear and I must have missed his link. I misinterpreted Kaminsky big time and am very sorry about that. Thanks very much for reporting. I hope you'll find the new version OK. We still don't mention the "less than $1 million" since it's imprecise and includes more than donations, but it's at least mentioned on OpenSSL. --Chealer (talk) 20:15, 30 April 2014 (UTC)
The concluding paragraph is bogus
The concluding paragraph is bogus. There are tons of bugs in proprietary software too.[5] OpenSSL is rather crufty though. The OpenBSD team is overhauling it, but who know if the extensive changes will introduce more bugs. Best practice is probably to use the "engine" feature to put the sensitive crypto operations into a separate process, and there's at least one big installation planning to move to that approach, but I don't have an RS for that yet. There may be some general security principles we can quote from, e.g. from Ross Anderson's book. [6]70.36.142.114 (talk) 03:04, 20 April 2014 (UTC)
I've reverted this good faith edit because the explanation ("does not actually test whether Heartbleed is present on a given site") doesn't apply to what the test does. Of course, it doesn't address whether Heartbleed isn't on any particular site. That's not what it does. Instead, it tests whether a browser checks whether an SSL certificate has been revoked. Heartbleed allows hackers to steal SSL certificates. Even if the website revokes the stolen certificate, if the browser doesn't check whether it was revoked, the browser will report the revoked certificate as legitimate. This test was specifically created because of the Heartbleed bug. According to Netcraft, only 30,000 of the 500,000+ SSL certificates affected by the Heartbleed bug have been reissued up until today, and even fewer certificates have been revoked.[7]A Quest For Knowledge (talk) 02:08, 20 April 2014 (UTC)
Meh, Adam Langley argues that online CRL checking is useless.[8] Yes revocation is appropriate but I wouldn't get that worked up about it. 70.36.142.114 (talk) 03:42, 20 April 2014 (UTC)
I do not consider this test as relevant in this article. However, if some people think it is, keep in mind it doesn't "test whether Heartbleed affects a given site", which is the reason why I am removing it. --Chealer (talk) 17:41, 20 April 2014 (UTC)
It's certainly wrong to call it a check for heartbleed. However, lots of heartbleed-affected sites have been replacing their certificates (and sometimes revoking the old ones), so mentioning something about that is relevant to the article, at which point it's reasonable to point to a CRL checking tool. 70.36.142.114 (talk) 18:15, 20 April 2014 (UTC)
@Chealer: It doesn't matter whether you personally think it's relevant to the article. Original reseach isn't allowed and even if it was, you would be wrong. The fact remains that a hacker can steal a web site's certificate using Heartbleed and this tests whether the web site's certificate has been revoked. If you don't understand how Heartbleed works, maybe you shouldn't be editing this article. A Quest For Knowledge (talk) 19:21, 20 April 2014 (UTC)
A Quest For Knowledge, I fail to see why you allude to OR. My edit simply removes material. In any case, as I wrote, the reason why I removed the material is because it made the section wrong, not because I consider it irrelevant. --Chealer (talk) 19:50, 20 April 2014 (UTC)
Wait, what are you guys arguing about? AQFN, what edit did you revert at the top of the section? I remember seeing a CRL checker mentioned in the section about heartbleed tests. I'd say a CRL checker is definitely not a heartbleed test and should not be described as one, but it's arguably relevant to the article anyway, so there is a case for including it as part of info about cert revocation. Cert revocation itself should be mentioned in the article (including whatever sourcing can be found about whether it's a good or bad idea) since it's being recommended by some as a response to Heartbleed. Actually, if anyone has a revoked certificate that they can still serve, it might be interesting to show a screen shot of a browser responding to an OCSP failure. 70.36.142.114 (talk) 19:41, 20 April 2014 (UTC)
Lastpass, the company, owns Lastpass Password Manager. It was from a direct blogpost from them, describing that Lastpass Password Manager was vulnerable. Per WP:PRIMARY, this is a sufficient reference, and we do not need another one. Also, the entries below it use primary sources as well, and I don't see you tagging them as 'needing another reference'. Specific text; A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge.. Tutelary (talk) 22:19, 25 April 2014 (UTC)
I agree. The repeated insistence on reference is very odd. I just read the entire blog post and it seems to support the article text pretty well. We indicate that Lastpass's service was affected, but that they had measures in place that prevented further damage. I don't see any conceivable reason that the source does not support the article text. – FenixFeather(talk)(Contribs)03:31, 26 April 2014 (UTC)
As I already explained, the reason for the tag isn't that a "better source" is needed (although [9] did imply that). What is missing is a source for the part of the paragraph stating that LastPass Password Manager was vulnerable. As previously explained, a source stating that LastPass was vulnerable does not suffice to claim that LastPass Password Manager was vulnerable, just like a claim that Microsoft was affected wouldn't suffice to claim that Microsoft Windows was affected (although LastPass Password Manager probably has more relative importance to LastPass than Microsoft Windows has to Microsoft).--Chealer (talk) 20:36, 26 April 2014 (UTC)
It is very much sufficient. Two editors (including myself) are against you, and per WP:CONSENSUS, and in accordance with WP:EDITWAR, you should not be readding content that one or more editors disagree with (when you know they disagree) with it. Per WP:PRIMARY, It is a sufficient enough source. We don't need a better source than the company themselves. The source stating themselves are vulnerable is by themselves. Also, you're not giving the source enough WP:DUE. It's the company's official blog. If that's not reliable, I don't know what is. Is your final goal to remove the Lastpass section entirely, due to being properly sourced as you did once before?: https://wiki.riteme.site/w/index.php?title=Heartbleed&diff=605482274&oldid=605482150Tutelary | It should also be noted that the sources below Lastpass (and above) also rely on primary sources, yet I don't see you ultimately tagging them. What is missing is a source for the part of the paragraph stating that LastPass Password Manager was vulnerable. As previously explained, a source stating that LastPass was vulnerable does not suffice to claim that LastPass Password Manager was vulnerable, just like a claim that Microsoft was affected wouldn't suffice to claim that Microsoft Windows was affected (although LastPass Password Manager probably has more relative importance to LastPass than Microsoft Windows has to Microsoft). No. Not another source is needed. An official statement by Microsoft meets WP:DUE and we would include it, as they are the owner of the software and know it better than anybody else. I'd also like to request on what policy you think that this is not a reasonable source to use for a claim about their product which they own. Tutelary (talk) 00:15, 27 April 2014 (UTC)
WP:CONSENSUS does not claim that one shouldn't readd content because one knows of an opposing editor. In any case, I have not readded content. This has nothing to do with WP:PRIMARY. We couldn't include a claim that Microsoft Office was affected just because a source (even if it was Microsoft) would claim that Microsoft was affected. Do you understand that Microsoft and Microsoft Office are not the same thing? My final goal is to make the article comply with our guidelines, whether that's by removal of unverifiable content or by proper sourcing. --Chealer (talk) 17:15, 27 April 2014 (UTC)
We would give it its WP:DUE to it being an official source, and the owner of the software. Yes, we would very much include it. You still have not linked to a policy regarding this. Tutelary (talk) 17:33, 27 April 2014 (UTC)
Again, this has nothing to do with ownership of the software. No matter how much boldface or textual effects you want to use, we still won't consider it as verifiable that Microsoft Office is foo just because the best source in the world says Microsoft is foo. If you need a link to get that point, then see Wikipedia:Verifiability. --Chealer (talk) 02:27, 28 April 2014 (UTC)
Why is that page not sufficient? It's talking about their product. They refer to their own product as LastPass. See this. It doesn't even make sense for a company to be vulnerable to Heartbleed. – FenixFeather(talk)(Contribs)22:31, 26 April 2014 (UTC)
Just to add to numbers without discussion, I agree that the LastPass information (which I also have edited) is sufficient. I edited it to the wording "According to the LastPass Password Manager blog, a standard test showed it as being vulnerable until it was patched on 8 April but, due to its use of additional encryption and forward secrecy, potential attacks were not able to exploit this bug. However, LastPass recommended that users change passwords that LastPass stored for vulnerable websites." This was changed, I don't know if because someone disagreed, or as a side-effect of other changes. My intention was to give more detail and stay close to the source: "a standard test showed it as being vulnerable" (from the Web page). The present wording "LastPass Password Manager, according to the company's official blog, showed it as being vulnerable" is perhaps not quite right (a particular test flagging it as vulnerable doesn't mean it actually was; it is claimed that it wasn't, actually) and ungrammatical. Pol098 (talk) 11:01, 27 April 2014 (UTC)
Pol098, I was the one who reworded it to match the style of wording listed by the other products. All of them had their names listed as first, so I sought to do the same for Lastpass. I've restored the original wording except for a few words. You have my blessing to restore it entirely if you still don't think it's right. Just keep in the mind the style that the other entries have. They start with their names first, so if you do change it, try to preserve that. Tutelary (talk) 12:48, 27 April 2014 (UTC)
Thanks for explanation. I see it's been reworded now (I got an edit conflict when doing it myself!); I think it's better that way. Best wishes, Pol098 (talk) 14:13, 27 April 2014 (UTC)
Chealer, please do not readd the request for reference. There are now 3 editors against you, and I really hope you get it this time. You haven't addressed any of the points that I or anybody else have made. @Chealer:, I find it incredibly disruptive that you have to resort to misleading edit summaries to drive your point in; https://wiki.riteme.site/w/index.php?title=Heartbleed&diff=606059695&oldid=606059230 | The next time that you edit this section in without engaging in any rebuttals of the arguments here, I will go through the proper channels regarding this. Tutelary (talk) 17:26, 27 April 2014 (UTC)
There's no need to get adversarial. I'm not "against you", we simply disagree on one point (or more likely, one of us misunderstands something). I did answer some or all of the points. Please focus on participating in the discussion rather on than pushing your favorite version. --Chealer (talk) 17:33, 27 April 2014 (UTC)
It is not I who resorted to misleading edit summaries in order to secretly readd the request for reference tag against WP:CONSENSUS. Consensus is how we make editorial and content based decisions here on Wikiepdia. You are welcome to attempt to prove to the community that is is flawed, and needs a change but for now, the consensus is against you. Tutelary (talk) 17:34, 27 April 2014 (UTC)
Per WP:CIRCULAR, we should avoid using Wikipedia articles as sources, even in a discussion. The article itself may have to be moved, depending on more information on the official product name. In any case, even if only the informal name is Lastpass, it is very clear that when Lastpass says "Lastpass was vulnerable to Heartbleed," they mean their product, Lastpass, a password managing software, not the company. Using your Microsoft example, Microsoft cannot be vulnerable to Heartbleed. Maybe Microsoft services such as Skype and OneDrive can be vulnerable, but certainly not Microsoft itself. – FenixFeather(talk)(Contribs)18:11, 27 April 2014 (UTC)
Microsoft can certainly be vulnerable to Heartbleed. If one of its systems is attacked, damages to these systems will be damages to Microsoft. The question is what the "product" is - a service or an application? Most likely a service, in which case the item needs another source.--Chealer (talk) 02:27, 28 April 2014 (UTC)
It is both. While the LastPass article may need to figure out what the article is on, in real life, when they say LastPass is vulnerable, they mean that the service, which includes the LastPass application, is vulnerable. Users of the LastPass service use the LastPass application to connect to LastPass servers, where they can store their information. – FenixFeather(talk)(Contribs)04:28, 28 April 2014 (UTC)
I agree, their system must have a server and clients. The reference clearly refers to the service. Had it been about the application, they'd have mentioned vulnerable versions (and - hopefully for their customers - released a fixed client by now). --Chealer (talk) 15:45, 30 April 2014 (UTC)
The main lastpass application is web based which means that the server is the critical bit. Yes they have booklets and plugins for browsers etc. but the doesn't change that. PaleAqua (talk) 17:01, 30 April 2014 (UTC)
I'm not sure I get what you mean by the "main lastpass application". The application to manage passwords? Surely that application doesn't allow form filing :-? --Chealer (talk) 20:52, 30 April 2014 (UTC)
Chealer, I second those above who point out that a company can't be vulnerable to a SSL bug—only a particular web service, in this case Lastpass's password vault service, can. The official blog post seems perfectly clear to me—the servers running their service were initially vulnerable to the bug before being patched. I'm removing the "dubious" tag.—Neil P. Quinn (talk) 04:02, 28 April 2014 (UTC)
Yeah, I threw in another source that explicitly mentions them trying to fix their service on the 8th. Hopefully this will please him. He's been edit warring all sorts of tags into that part of the article. – FenixFeather(talk)(Contribs)04:23, 28 April 2014 (UTC)
One might argue that only software can be "directly" vulnerable to a bug, but if we take "open to attack or damage" as the definition of "vulnerable", then an organisation can be vulnerable to Heartbleed ("indirectly", if you wish). Anyway, thanks for your opinion, that's also how I interpreted the source. Although we haven't been asking for a source blaming the application and specifics for very long, I'm taking their absence as a confirmation that these don't exist, and am moving the problematic piece. --Chealer (talk) 15:45, 30 April 2014 (UTC)
Password managers and recommendations
Note that fact that the passwords were stored in a particular vault doesn't matter in regards to vulnerabilities on other websites and so I removed what to me seems like a redundant bit of advice, which might better besides some other statements of recommendations of password changes. That said I like Tutelary's rewrite as it avoids the implication that it is the channel between lastpass and other sites that was the problem. That said we have several sentences and sources quoted as saying stuff like "People should take advice on changing passwords from the websites they use.", People should take advice on changing passwords from the websites they use., The following sites have services affected or made announcements recommending that users update passwords in response to the bug, Platform maintainers like the Wikimedia Foundation advised their users to change passwords. already spread though out the article, so it does feel a bit redundant to say just a few sentences similar sentences that same thing again. We also seem to be missing stuff that was covered by several sources about how such vaults help with recovery after such an incident? For example:
Tools are now widely available that will store and organise all your passwords and PIN codes for computers, apps and networks. They can also generate passwords and can automatically enter your username and password into forms on websites. Such tools store your passwords in an encrypted file that is accessible only through the use of a master password. Examples of such services include KeePass, LastPass and 1Password.
If I recall there were several news articles extolling the virtues of such managers as part of there converge. PaleAqua (talk) 21:11, 30 April 2014 (UTC)
I would not be opposed to adding such material to the article, however it does border on the not an instruction manual policy of Wikipedia. Saying something like, "It is recommended that you use a password manager" I think would have no place. However maybe in a reception/section somewhere, say something like, "BBC recommended using a password manager in order to have secure passwords" or something like that. I don't know. It still appears somewhere promotional (even if others don't see it that way.) Anywho, I didn't exactly rewrite it. It was what it was before Chealer messed with it, so I just restored that version of it. Tutelary (talk) 21:18, 30 April 2014 (UTC)
We are reporting what the source says. The discussion above was pertaining to a possibility of a new paragraph or sentence to the 'reception' portion of the article, and the possibility of creating one. Do not misinterpret this as approval to remove the sentence. Tutelary (talk) 21:46, 30 April 2014 (UTC)
If PaleAqua didn't support removal, I don't know how to interpret the following part:
That said we have several sentences and sources quoted as saying stuff like "People should take advice on changing passwords from the websites they use.", People should take advice on changing passwords from the websites they use., The following sites have services affected or made announcements recommending that users update passwords in response to the bug, Platform maintainers like the Wikimedia Foundation advised their users to change passwords. already spread though out the article, so it does feel a bit redundant to say just a few sentences similar sentences that same thing again.
While my preference did lean a bit towards removal, I actually like the idea of a slightly expanded reception portion. While wikipedia is not a how to guide, a number of sources did offer recommendations, and we should cover that. I've also heard that of numerous scams using heartbleed as the hook, might be worth mentioning ( though briefly ) as well. For example: Heartbleed Used by Identity Thieves in Phishing Scam; I know someone that almost got taken in by one that was similar to the "Microsoft/Windows Support" event viewer scam but based around Heartbleed. btw: her not his PaleAqua (talk) 21:16, 3 May 2014 (UTC)
The article misses some important big picture aspects
Unfortunately, this article (like much of the information currently available online as of 5/8/14) misses some very important aspects of the HeartBleed bug. Among them:
While O/S are generally immune, application software packages often embed a copy of OpenSSL which itself can be vulnerable. This is true on every popular platform, and is a vendor-recommended action.
Some vendors continue to offer vulnerable software on their App download sites, and little or no help to users who want to find and remediate vulnerabilities.
As a result of the above, the industry/community is now in a situation where most people have "moved on" yet HeartBleed is still a potentially large risk.
I will begin the process of adding extra information (yes with references) to the article, to ameliorate this.
Mr Pete (talk) 19:58, 8 May 2014 (UTC)
I'm removing the following sentence from the lead:
Apple recommends embedding OpenSSL in client applications when necessary for compatibility; as a result, Apple's FileMaker software required a fix.
Although FileMaker did require a fix as mentioned in the Impact section, the relation doesn't warrant treatment in the lead in my opinion and the sentence could be misunderstood. The need to fix FileMaker itself is in fact the result of a combination of circumstances:
FileMaker using OpenSSL
FileMaker linking OpenSSL statically
The OpenSSL version embedded in some FileMaker versions being vulnerable
Note that Apple actually recommends against using OpenSSL all together, and only recommends embedding only when OpenSSL is used to maintain source compatibility. On the other hand FileMaker is a subsidiary of Apple. PaleAqua (talk) 20:16, 10 May 2014 (UTC)
Resolved
davidwr/(talk)/(contribs) 21:06, 19 April 2014 (UTC)
and 
. Mahahahaneapneap (talk) 12:35, 22 April 2014 (UTC)
