Talk:Heartbleed

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Security (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer Security (marked as Top-importance).
 
WikiProject Internet (Rated B-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 

ITN/DYK[edit]

Is anyone going to take this article to ITN/DYK? --TitoDutta 18:58, 9 April 2014 (UTC)

OpenSSL#Heartbleed bug has already been linked to at ITN. I just proposed over there for the link to be changed. Mz7 (talk) 21:38, 9 April 2014 (UTC)
Resolved: The link has been changed. Mz7 (talk) 01:28, 10 April 2014 (UTC)

Illustration[edit]

The image at http://heartbleed.com/heartbleed.png appears to be used in a lot of news articles. It originates from a website called heartbleed.com. I'm thinking about asking the copyright owners for permission to use it on Wikipedia and license it under CC-BY-SA, but I want to first confirm whether or not it would be appropriate. It's definitely not the "official logo" or what not for the security bug, but it's being used to represent it at CNET, BBC, Epoch Times, and other sources. Thoughts, concerns? Mz7 (talk) 21:45, 9 April 2014 (UTC)

Asking them to release it under CC-BY-SA is a good idea, but don't expect "yes" (although it is quite possible!). πr2 (tc) 23:06, 9 April 2014 (UTC)
It might be very possible that this logo (and the dedicated website) helped in spreading knowledge about the bug (and thus encouraging rapid response), because it gave media something to show. (refs: [1], [2]) It might be worth keeping an eye out for analyses of this aspect of the whole event. --Rhymoid (talk) 00:09, 10 April 2014 (UTC)
I've sent an email to Codenomicon requesting consent. It's a toss-up for if they say yes or no. smile Best, Mz7 (talk) 02:23, 10 April 2014 (UTC)
The quickest way might be if they upload themselves. Does not it pass FairUse? --TitoDutta 02:28, 10 April 2014 (UTC)
Under CC0 apparently. πr2 (tc) 11:32, 10 April 2014 (UTC)
Resolved: Yep, I've just got an email confirming CC0, the website has been updated to confirm this too. Looks like it's already been uploaded. Mz7 (alt) (talk) 14:38, 10 April 2014 (UTC)

Origin and meaning of name[edit]

How did this bug get this name? 71.80.141.142 (talk) 02:25, 10 April 2014 (UTC)

"Bug is in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server." Hence Heartbleed. kencf0618 (talk) 04:40, 10 April 2014 (UTC)

And:

According to http://security.maruhn.com/iptables-tutorial/x1736.html --

"The HEARTBEAT chunk is sent by one of the peers to probe and find out if a specific SCTP endpoint address is up. This is sent to the different addresses that was negotiated during the initialization of the association to find out if they are all up. . . .

"Heartbeat Information TLV - bit 32-n. This is a variable-length parameter as defined inside the RFC 2960 - Stream Control Transmission Protocol document. This is a mandatory parameter for the HEARTBEAT chunks that contains 3 fields, info type = 1, info length and a sender-specific Heartbeat Information parameter. The last field should be a sender-specific information field of some kind, for example a timestamp when the heartbeat was sent and a destination IP address. This is then returned in the HEARTBEAT ACK chunk." Jo3sampl (talk) 01:58, 12 April 2014 (UTC)

Affected Websites[edit]

Should the large list of affected websites be linked to the websites they point to? They currently are simply urls. Piguy101 (talk) 19:21, 10 April 2014 (UTC)

@Doc Strange, Piguy101: is this good? πr2 (tc) 19:53, 10 April 2014 (UTC)
That's much better. Thanks Piguy101 (talk) 19:56, 10 April 2014 (UTC)
Would [[Example (website)|example.com]] be better? πr2 (tc) 19:57, 10 April 2014 (UTC)
I believe that it is fine the way it is now, but if you think differently, go ahead and make the change. Piguy101 (talk) 19:59, 10 April 2014 (UTC)
Depends whether or not they use the '.com' in their company name or not. -Lopifalko (talk)
Of course. If the ".com" is part of the company name, it should already be in the article name, right? Piguy101 (talk) 20:06, 10 April 2014 (UTC)

Purpose of "Affected websites and services" section[edit]

I don't see how the section will be too useful in the future when all the servers have been patched and the filippo.io links no longer detect the bug. The websites listed should be supported by secondary sources instead of relying on so many primary sources (the tests run by filippo.io); it also seems like indiscriminate information to me, but this could also be made relevant by secondary sources. Whisternefet (t · c) 23:13, 10 April 2014 (UTC)

  • keep it at least for now. --TitoDutta 23:33, 10 April 2014 (UTC)
  • Maybe the list should be condensed in the near future to just a few of the biggest sites because the list may be relatively useless in just a year. Piguy101 (talk) 23:58, 10 April 2014 (UTC)
That section needs to be deleted in its entirety. It serves no real purpose considering OpenSSL is used in millions of servers including ALL top 1000 websites. There is no need to list them all. It's also missing many major ones anyway (Google, Facebook, etc.). And what on earth is the point of the whole "fixed on [or before] 10 April 2014" next to each website? That's already outdated... --CyberXRef 13:50, 11 April 2014 (UTC)
  • I agree, the list is too large and has a potential to grow too large to be useful. Only sites that have been reported as vulnerable in secondary sources should be listed, if at all. –xenotalk 15:37, 11 April 2014 (UTC)

Vimeo video[edit]

Why are we linking Vimeo video at the EL section? --TitoDutta 23:32, 10 April 2014 (UTC)

FWIW - Yes , the Vimeo Video (Video (08:40) - Explanation of the Heartbleed bug) Seemed a Relevant and Worthy Addition To The Heartbleed bug Article - However, Please Understand That It's *Entirely* Ok w/ Me to rv/mv/ce of course - In Any Case - Enjoy! :) Drbogdan (talk) 00:23, 11 April 2014 (UTC)

Possible Exploitation by intelligence agencies[edit]

EFF reports in their latest newsletter the possibility that this has been exploited by intelligence agencies https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013:

"The second log seems much more troubling. We have spoken to Ars Technica's second source, Terrence Koeman, who reports finding some inbound packets, immediately following the setup and termination of a normal handshake, containing another Client Hello message followed by the TCP payload bytes 18 03 02 00 03 01 40 00 in ingress packet logs from November 2013. These bytes are a TLS Heartbeat with contradictory length fields, and are the same as those in the widely circulated proof-of-concept exploit.

Koeman's logs had been stored on magnetic tape in a vault. The source IP addresses for the attack were 193.104.110.12 and 193.104.110.20. Interestingly, those two IP addresses appear to be part of a larger botnet that has been systematically attempting to record most or all of the conversations on Freenode and a number of other IRC networks. This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers." — Preceding unsigned comment added by StephenK51 (talkcontribs) 23:47, 10 April 2014 (UTC)

First reported in ArsTechnica http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/

From Wired "Has the NSA Been Using the Heartbleed Bug as an Internet Peephole?" — Preceding unsigned comment added by StephenK51 (talkcontribs) 00:58, 11 April 2014 (UTC)


Probably a good explanation for lay people: http://imgs.xkcd.com/comics/heartbleed_explanation.png — Preceding unsigned comment added by 82.46.109.233 (talk) 10:47, 11 April 2014 (UTC)

Wkimedia: clarification?[edit]

@Perfect for you: what needs to be clarified? Do you want to list out Wikipedia, Wiktionary, Wikibooks, etc. ? πr2 (tc) 11:51, 11 April 2014 (UTC)

Under "Websites affected" is listed "Wikimedia (including Wikipedia)". The first part, Wikimedia, could mean Commons, or it could mean Meta? The second half "including Wikipedia" doesn't mention which language versions of Wikipedia were affected, and none of it mentions whether Wikibooks, Wiktionary, Wikiversity, or Simple English Wikipedia were affected. I don't know why the notification/ping only appeared today, especially since I have logged on several times since making that edit. Anyways if you have any more questions, please drop a note on my talkpage because I don't trust the notifications. @PiRSquared17: Perfect for you (talk) 14:43, 5 May 2014 (UTC)
@Perfect for you: Wikimedia refers to all of that (all sister projects in all languages, so everything you mentioned is included)... it's all the same infrastructure. :-) I don't think it makes sense to list all language editions of Wikiversity, Wikibooks, Wikispecies, Wiktionary, Wikipedia, etc. and Meta, Commons, etc. separately. Do you have a better suggestion? Maybe "Wikimedia (all sites hosted)"? πr2 (tc) 19:08, 5 May 2014 (UTC)
@PiRSquared17: Something like "All 587 Wikimedia Foundation wikis", but I don't know where to find the actual number. Perfect for you (talk) 19:21, 5 May 2014 (UTC)
@Perfect for you: Special:SiteMatrix says 882, there were 853 in a query result, but only 726 of those were not closed (have any been opened since Heartbleed?). Maybe we should just say "over 700" or "over 800" if we are going to do that. πr2 (tc) 01:08, 6 May 2014 (UTC)

What is the Heartbeat[edit]

What is the heartbeat, why is it in openssl? What is the effect of not having heartbeat enabled? — Preceding unsigned comment added by 119.12.44.161 (talk) 12:35, 11 April 2014 (UTC)

It is a feature of Datagram TLS, a relatively new extension of TLS, that allows a DTLS peer to check the responsiveness of the other end, since the normal TCP machinery isn't around to do this. I think it's worth including some description of this in the article. OpenBSD has turned it off, FWIW.[3] — Preceding unsigned comment added by 70.36.142.114 (talk) 15:38, 14 April 2014 (UTC)

Assumptions based on incomplete checks and bare domain names[edit]

Heartbleed#Affected websites and services has a list of "websites and services" that were alleged to be vulnerable on April 8 but fixed on April 10 or later. But it appears to be WP:SYNTHESIS analysis based on the flawed assumption that testing https for the bare domain name host (without www. or anything else) for the Heartbleed bug is actually the indication of whether the institution's servers have now been secured. There are several major holes in these assumptions:

  1. It's a flawed assumption that HTTPS servers that answer for the bare domain name (for example https://google.com/) are the ones that carry the important traffic, rather than just being a redirect to the www. or other servers (for example https://www.google.com/) where the main traffic is.
  2. It's a flawed assumption that the "valuable" data to steal is on the main website. Many major websites actually have a totally different set of web servers (e.g. https://login.google.com/ or http://login.yahoo.com/) for entering your username and password, entering your credit card information, and the other main targets of data theft. These are the public servers that would be the most valuable (but not the only valuable) targets to connect to and exploit Heartbleed on.
  3. It's a flawed assumption that having fixed the bug for https on the "visible" websites made the logins and passwords or other authentication secure again. If the usernames/passwords/secrets are leaking on any protocol that is using them, the information is still compromised. Think of how many organizations now have mobile apps and instant messengers that are taken care of a different group of people with a different time schedule, or even a third-party contractor in a different city/country, and who weren't consulted about whether they're secure before the announcement was made to change passwords (which will instantly be exposed by those apps). Now think of how many of those apps and instant messengers "helpfully" log in automatically all the time without asking the user anymore. Until all the servers for apps that log in are fixed, the company's customer usernames and passwords are still compromised.
  4. It's a flawed assumption that no longer having the Heartbleed bug is the indication that the organization is back to being safe for the public. Tech news sites have mentioned that many purportedly-"fixed" websites seem to still be using pre-April SSL certificates that are supposed to prove the site is the real one. The certificates were reportedly leaked regularly by this bug and are potentially floating around out there ready to be used by fake websites now. Unless the organization revokes the certificates and uses newly-generated ones on all of its SSL services (see apps and instant messaging above), the services with old certificates are potentially as vulnerable to man-in-the-middle attacks and other phishing scams as if they were using plain HTTP with no encryption at all.

Because of all this, we need more reliable sources than just the improper synthesis assumption that the bare domain name HTTPS check is a good indicator that the organization's services are secured again. As mentioned in #3 above, we may have a primary sources problem also, because even the organizations themselves may even be inaccurately announcing that they are "secure" or "fixed" now just because they think their main web server team upgrading the web server software was the fix. Information from parties that explicitly have noted what services an organization has, and which have been secured, are probably necessary. Examples:

  • Google: Are Google Talk's XMPP servers patched and certificates re-issued? What about the Google login servers that authenticate every Android app that uses a Google account for access? What about the Google Play servers?
  • Yahoo: Are Yahoo Messenger's login servers patched and certificates re-issued?
  • Internet relay chat (IRC): Encrypted connections are exposing an IRC network's nickname/NickServ/ChanServ passwords unless every encrypted server on that IRC network has been patched and certificates re-issued. (The servers are often run by separate administrators.)
  • GitHub, SourceForge, and all those other source code/programming sites: Any distributed revision control systems that use SSL? MySQL and PostgreSQL and other database servers that public users can use for hosting? These source-code hosting organizations usually have several publicly-accessible services with SSL that most other organizations don't have. SSH wasn't vulnerable to Heartbleed; however, if an organization makes SSH or other arbitrary executable programs available to the public, then every SSL service available to "authenticated users" is open to silent attack from a random obscure customer also, even if it's firewalled from non-users.
  • Basically, for any site with encrypted communication other than the main website's pages: Have they enumerated which services they've gotten around to checking (rather than "all" or "most"), so that it can be determined by users (or Wikipedia readers) whether something has been overlooked before they authenticate to it or transfer other sensitive data that way? Before posting statements about "all" services being OK: Have we looked for other sources that already say that the organization forgot something? --Closeapple (talk) 16:25, 11 April 2014 (UTC)
  • I agree. This section ("Scanned") needs to be reworked. I've removed it: [4]. We definitely shouldn't be declaring an entire class of services "fixed" based on our own research. –xenotalk 17:17, 11 April 2014 (UTC)

xkcd explains Heartbleed[edit]

I am soooo tempted to just WP:BOLDly add this to External Links, but I'm thinking it might be a controversial addition. So... Discussion?

davidwr/(talk)/(contribs) 17:14, 11 April 2014 (UTC)

Reaction or cultural relevance? –xenotalk 17:27, 11 April 2014 (UTC)
It's an extremely layman-friendly illustration of the vulnerability. I'd never have made sense of the explanation in the article -- and I have some very basic programming experience -- but the XKCD strip made it very easy to understand. I recognize the undesirability of adding an external link to every XKCD strip that explains a difficult concept, but I'd support davidwr's idea in this one situation. 208.93.33.130 (talk) 19:44, 11 April 2014 (UTC)
If the article doesn't include a brief explanation of the bug in layman's terms, it'd seem better to write one than to link to a site that had one. Could even write up the comic in the article as "Randall Munroe explained the bug as..." if we considered him to be a sufficient authority for WP:SELFPUB. --McGeddon (talk) 22:08, 11 April 2014 (UTC)
I'm not up on all of the relevant WP standards -- but for usefulness, a link to that xkcd strip would be great! -- Jo3sampl (talk) 17:48, 12 April 2014 (UTC)

There isn't a real consensus one way or another, so I went ahead and WP:BOLDly added the link. I won't be offended if it is removed. diff. davidwr/(talk)/(contribs) 20:29, 15 April 2014 (UTC)

Someone added their own stick figure comic, explaining it in layman's terms in unreadably small text. I added a description to the caption, but this was reverted on the grounds that it's not worth explaining the image at this point because it's unreadable as a thumbnail. Fair enough. But it isn't great if the only non-technical explanation of the bug requires the reader to know that they can click on a Wikipedia image to see it magnified. Should this just go into prose? Is there a good source for a layman's description out there? I've just thrown in a summary of XKCD's explanation for now. --McGeddon (talk) 23:09, 15 April 2014 (UTC)

The current version of the page includes the XKCD comic itself. I interpret the NFCC policy's rule of "no free equivalent" to disqualify its use, so I nominated it for a non-free content review. Join the discussion at Wikipedia:Non-free content review#File:Xkcd.com-1354-how-the-heartbleed-bug-works.png. davidwr/(talk)/(contribs) 18:02, 19 April 2014 (UTC)
I attempted to withdraw this nomination but I wasn't fast enough, so the nomination discussion will continue. See #Removing XKCD for another discussion related to the use of this comic in this article. davidwr/(talk)/(contribs) 18:52, 19 April 2014 (UTC)

Reference to the xkcd strip definitely needs to go in the article, not as a technical explanation, but to reflect the public reception of the incident. It´s likely the single most viewed publication refering to it. --129.13.72.198 (talk) 11:00, 22 April 2014 (UTC)

I imagine heartbleed.com reached a much wider audience. If you've got any sources that talk about the impact of the comic, though, go ahead. --McGeddon (talk) 11:11, 22 April 2014 (UTC)

Discoverer(s)[edit]

It is clear that Mehta reported the discovery first to the OpenSSL team. Both Codenomicon and Google/Mehta also acknowledge Codenomicon in some way. Codenomicon describes it as a straightforward independent discovery. Mehta does not go into detail, but does congratulate them on Twitter. Per NPOV, I think we should provide this information and let the reader draw their own conclusion. Thus, I've put back the text citing Heartbleed.com about this, and added Mehta's Twitter statement. Superm401 - Talk 23:57, 11 April 2014 (UTC)

Proposed move to "Heartbleed bug"[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: No move. Supports and opposes were about evenly split. There were essentially two points of argument: whether "heartbleed bug" was the subject's common name over just "heartbleed", and whether the bug is the WP:PRIMARYTOPIC for "heartbleed" (and therefore, whether the dab page should be at "heartbleed"). Several editors suggested other articles or topics existed that challenged the bug's status as primary topic, but this largely was not in evidence. I detect a rough consensus against moving this article and replacing it with a dab page. Several editors who supported (or were amenable to) a move specifically felt "heartbleed" should remain a redirect. However, the level of support still did not reach consensus for a move. No other proposal garnered much support; as such I'm closing as "no move." Cúchullain t/c 20:42, 24 April 2014 (UTC)



HeartbleedHeartbleed bug – This is likely going to be a current events report that will pass from memory in a few months once all internet services have patched their latest version of OpenSSL, whereas "heartbleed" is a common term referring to any number of heart conditions and should have been left as a disambiguation page. Per Wikipedia:Article titles#Deciding on an article title criteria:

  1. Recognizability: Everyone would know heartbleed in the software sense of the term, that is as a software bug, if it is moved to the new title. In the more persistent and long-term medical sense of the word, everyone would be more likely to know heartbleed as a problematic condition of the heart that occurs, well, when the heart bleeds.
  2. Naturalness: A disambiguation would be more likely to point users to a number of terms they could choose from when searching through Wikipedia, and not always about the software sense of the term for a couple technical know-how nerds. As it is, we are giving undue weight and catering unnecessarily to the smaller technical community while obscuring with a hatnote what the more common use of this term should be in the worldwide community - the medical sense.
  3. Precision: Should be self-evident.
  4. Conciseness: Perhaps not as a concise, but definitely more precise.
  5. Consistency: I am open to suggestions to make this more disambiguated, such as "Heartbleed (software)" or any number of article titles that would better serve our readers.

Let me know what you think. TeleComNasSprVen (talkcontribs) 07:40, 12 April 2014 (UTC)

  • Support - per semi-official website, BBC News, NYTimes, CNet, TIME --TitoDutta 08:04, 12 April 2014 (UTC)
    • Note that while http://heartbleed.com names it as "Heartbleed Bug" (note the capitals), the other sources linked merely use the word 'bug' as a qualifier. - hahnchen 17:37, 13 April 2014 (UTC)
  • Support - per above noted reasons - makes *very* good sense to me atm - (fwiw - seems "Heartbleed bug" was the original name of the article before being renamed/moved to the present name "Heartbleed" by Xeno on April 10, 2014) - in any case - Enjoy! :) Drbogdan (talk) 12:56, 12 April 2014 (UTC)
    FYI I moved it here per a user's request here, which seemed reasonable - perhaps Hahnchen would like to elucidate their rationale. If the consensus is that the page is best named "Heartbleed bug", I have no issue with it being moved back. If that occurs, 'Heartbleed' should redirect to 'Heartbleed bug', at least for now. I do note that the Heartbleed disambiguation makes no mention of the medical heart bleeding conditions referenced in the original proposal. –xenotalk 18:20, 12 April 2014 (UTC)
@Xeno - Thank you *very much* for your comments - and clarification - no problem whatsoever on my part - Thanks again - and - Enjoy! :) Drbogdan (talk) 19:36, 12 April 2014 (UTC)
  • Support - per above noted reasons; the new article title is more descriptive! — Charles Edwin Shipp (talk) 13:16, 12 April 2014 (UTC)
  • Support per above. Crumpled Fire (talk) 14:20, 12 April 2014 (UTC)
  • Support. It started as Heartbleed bug. It's too bad that the reduction to Heartbleed was not discussed before it was changed. DavidMCEddy (talk) 15:05, 12 April 2014 (UTC)
  • Support - per above noted reasons Tschild (talk) 16:15, 12 April 2014 (UTC)
  • Oppose - I CSDed Heartbleed because it was an unnecessary redirect to Heartbleed bug. Heartbleed is a bug in OpenSSL, there's no official designation that its full name is "Heartbleed bug", the bug is just a descriptor. Following Wikipedia naming conventions, it should be Heartbleed (bug). If Heartbleed is such a "common term" referring to heart conditions, why is it that there is nothing at Heartbleed (disambiguation), nothing at Google Scholar, nothing on Google Books. - hahnchen 18:35, 12 April 2014 (UTC)
  • Speedy support - let the next admin just move this. Red Slash 18:42, 12 April 2014 (UTC)
    • But obviously the bug is primary topic for heartbleed Red Slash 20:21, 12 April 2014 (UTC)
  • Support per above reasons.Cmoibenlepro (talk) 01:44, 13 April 2014 (UTC)

Proposition. Move page to 'Heartbleed (bug)' and leave 'Heartbleed' as a disambiguation page, as some heart conditions do warrant the name. Ging287 (talk) 18:47, 12 April 2014 (UTC)

  • What heart conditions? I've asked WP:MEDICINE, but I'm unconvinced. - hahnchen 18:50, 12 April 2014 (UTC)
I have no opinion either way regarding if the "bug" is better or worse here, but I have never once heard "heartbleed" being used to refer to any medical condition, and the searches hahnch linked reflect that. A regular google search for "heartbleed" refers entirely to the bug this article refers to. Cannolis (talk) 19:11, 12 April 2014 (UTC)
1) Because it's Google. 2) Because they're more prone to the sad recentism bias I'm seeing more and more in Wikipedia. TeleComNasSprVen (talkcontribs) 06:06, 13 April 2014 (UTC)
Until the heartbleed bug became world news, heartbleed was a red link. Anyone erroneously looking for medical conditions where the heart is bleeding who typed "heartbleed" was out of luck, and it's doubtful this is the term they would have used anyway, the term not having any basis in medicine. And now because you have some vague concern about recentism, you want to send our readers past a disambiguation page before they get to the article they are looking for. I disagree. And it should be noted that if this move finds consensus, there will still need to be a further discussion on whether "heartbleed" should redirect to the bug or the disambiguation page. –xenotalk 16:06, 13 April 2014 (UTC)
For the near future, anyone typing "heartbleed" into the search box is looking for the bug. So heartbleed should lead to the bug, at least for a while; we should not force readers past a disambiguation page first. –xenotalk 20:17, 12 April 2014 (UTC)
As I explained in my rationale, I'm afraid that there's a strong bias to point an article to a current event that primarily only serves the needs of the technical community, one that is oft-repeated in more reliable news sources than Wikipedia, and that is a short-term goal we ought to avoid. In general, I hope Wikipedia avoids its tendency to become a news station and focus on long-term goals. In fact, when I first hear the term "heartbleed" around an instant messaging site, I initially thought of a heart rupture until they pointed me to the heartbleed.com website where it was elaborated to be a software bug. Also, I am also fine with "Heartbleed (bug)" or any other article title as a good substitute suggestion, but for now the proposed move is toward "Heartbleed bug".
I would also like to point out that "Heartbleed" need not be an exact medical term of any sort, but a vernacular construction that could refer to heart ruptures or any other kind of medical condition that might lead to, well, the heart bleeding. Neither "brain bleed" nor "stomach bleed" are official medical terms in any medical encyclopedia (notice the former conveniently points to cerebral hemorrhage), but Wikipedia should serve those readers not having knowledge said medical terms. Some reading: Bleeding heart, myocardial rupture, myocardial infarction, hemopericardium, cardiac tamponade, first image of a bleeding heart, dissection of the aorta --TeleComNasSprVen (talkcontribs) 02:29, 13 April 2014 (UTC)
Ah, I recognize the problem now. According to Wikipedia:Disambiguation#Is there a primary topic? there is currently a conflict and/or tension between "a topic of primary usage and one of primary long-term significance". That might best describe the situation up for discussion here. --TeleComNasSprVen (talkcontribs) 02:33, 13 April 2014 (UTC)
When you first heard "heartbleed", you thought it was some medical condition. You thought wrong. Heartbleed is the concise and precise name for this vulnerability. Heartbleed was a redlink before the bug turned up. Brainbleed is still a red link. Wikipedia has a strong bias towards being right, not towards whatever gut feelings a layman might have, or is that Gutfeel? - hahnchen 03:28, 13 April 2014 (UTC)
Yes, I thought wrong but it was more than obvious why. And thanks for pointing out the redlink, I've fixed that. Whether or not Wikipedia has a strong bias towards being right is irrelevant, as Wikipedia follows verifiability, not truth. TeleComNasSprVen (talkcontribs) 03:47, 13 April 2014 (UTC)
If you truly think our readers are typing "heartbleed" and looking for something other than the bug, you would serve them well to go add whatever articles you think they are looking for to the heartbleed disambiguation page. A hatnote leads there. –xenotalk 05:06, 13 April 2014 (UTC)
Thank you, the disambiguation page has been ameliorated. TeleComNasSprVen (talkcontribs) 06:06, 13 April 2014 (UTC)
  • Note: FWIW, after cursory examination, currently wikipedia nomenclature demonstrates a lack of popularity for any title with the term "bug", not counting books or film
    • Historically Code Red of 2001 already had the alias "heart bleed"
    • Category:Software bugs does not reflect strong usage, and none parenthetical
    • List of software bugs only reflects the two links: software and heartbleed
    • Wetware apparently has the precedent implementing the parenthetical, like Velia (bug) -- this could be confusing of the two fields, biology versus computer, if you are setting or breaking a precedent for usage WurmWoodeT 21:51, 12 April 2014 (UTC)
  • Oppose, due to the rationale given by the proposal. "Heartbleed" is not the common term of any heart condition, and the majority of google hits refer to the security bug, not any medical condition. Furthermore, if the chambers of the heart do rupture, death is guaranteed, so in practical terms you cannot have a medical "condition" called heartbleed. --benlisquareTCE 05:13, 13 April 2014 (UTC)
    • If it is refuting the original points of the proposal, I think that would qualify as a regular oppose. I'm not sure why you would qualify it as "procedural" when you disagree with the medical connotations.
    • More to the point, what you have quoted me referring to as a medical "condition", is simply my explanation that the vernacular construction is often interpreted literally, i.e. the physical heart bleeds. Medical connotations simply follow from that construction; it is not, inherently speaking, "medical". TeleComNasSprVen (talkcontribs) 06:06, 13 April 2014 (UTC)
  • Weak support for changing the title to "Heartbleed bug"; oppose making Heartbleed a disambiguation page rather than redirecting to this article. As has been pointed out, Heartbleed was always a red link before this - it is very unlikely that anyone would be searching for any other topic under that name, so the proposal would merely make life more difficult for thousands of users (especially if the bug meaning is to be hidden away near the bottom of the disambiguation page, as someone has rather precipitously already done). I also checked out Google Books and Scholar (as I now see above someone else has also done) and there is absolutely nothing of relevance under "Heartbleed". The claim that it's some kind of medical term, vernacular or otherwise, is a pure red herring. It certainly could be used as such, but it isn't, so the possibility needn't concern us. I'm not sure these newly added medical conditions should even be on the disambiguation page at all (except possibly under "see also"). W. P. Uzer (talk) 08:07, 13 April 2014 (UTC)
    • How so? Information about the heartbeat bug is already on the top of the list for Google search hits, and we're mainly regurgitating news articles and other sources about something most (technical-minded) people would know about anyway. It'd stay at the top for a few years, and Wikipedia's article on it would not make a difference; after that, it'd fall off as old news and everyone will forget about it, and Wikipedia's article on it would still not make a difference. Either way, users would reach this article whether they feel like it or not, which is in my opinion a short-sighted goal. Wikipedia has been suffering from a rash of recentism lately. TeleComNasSprVen (talkcontribs) 08:32, 13 April 2014 (UTC)
    • Well that's interesting. I checked out Google Books and it seems the primary sense of the term is in a metaphorical sense or literary device. What does it mean though, and how does it relate to the bug? Is it popular enough a meaning? TeleComNasSprVen (talkcontribs) 08:40, 13 April 2014 (UTC)
  • Despite stating that heartbleed was a "common term" for a medical condition, and that use is "more persistent and long-term", you've only figured out a day later that its only use case is a typo when using the idiom, "my heart bleeds". You state above that Wikipedia relies on verifiability, on sources, yet you've offered none but your Gutfeel which is now bleeding out into the mainspace. - hahnchen 17:37, 13 April 2014 (UTC)
  • No, it's just a rare word (or more commonly, a misspacing of "heart bleed", as in "makes my heart bleed"). Wikipedia is not a dictionary (and even Wiktionary doesn't list this word, nor do any of the print dictionaries I have to hand). The only encyclopedia topic for this term is the software bug (plus a couple of obscure songs). It's not a case of recentism at all, just that there is no other significant meaning whatever, so nothing to be gained for anyone, either now or in the future, as far as we can tell, by making thousands of users scan for and click additional links in order to get the page they want. W. P. Uzer (talk) 09:03, 13 April 2014 (UTC)
  • Support changing the title. I think TeleComNasSprVen expresses it well, and I agree with the user's interpretation of our titling criteria. (I would actually say that the conciseness criterion arguably supports "Heartbleed bug" as well, given that being concise does not simply mean being brief but rather being brief while conveying much... and the current title doesn't convey enough to be sufficiently clear.) ╠╣uw [talk] 11:13, 13 April 2014 (UTC)
  • Oppose. The name of the bug is "Heartbleed", not "Heartbleed bug", so per WP:PRECISE and WP:CONCISE, "Heartbleed" should be the title of the article about the bug unless there is ambiguity AND the bug is not the WP:PRIMARYTOPIC. As others have mentioned, the supposed ambiguity is a red herring and there is no evidence that there's a medical condition that is also widely known as "heartbleed". But even if there is such a medical condition, I remain unconvinced that the bug is not the primary topic. —seav (talk) 17:12, 13 April 2014 (UTC)
  • Strong Oppose per User:Seav, User:hahnchen, User:Xeno, User: WurmWoode and others. Heartbleed is the most common name, and the term most will come here looking for. Bug is unnecessary, not part of the common name, and heartbleed is not a medical term, so there is no confusion. Also very little precedent for use of "bug" in titles. Per especially WP:COMMONNAME, as well as WP:PRIMARYTOPIC, WP:CONCISE, & WP:PRECISE. To move this article as suggested would be against policy. The semioffical website is Heartbleed.com, not HeartbleedBug.com — Becksguy (talk) 01:49, 14 April 2014 (UTC)
  • Oppose, strongly. Per many others above, the bug is known simply as heartbleed. There are also no medical conditions commonly referred to as heartbleed. Thus, there is no reason to move the bage. Calidum 04:57, 14 April 2014 (UTC)
  • Oppose, strongly. Checking Google Books, use of the single word Heartbleed is extremely rare, it occurs only when a space is left out. Only use I see is for the name of a character "world's shyest white-hat hero, Heartbleed Haymeadow". Malaiya (talk)
    • Huh? What?! Are you seriously suggesting that a newly discovered bug not used in Google Books is a valid reason to reject the most commonly used name? Seriously? A Quest For Knowledge (talk) 23:28, 16 April 2014 (UTC)
      • No, they're saying that "heartbleed", without spaces, is not used often in Google books. Therefore, they conclude, "Heartbleed" was not used to refer to anything in conventional literature previously and most likely just refers to the bug in OpenSSL. – FenixFeather (talk)(Contribs) 00:17, 17 April 2014 (UTC)
      • So, are you acknowledging that using Google Books for a brand new security vulnerability in which no books have been written is meaningless? A Quest For Knowledge (talk) 13:50, 19 April 2014 (UTC)
        • You have misunderstood. The term "heartbleed" isn't found in Google Books. Therefore, it only refers to the newly discovered bug, not to a medical condition. That means the page can be kept at Heartbleed, because there is no clash. Mahahahaneapneap (talk) 14:53, 19 April 2014 (UTC)
  • Strong oppose. "Heartbleed" is the concise title. If there ever exists an article on the medical term "Heartbleed", this issue can be looked at again, but until such an article exists? There's no reason at all to move this. SnowFire (talk) 16:49, 16 April 2014 (UTC)
  • Oppose. There is no medical condition commonly referred to as "heartbleed", so little to no chance of confusion. "Heartbleed" is a common (and probably the most common) name for the security vulnerability. Psychonaut (talk) 17:15, 16 April 2014 (UTC)
  • Support It's the most common name in English. A Quest For Knowledge (talk) 23:23, 16 April 2014 (UTC)
    • Can anyone provide any evidence, one way or the other, as to which of "Heartbleed" or "Heartbleed bug" (or possibly "Heartbleed Bug") is more common, rather than just making unsupported statements? This discussion has become rather confused, since there are effectively two questions being addressed. We have hopefully debunked now the suggestion that this might not be the primary topic for the term "Heartbleed", but even without that spurious claim, it might still be the case (on other grounds) that the word "bug" ought to be included in the title. W. P. Uzer (talk) 06:54, 17 April 2014 (UTC)
  • Support I only knew it as "that internet bug that means I have to change my passwords," so I looked up "security internet bug" on wikipedia to find out what it was. It might have been easier to locate from there if it had been labeled "Heartbleed butt"93.209.55.56 (talk) 14:58, 17 April 2014 (UTC)
    • If you search for "security internet bug" on Wikipedia, the second result is Heartbleed bug, which redirects to Heartbleed. I don't think this is a valid reason Mahahahaneapneap (talk) 17:43, 17 April 2014 (UTC)
      • True. Alright, I agree that my reasoning was silly, but I still support moving for reasons of clarity, to Heartbleed (bug) or Heartbleed bug. (same person different computer)93.209.55.56 (talk) 22:13, 17 April 2014 (UTC)
  • Oppose both "Heartbleed bug" and "Heartbleed (bug)". "Heartbleed bug" is very clearly against naming conventions. "Heartbleed (bug)" is slightly better, but until there is another especially notable article is named "Heartbleed" or it is shown that there is significant use of the term "Heartbleed" in the literature outside of discussions of the bug itself, there is no need to move the article. – FenixFeather (talk)(Contribs) 20:35, 17 April 2014 (UTC)
  • Support either "Heartbleed bug" or "Heartbleed (bug"). I did a Google books search for "heartbleed", and the results were overwhelmingly variants on "my heart bleed" , so "heartbleed" should probably redirect to Bleeding heart (disambiguation). --BrownHairedGirl (talk) • (contribs) 16:37, 21 April 2014 (UTC)
As we've already been over, the results were overwhelmingly misprints, and they rarely referred to any physical bleeding. And there were so few results anyway that we can safely conclude from them that this is not a word that significant numbers of people would be using to seek information about bleeding hearts (and still less about any of the topics listed at Bleeding heart (disambiguation), which don't include anything about hearts actually bleeding either), compared with the number using it to find information about this bug, which for obvious reasons will not have found its way into any books as yet. Some common sense is required when drawing conclusions from Google... W. P. Uzer (talk) 17:55, 21 April 2014 (UTC)
  • I'm equally comfortable with the current and proposed titles. The current title is concise and a primary topic, but "Heartbleed bug" is essentially fine, as it's a commonly used phrase and doesn't add too much in terms of length. Oppose Heartbleed (bug) as unnecessary parenthetical disambiguation. If we determine "Heartbleed" is insufficient, we should use WP:NATURAL disambiguation. (Edit: I'm really only ok with "Heartbleed bug" as a phrase of its own. There is a primary topic, so disambiguation is not called for, natural or otherwise.) --BDD (talk) 22:43, 21 April 2014 (UTC)
  • Oppose. This move request and much of the support are based on the flat-out incorrect claim that "heartbleed" is "a common term referring to any number of heart conditions". As far as I can tell, this supposition was pulled out of thin air, as there's absolutely no evidence that the term commonly refers to anything (be it a medical condition or something else) other than this article's subject. The two obscure songs are listed on the disambiguation page, properly linked from this article via a hatnote. Titling an article in accordance with a term's only common use isn't "recentism", no matter how recently said usage arose. —David Levy 01:57, 22 April 2014 (UTC)
  • Comment: Further argument against renaming is that actually the term bug applies to the software error in the coding, not what happened in internet security or the press or blogosphere as a result. Heartbleed is the exploit, not the bug. Bugs are coding or logic errors that may, or may not, lead to exploits, or be the means for an exploit, but they are not the same thing. An exploit is an attacker using an error or vulnerability (actually or potentially) to gain access to a system and cause harm or compromise it, or to exfiltrate data from a system that is of value, such as crypto keys, plaintext, or whatever. Suppose an owner uses their car to go shopping and forgets to take the ignition key, thus leaving the key in the ignition, which is a mistake or error. A potential criminal sees the key, and using that as a means to commit a crime, steals the car. Stealing the car is the exploit, by exploiting, or taking advantage of the error. Forgetting the key and stealing the car are not the same thing, neither is the software bug and the exploit called heartbleed the same thing. In both cases one is a means to commit the other (crime or exploit). Renaming would violate the policies I referenced before. — Becksguy (talk) 02:56, 22 April 2014 (UTC)
    • But "Heartbleed" is rather the name attached to the bug (as on the official site and many other reports). It might seem to us a little more logical for that word to refer to the exploit than to the error, but it's not up to us to decide what things ought and oughtn't to have been called. W. P. Uzer (talk) 06:57, 22 April 2014 (UTC)
      • I think what he's saying is that Heartbleed refers to the crisis in general, whereas Heartbleed bug refers to the bug that caused the crisis. So Heartbleed is a better way to describe the events. Sort of like how Watergate refers to the entire scandal, but the Watergate bug was the bug that was planted at Watergate hotel. – FenixFeather (talk)(Contribs) 03:31, 24 April 2014 (UTC)
  • Oppose: No such medical condition in evidence. Nom appears to be confused at best. If there was already DAB page with entries on it that would be won thing, but ti is an obvious case where the primary, really only, topic is this bug, so the disambiguation isn't necessary (nor would it be necessary to use "(bug)" where the plain-Englsh "bug" will do fine, should it ever become necessary).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:12, 24 April 2014 (UTC)
  • Oppose: When looking through sources listed as supporting saw several cases were after bug was mentioned once it was just referred to as heartbleed. I agree that there doesn't seem to be a disambiguation problem, so concise seems to be the way to go. As for the passage of time and Heartbleed by itself not being recognized as well.. that can wait til it is an issue. There is also the advantage of looking at the bug and the impact as separate but related things, and agree with the points above on the matter. PaleAqua (talk) 07:30, 24 April 2014 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

total length of a HeartbeatMessage: 2^14 or 16 KByte, not 64 KByte[edit]

RFC6520: The total length of a HeartbeatMessage: 16 KByte, not 64; source: So funktioniert der Heartbleed-ExploitGermany J744 (talk) 20:59, 12 April 2014 (UTC)

That ignores the precept RFC 6066, wherein "max_fragment_length" may be negotiated to be larger (bending the rules), thus allowing the buffer overrun (breaking of the rule, maximally), retrieving 2^16 (64K), or whatever was successfully negotiated. The difference (RTFM) between a pro versus a newb? WurmWoodeT 21:51, 12 April 2014 (UTC)
Speaking of RTFM, I don't see the possibility to increase the length in RFC 6066 ("The allowed values for this field are: 2^9, 2^10, 2^11, and 2^12."), nor any support for fragment length negotiation in OpenSSL 1.0.1f/g at all. --Matthäus Wander (talk) 19:59, 14 April 2014 (UTC)

When requesting more than 16KB, a vulnerable server responds with multiple Heartbeat responses, each 16KB, totalling up to 64 KB. Example. --Matthäus Wander (talk) 21:03, 14 April 2014 (UTC)

Duplicate sentence[edit]

  • Sentence: "LogMeIn claimed to have "updated many products and parts of our services that rely on OpenSSL"."
  • Locations: Section: Affected services:
    • subsection: Websites and web services, bottom of section
    • subsection: Software applications, bottom of section

The identical sentences are 5 list item/section titles apart, perfectly easy to see on one screen. I would leave the full quote in the first subsection, for informational purposes, with the second being reduced to "LogMeIn"<ref>. However, I do not know enough about LogMeIn to know if there is something more appropriate, such as website or software, not both? 71.234.215.133 (talk) 10:42, 13 April 2014 (UTC)

Resolved
I seem to remember this being fixed a long time ago. --Chealer (talk) 07:30, 1 May 2014 (UTC)

Dissertation of the Programmer[edit]

What strikes me is the fact that the programmer in his Ph.D. explicitely mentioned the possibility to exploit the payload mechanism which he himself had implemented just before:

"The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport. The padding, on the contrary, always has to be of random data and is not sent back. The length of the padding is arbitrary, but should always be 16 bytes or more for security reasons, to prevent statistical attacks in case the payload is predictable. This can be the case if an implementation only uses sequence numbers for the payload of its requests. Without additional random bytes this payload can be guessed easily, thus making it prone to a KnownPlaintext Attack (KPA) [94]." [5], p.67

I tried to find a formulation to express this striking coincidence which might lead to the impression that the programmer was well aware about what he was contributing, although of course there could be other explanations as well. My contribution apparently sounded to biased to User:Per_Olofsson and he removed it. Please help me to find a wording neutral and subtle enough for WP:en, so that either interpretaion about deliberate intensions would be possible. I am not a native speaker in English so I might fail here. --HV (talk) 14:06, 13 April 2014 (UTC)

Thanks for your work! Someone will assist; others will further refine, if necessary. — Charles Edwin Shipp (talk) 16:51, 13 April 2014 (UTC)

Except that it is about the heartbeat feature he implemented, the quoted text has nothing to do with the bug. The discussed attacks are fundamentally different from the actual bug. No chance for conspiracy theories or original research.93.104.51.24 (talk) 21:32, 13 April 2014 (UTC)

But the excerpt shows at least that the developer being a security expert was very well concerned with the issue in which he himself had failed to be careful enough. How can this be explained? Serious lack of memory or concentration? Purpose? Other explanations? In any case it is an inevitable part of the whole scenario and thus should be mentioned in a reasonable and neutral fashion. --HV (talk) 21:43, 13 April 2014 (UTC)
Addition: neither conspiracy theory nor original research intended by me. Therefore I ask for collaboration. --HV (talk) 21:45, 13 April 2014 (UTC)

Explanation: He was blackmailed by the NSA but wanted give a secret hint about this in his dissertation by suggesting that he is a security expert worrying about security, since smart persons would know that such a person would never work on OpenSSL. Unfortunately, now since this section of his dissertation is public, the NSA will kill him before we can reveal details of this evil plot. Have a nice day! 93.104.42.169 (talk) 22:54, 13 April 2014 (UTC)

Even better explanation: he was forced by aliens to translate a portion of Nostradamus into code and a chapter of his dissertation... No, I don't want any speculation about inner or outer reasons for this coincidence, but rather a dry and short description of the fact, which might have a legion of possible reasons, including amnesia, simplemindedness and pure accident. It's the circumstances which matter here because they do give a perfect scenario for a potential social hack (regardless if it really happened or not). These circumstances are part of the story and of encyclopedic relevance. What will happen in the fantasy of our readers, even if some of them become paranoid, is none of our business. Did you get my point? --HV (talk) 05:16, 14 April 2014 (UTC)

As 93.104.51.24 notes, the passage you are quoting does not describe the actual bug at all. I am not sure what you think is suspicious about the quote, but it does not say anything about buffer overflows. Even if he did discuss buffer overflows in his thesis, I do not think it is appropriate to point out "coincidences" on Wikipedia like that. On the other hand, if you can find a reliable source that discusses this, then you could cite that source. Otherwise I think it constitutes original research. (And in this case I believe you are mistaken, but that is beside the point.) --Per Olofsson (talk) 09:51, 14 April 2014 (UTC)

I should also note, HV, that I do not think you are biased and I did not specifically object to the exact wording. I reverted your edit because I felt it constituted WP:OR, more specifically WP:SYNTH. If you can find a reliable source that discusses coincidences in the thesis regarding the Heartbleed bug, then I have no problem if you cite it on the page. However, in this case, I felt you were creating a synthesis by implying something that the source did not state. --Per Olofsson (talk) 10:18, 14 April 2014 (UTC)

I agree that this is irrelevant to the software bug. It is worth mentioning the padding requirement in the article about DTLS though, if that article gets expanded. 70.36.142.114 (talk) 15:26, 14 April 2014 (UTC)

"OpenSSL must die"[edit]

Git vulnerability[edit]

Current version of the article has this entry in the list of vulnerable appications: "git 1.9.1 tested clone / push, leaks not much". Git uses multiple ways of communication [7]. The article should specify which of those are affected.Muelleum (talk) 21:57, 15 April 2014 (UTC)

I don't think Git has an embedded http/s server. You put your repo under a separate web server that might or might not have the heartbleed bug. 70.36.142.114 (talk) 11:09, 16 April 2014 (UTC)

Copyright (attribution) problems[edit]

FYI: I've mentioned this article on WT:CP. --Muelleum (talk) 00:44, 16 April 2014 (UTC)

Removing XKCD[edit]

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.
No offense to you personally, ArnoldReinhold, I'm sure you're acting in good faith. A Quest For Knowledge (talk) 10:38, 19 April 2014 (UTC)
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)
I've added content sourced to third-party reliable sources to the article about this comic.[8] A Quest For Knowledge (talk) 12:03, 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). ~SuperHamster Talk Contribs 19: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. ~SuperHamster Talk Contribs 20: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.
In any case, File:Xkcd.com-1354-how-the-heartbleed-bug-works.png needs a {{Non-free use rationale}} template placed in the summary, such as the one at File:Xkcd - Heartbleed Explanation by Randall Munroe.png. It might even be best to use the earlier existing file & Upload a new version of this file since that file & its discussion precedes the File:Xkcd.com-1354-how-the-heartbleed-bug-works.png file.
Peaceray (talk) 20:28, 19 April 2014 (UTC)
Re "my main intent was to drive traffic to the comic" - hmm, what to do, what to do, what to do ... WP:NOTPROMO is a policy, but so is WP:IAR.
I'm sure your real intent was to improve the article by adding educational material, right??? Right??? Face-smile.svg davidwr/(talk)/(contribs) 21:06, 19 April 2014 (UTC)
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. ~SuperHamster Talk Contribs 21: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!
Peaceray (talk) 23:40, 19 April 2014 (UTC)
To be honest, the current graphic does look a bit Microsoft painty. I could try putting together a more polished one. – FenixFeather (talk)(Contribs) 00:35, 20 April 2014 (UTC)

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

svg version (Should be easy to edit with Inkscape)

raster version

FenixFeather (talk)(Contribs) 01:06, 20 April 2014 (UTC)

Wikipedia like thumb.png
I like the raster version! Peaceray (talk) 02:13, 20 April 2014 (UTC)
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)

Simplified Alternative[edit]

So after a lot of problems I've finally managed to upload a proper svg to commons. Let me know what you all think! – FenixFeather (talk)(Contribs) 03:20, 20 April 2014 (UTC)

Example alt text
Simplified Heartbleed explanation
I think it's good, but you need to label both 'Server' and the 'Client'. Then it'll be perfect. Tutelary (talk) 04:28, 20 April 2014 (UTC)
Thanks for the feedback. I'll add it. – FenixFeather (talk)(Contribs) 04:31, 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)
Looks great, well done guys :) ~SuperHamster Talk Contribs 12:45, 20 April 2014 (UTC)
Thanks!! I've made the text bigger and added server text per your suggestions. – FenixFeather (talk)(Contribs) 17:23, 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[edit]

Here is the same content (give or take a few minor details) as a table:
davidwr/(talk)/(contribs) 04:22, 20 April 2014 (UTC)

Looking pretty good. But with the above image, there needs to be a label on what is what. Tutelary (talk) 04:29, 20 April 2014 (UTC)

  • I like this. Perhaps we could add some icons so that casual readers understand what each party is. Perhaps something like Computer.svg and Server-tower.svg. Mahahahaneapneap (talk) 12:35, 22 April 2014 (UTC)

earlier bug[edit]

Might be worth mentioning this: https://www.debian.org/security/2008/dsa-1571

It was worse than Heartbleed in some ways, it affected a heck of a lot of systems (not as many as Heartbleed but still a lot), but it didn't have the marketing campaign so nobody remembers it now. 70.36.142.114 (talk) 11:43, 18 April 2014 (UTC)

Lessons Learned by Internet users[edit]

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)

The concluding paragraph is bogus[edit]

The concluding paragraph is bogus. There are tons of bugs in proprietary software too.[9] 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. [10] 70.36.142.114 (talk) 03:04, 20 April 2014 (UTC)

Let's fix it. — Charles Edwin Shipp (talk) 14:18, 21 April 2014 (UTC)
Prior to the concluding paragraph, I'd like to see an additional section, "Lessons Learned by Internet users". Charles Edwin Shipp (talk) 19:34, 21 April 2014 (UTC)
Resolved
The offending paragraph has been removed.
Otherwise, the section already discusses some technicalities, but feel free to expand. --Chealer (talk) 07:21, 1 May 2014 (UTC)

Heartbleed certificate revocation[edit]

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.[11] A Quest For Knowledge (talk) 02:08, 20 April 2014 (UTC)

Meh, Adam Langley argues that online CRL checking is useless.[12] 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)

If it's just a question of placement, I've moved it out of the list. Hopefully, this addresses Chealer's concerns. A Quest For Knowledge (talk) 06:11, 21 April 2014 (UTC)
Resolved
It does, thanks. --Chealer (talk) 07:28, 1 May 2014 (UTC)

reverse heartbleed[edit]

Anyone wanting to add the above, please feel free. I may not get a chance to do it today, and I'll probably be offline for several days starting in a few hours. 70.36.142.114 (talk) 19:35, 20 April 2014 (UTC)

Often, blogs require additional supporting documentation. — Charles Edwin Shipp (talk) 14:27, 21 April 2014 (UTC)

Cost[edit]

It would be interesting to include an approximation of the cost of Heartbleed. According to [13], "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)

Original research[edit]

I've removed this[14] 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)
Please do it, thanks.RenniePet (talk) 15:57, 21 April 2014 (UTC)
Resolved
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 [15]). 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)

Latest Current new News[edit]

Headine-1: Heartbleed Will Require Rehab

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.

Security Now[edit]

I just wanted to mention that Security Now has been providing some excellent, in-depth coverage of this topic:

A Quest For Knowledge (talk) 23:15, 23 April 2014 (UTC)

Lastpass request for reference[edit]

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 [16] 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://en.wikipedia.org/w/index.php?title=Heartbleed&diff=605482274&oldid=605482150 Tutelary | 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)
According to LastPass Password Manager, their product is known as "LastPass Password Manager". It does make sense for a physical or moral person to be vulnerable to an exploitation of Heartbleed. --Chealer (talk) 17:15, 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://en.wikipedia.org/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)
Please assume that your colleagues act in good faith. There was an edit conflict and a change was lost. There is unfortunately no consensus at this point on this issue, but it would help if everyone could stay civil and pursue discussion rather than pursuing an edit war. --Chealer (talk) 02:27, 28 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)
Not to mention that they regularly use "Lastpass" as the short version of their product. Tutelary (talk) 18:19, 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[edit]

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)
Sorry didn't realize it was the same. True enough about sounding promotional. PaleAqua (talk) 21:38, 30 April 2014 (UTC)
I recognize that the sentence is correct, but I also support its removal, for reasons you mention. --Chealer (talk) 21:44, 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.

Although I recognize that his comment doesn't constitute endorsement for removal like mine. --Chealer (talk) 21:01, 3 May 2014 (UTC)
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)

Requesting periodic reassessment of "importance" for WikiProjects[edit]

Wikipedia:WikiProject_Internet/Assessment#Importance_scale gives Netscape Navigator as an example of a mid-importance article. There was a time that NS Navigator was the web browser.

Yes, Heartbleed probably was a top-importance article when the news first broke and it might still be, but within a month it will probably drop to High-importance and within 6 months it will probably be at mid-importance or lower.

If anyone sees this message after June 1, 2014 please re-assess the importance. Ditto if anyone sees this message after about December 1, 2014. davidwr/(talk)/(contribs) 02:37, 26 April 2014 (UTC)

I don't know if Heartbleed will ever drop to mid-importance. The ramifications of Heartbleed aren't just limited to mitigating the impacts of the exploit itself. Heartbleed was sort of a wake up call that a lot of infrastructure may depend on inadequately supported projects. We'll have to see the long term implications of Heartbleed to know for sure whether it was just a temporary crisis quickly forgotten or a key turning point in internet security. – FenixFeather (talk)(Contribs) 03:26, 26 April 2014 (UTC)
I hadn't construed importance as something time-dependent before reading this, but I think it makes sense for Heartbleed. Current view statistics show this article as being as popular as Internet... and these statistics are much lower than the peak. I agree Heartbleed should hopefully drop to High at some point, and perhaps to Mid in the long term. I wouldn't set it lower though. I had previously reduced the Computing importance from Top to High. --Chealer (talk) 20:28, 26 April 2014 (UTC)

Misleading donation figures[edit]

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]

This is misleading. The Wall Street Journal article which Kaminsky cited says,

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)

Edit warring "request for reference"[edit]

Chealer now insists that the patently obvious statement that a custom memory allocator caused the problem is false, and did not in fact cause Heartbleed. But the source clearly says:

So years ago we added exploit mitigations counter measures to libc

malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it's own, and not free it to the protective malloc.

I am confused as to why he insists on edit warring over things like this, but this is a necessary step before reporting him for repeated edit warring in this article. Previously, he had done this with LastPass and also refused to participate in Dispute Resolution. I expect similar recalcitrance this time around. – FenixFeather (talk)(Contribs) 00:08, 30 April 2014 (UTC)

What you cite is from [17]. As I explained in User_talk:FenixFeather#Heartbleed_-_Custom_memory_management, we can't claim that a custom memory allocator caused the vulnerability just because it prevented OpenBSD's countermeasures. OpenBSD is just one OpenSSL platform among many. --Chealer (talk) 01:25, 30 April 2014 (UTC)
He is an OpenBSD developer, but he is not talking about OpenBSD in the email. He is specifically explaining why OpenSSL failed; it has NOTHING to do with OpenBSD, despite the similarity in name. Because reading comprehension seems to be problematic for you, I will provide the email here and highlight all the relevant words:

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it's own, and not free it to the protective malloc.

You can find the comment in their sources ...

  1. ifndef OPENSSL_NO_BUF_FREELISTS

/* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Please just admit you are wrong and make constructive edits instead of tagging things and telling others to find ultraspecific sources only you demand. – FenixFeather (talk)(Contribs) 01:31, 30 April 2014 (UTC)
First of all, I am a very demanding person. I happen to have "adopted" this article a couple of weeks ago and to be its de facto "maintainer". Perhaps because of my perfectionism, the maintainers who I borrowed it from appear to have stopped watching it, which is unfortunate in a sense. This doesn't mean that nobody else cares about the article. In fact, it still has over 10 000 reads daily. I don't think what may be perceived as attention to detail is unwarranted. After all, Heartbleed has even affected this very website. That being said, let's try to focus on our content issue...
You may say Ted's mail isn't talking "about OpenBSD", but he's still talking in the context of OpenBSD. What Ted explains is not necessarily specific to OpenBSD. Some other operating systems share its security concerns and will also feature hardened memory management.
However, we would still be discussing Heartbleed had OpenSSL not used custom memory management. OpenBSD wouldn't, but we at Wikipedia and the world at large would still be discussing the bug and its impact on a lower number of systems. --Chealer (talk) 02:34, 30 April 2014 (UTC)
You don't own this article. In case you haven't read the sentence, I will post it again: "If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.". That is not in the context of OpenBSD. Just because he is the lead developer of OpenBSD does NOT mean his life and everything he says revolves around OpenBSD. If you are so interested in maintaining this article, go find real issues instead of quibbling over more requests for reference for obvious, common sense and stuff supported by reliable sources. By all means, if you are interested in finding another source, go right ahead. There is an excellent tutorial at WP:REFB, but there is no need to bother other editors about nitpicking for every small thing. – FenixFeather (talk)(Contribs) 02:38, 30 April 2014 (UTC)
Nobody fully owns this article (except for the sum of its authors, to be exact). Sorry to re-repeat myself, but I am not interested in sourcing that material per se. What I am interested in is to keep the article in compliance with our policies.
It is not the fact that the sentence was written by an OpenBSD developers which shows that it's in the context of OpenBSD. It is the fact that it was sent to an OpenBSD mailing list (misc@openbsd.org). Although it is not entirely OpenBSD-specific, as previously explained. --Chealer (talk) 03:10, 30 April 2014 (UTC)
All right then, glad you finally agree that the current source is sufficient. If you're interested in adding another source, go ahead and do a quick search and cite it. Trust me, it's not that hard to cite sources. Once again, I highly recommend WP:REFB. – FenixFeather (talk)(Contribs) 03:23, 30 April 2014 (UTC)
Uh... quoting myself:

I am not interested in sourcing that material per se. What I am interested in is to keep the article in compliance with our policies.

Nobody's ever denied that the current source was sufficient to support de Raadt's reproach to OpenSSL. The problem is just with the flagged sentence. --Chealer (talk) 03:46, 30 April 2014 (UTC)
Then I fail to see your problem. That source supports the entire passage, and I've explained countless times why it does. Can we just agree on that? If you want a better source, go find it. But cn is only for certain use scenarios. Note that the Wikipedia policy on cn says "If you have the time and ability to find an authoritative reference, please do so. Then add the citation yourself, or correct the article text. After all, the ultimate goal is not to merely identify problems, but to fix them. While an editor may add this template to any uncited passage for any reason, many editors object to what they perceive as overuse of this tag, particularly in what is known as "drive-by" tagging, which is applying the tag without attempting to address the issues at all (hit-and-run)." At this point, we can consider you to be guilty of drive-by tagging. I've seen you do this "request for reference" nonsense on the LastPass Heartbleed stuff, on this business, and on the LastPass article too. User:Tutelary was kind enough to find a source for you, but seriously, you need to stop. You've spent so much time arguing for the addition of a tag, that you could've spent that time finding the source you so dearly wanted. WP:FIXTHEPROBLEM instead of dragging people into this sort of thing every time you decide in your delusional alternate reality that a source does not support a claim here. – FenixFeather (talk)(Contribs) 03:59, 30 April 2014 (UTC)
Quoting myself:

The problem is, how do you "fix the problem" (pun intended)? There are 2 approaches to making articles verifiable - sourcing problematic content appropriately, or removing problematic content. Possibly out of respect for my colleagues, I prefer to give sourcing a chance rather than directly removing content (sometimes even when I'm confident that the content is unverifiable, indeed).

No, that source does not support the entire passage. I take orders from my employer and customers, not from strangers. Even if you offered the money, I guess I would lack "the time and ability to find an authoritative reference" which I'm confident doesn't exist. As I said, my LastPass-related edits show that giving sourcing a chance doesn't prevent me from removal when it becomes clear that content is unverifiable. I usually act the same regardless of the chances a given claim has to be verifiable, but if you prefer, you can read "challenge" instead of "request reference". --Chealer (talk) 06:12, 30 April 2014 (UTC)
Oh and by the way, since you've taken it upon yourself to be the primary maintainer of the article, that's even more reason why you should be hunting down those sources instead of tagging all over the place, especially when everybody else does not agree with your tags. – FenixFeather (talk)(Contribs) 04:07, 30 April 2014 (UTC)
I have not "taken it upon yourself to be the primary maintainer of the article". This happened gradually after I got involved. It was never my intention to drive previous maintainers away. I have no official commitment to this article and am not in any way more responsible than anyone else for its maintenance. I have no intention to spend time hunting down sources which I'm confident do not exist.
If you think everybody else disagrees with my tags and you still prefer discussing behavior to discussing content, feel free to show me examples of such contributors. --Chealer (talk) 05:57, 30 April 2014 (UTC)
That's too bad then, because the current source is quite good on the topic. The burden is on you to show a reliable source that indicates OpenSSL's custom memory function was not part of the problem (hint, it was, and everybody knows this). – FenixFeather (talk)(Contribs) 20:05, 30 April 2014 (UTC)
See WP:BURDEN on burden, but again, I'm not sure I would say that custom memory management was not part of the problem (it obviously at least worsened the issue). --Chealer (talk) 20:57, 30 April 2014 (UTC)
The burden has been satisfied. You are making a counterclaim that goes against what the current source says. Thus the burden is on you. – FenixFeather (talk)(Contribs) 21:02, 30 April 2014 (UTC)
If you think the current source supports the sentence, please quote where. --Chealer (talk) 21:31, 30 April 2014 (UTC)
Chealer, I'm not going to play this game with you. I've quoted nearly the entire article to you and pointed out where it supports the content. Go back and read it. Previously, with respect to certificate revocations discussion with User:A Quest For Knowledge, you've already demonstrated that you are not technically competent (or open minded enough to listen to those who are) enough to make these sort of judgments. If you want to be "de facto maintainer" of an article, go be the de facto maintainer of article you have expertise on. Not on an article where you purposefully choose not to understand obvious facts. – FenixFeather (talk)(Contribs) 22:02, 30 April 2014 (UTC)
You may very well have quoted the entire article, but you still haven't quoted a part which actually supports the problematic sentence anyway. As for my technical competence, you'll have to explain how I would have demonstrated such a thing. I am "de facto maintainer", I don't want to be, as I said. --Chealer (talk) 22:16, 30 April 2014 (UTC)
If you don't want to be, then stop being it. Nobody forced you to edit this article. Maybe in your imagination, you are "de facto maintainer". But in real life, editors are the maintainers of this article. If you had made valuable contributions to this article, I might agree with your evaluation of yourself as de facto maintainer. But as it stands, the only thing you have done is caused disruption and destruction through your drive by tagging, your edit warring, your "clarifications", your "reworks", and your removal of access dates. Please just let people who are more knowledgeable about the topic area handle these more technical parts, because I simply cannot explain to you any further without sounding like I am talking to a five year old. Read PaleAqua's explanation below if you need to. – FenixFeather (talk)(Contribs) 22:21, 30 April 2014 (UTC)
Not wanting to be and wanting not to be are 2 different things. I'll be happy to leave all parts of this article in better hands when these arrive.
It is highly ironic that your opinion concerns my contributions to this article. When I first saw the article, it was in such a bad state and I was so sick that I couldn't perform the changes required. But I started patrolling new edits anyway, and noticed edits implementing the first changes I intended to make. Since that happened in the 24 hours which followed my arrival, I was so impressed by ourselves that I considered blogging about LSSP's virtues. I was cooled off by an edit war happening at the same time and didn't blog in the end. Of course, that was before I started reviewing and - inevitably - being perceived more and more as the new bad guy... --Chealer (talk) 23:44, 30 April 2014 (UTC)
Nobody here is a bad guy. I'm simply frustrated that you choose to drag minor things like this on and on forever, and refuse to budge an inch on any issue to anyone else. Be more considerate of others and you'll be fine. I've seen you make productive edits before. – FenixFeather (talk)(Contribs) 05:17, 1 May 2014 (UTC)
I know there's no bad guy. The problem is perception.
If your problem is refusal to budge, I'll directly remove unverifiable content next time. Then merely flag it as unappropriate after you oppose. Then let you enjoy to see me compromising. Right? --Chealer (talk) 07:19, 1 May 2014 (UTC)
In reply to your insistence that he is only talking about OpenBSD because his email address says @openbsd, no he. Is. Not. He is talking about C code in general. C is a programming language that can be compiled for multiple platforms. In fact, if you read the man page, you can see he is right in that default malloc and free have built in memory safe guards. "Crashes in malloc(), calloc(), realloc(), or free() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing the same pointer twice.". So just stop with this nonsense. – FenixFeather (talk)(Contribs) 02:52, 30 April 2014 (UTC)
He may be talking about C code in general, but still in the context of OpenBSD (and other operating with hardened C standard libraries). Thanks for the link, but would you mind quoting the part supposed to show that "default malloc and free have built in memory safe guards"? --Chealer (talk) 03:37, 30 April 2014 (UTC)
I just did. "Crashes in malloc(), calloc(), realloc(), or free() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing the same pointer twice.". So if you use the normal C memory management functions, overflowing your allocated chunk of memory will crash. This is exactly what did not happen with Heartbleed. They accessed stuff outside their allocated memory, but instead of crashing, it responded with blocks of server memory. – FenixFeather (talk)(Contribs) 03:42, 30 April 2014 (UTC)
Hum, if that's the only material there, that manpage won't help much. What we can imply from that sentence is the obvious - some overflows will cause crashes. That's a long way from implying that a simple read of unallocated memory would necessarily crash.
Not that this is uninteresting, but if I may save you some efforts, you'll notice a sentence just after the problematic one: "In addition, by using its own memory management routines OpenSSL bypassed mitigation measures in some operating systems that might have detected or neutralized the bug." (emphasis mine). Unless you take issue with that part, that's a pretty clear suggestion that only some operating systems have such mitigation measures in place... --Chealer (talk) 05:42, 30 April 2014 (UTC)
Note it's not just operating systems that have this type of checking in place, or have the ability to initialize malloc memory and cause double frees to fail ( such as Linux's mallopt and stuff like M_PERTURB ) but it's also common various memory analysis tools such as Purify or Valgrind. Using these types of tools are fairly common during development but tend not to work against bugs in code with custom memory handlers. As OpenSSL is a library any developer using it with one of those tools would have likely seen the problems if a system malloc was used. Many development IDEs have these tools. PaleAqua (talk) 07:29, 30 April 2014 (UTC)
Although the deraadt reference does mention that, we have not covered it in the article yet. This could be covered in the analysis section, although it may be getting a little far for my taste. --Chealer (talk) 16:04, 30 April 2014 (UTC)
This is not about your "taste", this is about reality, that which is true whether you believe it or not. You need to stop hanging onto your delusional protests and start listening to other editors, instead of stubbornly clinging to your edits. – FenixFeather (talk)(Contribs) 16:12, 30 April 2014 (UTC)
The level of detail we want from our articles is relative. We can't say an article is "8/10" in completeness, and even if we could, some would promote a higher level than others. That's why I'm not saying the fact PaleAqua highlighted should not be covered. Let's say I'd recommend the short version if someone wants to write something. --Chealer (talk) 17:08, 30 April 2014 (UTC)
Unless I'm understanding them wrong, PaleAqua is not talking about facts we should include, but explaining to you how memory allocation works. Please just listen to others. You are in a one person minority that believes the custom memory function in OpenSSL was not part of the problem. It was. Please stop denying reality. – FenixFeather (talk)(Contribs) 20:09, 30 April 2014 (UTC)
Not really an explanation of how memory allocation works, but sorry if I got PaleAqua's intent wrong. I'm not sure I would say that custom memory function in OpenSSL was not part of the problem. Obviously, they at least worsened the issue. --Chealer (talk) 20:47, 30 April 2014 (UTC)
Then why is this such a big issue? That is exactly what the source and the content say. Can you just concede now, or do you have to keep beating the dead horse? – FenixFeather (talk)(Contribs) 20:59, 30 April 2014 (UTC)
"Such a big issue"? I merely requested to source the problematic sentence. What could I concede? --Chealer (talk) 21:31, 30 April 2014 (UTC)
Not exactly, what I was explaining was not how memory allocations work, but how the custom allocators compounded the issue on more than just OpenBSD or just some OSes. The custom allocators would prevent memory bugs from being visible during typical software development cycles. The bug would have still existed with or without the custom memory handlers. It's just likely that it would have been caught earlier and would have been more a denial of service attack instead of a security breach as the attempts to read outside memory would have triggered page faults on some servers. All of this seems pretty common sense to me ( but then again I am a software tools developer. ) PaleAqua (talk) 21:26, 30 April 2014 (UTC)
It is common sense to anyone who has a modicum of technical knowledge or has read the cited source, or even the Wikipedia article. Chealer, unfortunately, has repeatedly demonstrated that he will not listen to anyone else, no matter how common sense it is. – FenixFeather (talk)(Contribs) 22:00, 30 April 2014 (UTC)
Note that I never refused to participate in Dispute Resolution. --Chealer (talk) 03:10, 30 April 2014 (UTC)

@Chealer: You need to stop making edits without reading the sources. You just edited the LastPass entry to make it seem as if LastPass's password transmissions were vulnerable: "its usage with vulnerable websites may have compromised the passwords transmitted". They were not. LastPass passwords are encrypted before even being transmitted in the first place. LastPass told its users to change their passwords because OTHER servers could have been compromised, not because LastPass is vulnerable. Stop "clarifying" stuff. You have no idea what you're doing. – FenixFeather (talk)(Contribs) 16:09, 30 April 2014 (UTC)

LastPass's password transmissions were vulnerable in a sense, i.e. when using it with vulnerable websites, just like the transmissions of Firefox or any browser. LastPass passwords are not necessarily encrypted, but yes, they are encrypted in the cases concerning us (when using with TLS websites). This doesn't mean, of course, that they can't be decrypted when a cryptographic key is comprised. As for

LastPass told its users to change their passwords because OTHER servers could have been compromised, not because LastPass is vulnerable.

...that's why we explain that "LastPass itself is not vulnerable in practice". I'm sorry you don't see the new version as clearer. To be honest, the issue's complexity is part of why the first solution I chose was to remove our coverage entirely (I only went for a fix after someone re-added the item). --Chealer (talk) 17:08, 30 April 2014 (UTC)
Removing something because you don't understand it is not the right approach to the problem. Your wording made it more confusing when it was perfectly fine before. – FenixFeather (talk)(Contribs) 17:18, 30 April 2014 (UTC)
The issue's complexity doesn't simply make it harder to understand for us, it makes it harder for the reader (or, it makes it harder for us to explain it to the reader). I'm sorry you find the wording more confusing. If you find some part could cause confusion, feel free to explain how. --Chealer (talk) 19:24, 30 April 2014 (UTC)
I've already explained, but I have no interest in fighting more with you. I'm sure nobody else is as interested as you are in LastPass anyway. – FenixFeather (talk)(Contribs) 20:01, 30 April 2014 (UTC)

Footnotes and accessdates[edit]

Also, why are you removing access dates from citations? They're a valuable part of references. I just don't understand why you edit so disruptively like this. – FenixFeather (talk)(Contribs) 16:14, 30 April 2014 (UTC)

I'm only removing those which already have a date to size down the article a little. Access dates are unlikely to be used when we already have a publication date (see Template:Cite_web/doc#URL). In the unlikely event that one is needed to help verifying a source, they can be digged from history quite reliably. --Chealer (talk) 17:15, 30 April 2014 (UTC)
They are NOT REQUIRED, not that they should be removed. These pages are news sources that may change in the future, and not static. There is no need to remove access dates. I don't want to have to hunt down an edit in the edit history just to figure out when an article was accessed. Please stop disruptively editing. – FenixFeather (talk)(Contribs) 17:18, 30 April 2014 (UTC)
No. Wikitech-l is a mailing list. The reference to it is a mail, which will not change in the future. It is perfectly static. There is of course no need to remove superfluous access dates, just like there is no need to add access dates. Many things we do are not necessary neither. --Chealer (talk) 19:30, 30 April 2014 (UTC)
Let me remind you that one of the sources from which you removed the access date was a news article I cited to put a temporary stop to your edit warring. There is no excuse for removing access dates, especially in that scenario. Access dates don't hurt, and they are often a required standard for citing web materials in many citation style manuals. – FenixFeather (talk)(Contribs) 20:01, 30 April 2014 (UTC)
There's of course nothing wrong with access dates in general, but this is a wiki. The access date is the date of the edit which introduced the reference (with exceptions), so displaying it is quite redundant when we already display the publication date. There's no excuse needed to remove them in these cases. You can remind me that I removed an access date from a news article, and I can remind you that news articles rarely change. It's as unlikely that the article is changed as it's unlikely that someone ever needs to find the access date anyway.
If it wasn't for the fact that they enlarge the article further, I'd agree access dates don't hurt significantly. It would be nice to be able to hide those unlikely to be used. --Chealer (talk) 20:41, 30 April 2014 (UTC)
Are you kidding me? Web pages change all the time, which is why access dates are so important. News articles often change their text or add corrections. I can't remember how many times I've come across a dead link in a ref, and have had to find a webarchive link for it. Having the access date conveniently there is crucial to locating a good date for the webarchive wayback machine, especially to verify the information. Stop being stubborn and accept that sometimes you can make mistakes. – FenixFeather (talk)(Contribs) 20:54, 30 April 2014 (UTC)
A dead link simply prevents you from accessing the last version. If you want the last version, you just take that from the wayback machine. --Chealer (talk) 21:00, 30 April 2014 (UTC)
Jesus. I don't know how you can be so ignorant on this sort of thing, but for verifiability, it is important that we use the version the original author used. That's why access date is so critical for web sources, because of how unstable they are. "Access dates bloat the article" is such an absurd argument. Just listen to yourself. Think before you speak. – FenixFeather (talk)(Contribs) 21:04, 30 April 2014 (UTC)
The current version is equally verifiable in the vast majority of cases, in particular when we have a publication date. I can live with the idea that I may have caused someone to lose a few minutes digging the history, as they'd probably have done anyway to see who added the reference. But thanks for your opinion. I wasn't aware that some people were that attached to all access dates. --Chealer (talk) 21:25, 30 April 2014 (UTC)
There is zero harm in access dates. There is potential harm in removing them. End. Of. Story. – FenixFeather (talk)(Contribs) 21:30, 30 April 2014 (UTC)
Any content is "harmful", in the sense that it has a cost. The perfect article could be entirely read in 0 seconds. Unfortunately, that article would be of little use. We are in a world of trade-offs, even though that can be difficult to accept. We also have to accept and deal with the conflicts caused by diverging opinions on where to draw the lines. --Chealer (talk) 21:39, 30 April 2014 (UTC)
@Chealer: You shouldn't be removing access dates. If you do, you need to take the time to re-add them. A Quest For Knowledge (talk) 21:40, 30 April 2014 (UTC)
The time it would take to re-add would be out of proportions and I don't intend to do that. However, I did assume that removing superfluous dates was uncontroversial, and am sorry for that. Thanks for sharing your opinion. --Chealer (talk) 21:50, 30 April 2014 (UTC)
Chealer, this comment is demonstrative of your attitude towards editing on Wikipedia. You are not interested toward editing constructively. You are not interested in listening to others. You tag obvious facts, you "clarify" things in a way to make them more confusing, you remove, of all things, access dates. Go out, do research, find something valuable, and add to the article, instead of power tripping as the pretend "de facto maintainer" of the article. You say you have no time for re-adding access dates, but apparently other people have time for digging through edit history to find access dates? Wait, you just said it wouldn't take much time. Stop being self centered. Get off your butt and go do real work, stop sitting around and disrupting others' work when you're not willing to put in the effort yourself. – FenixFeather (talk)(Contribs) 21:57, 30 April 2014 (UTC)
It's one thing to dig one access date. It's a different thing to dig up to 149 access dates, many of which won't come up, without any help from edit summaries, unfortunately. --Chealer (talk) 22:06, 30 April 2014 (UTC)
We never said you had to dig up 149 access dates, just that you should restore the ones that you have removed, if you have removed any. If you have removed 149 access dates, then yes, you need to go dig them up and restore them. It is not other people's responsibility to compensate for your wanton destruction. – FenixFeather (talk)(Contribs) 22:10, 30 April 2014 (UTC)
Fair enough, but since I made even more edits on this article, that would take quite a while too. --Chealer (talk) 22:26, 30 April 2014 (UTC)
That's fine, as long as you track down every single one you deleted. There is no deadline, so take your time with restoring them. It might give you something to do other than tagging random stuff. – FenixFeather (talk)(Contribs) 22:28, 30 April 2014 (UTC)
Unfortunately, I don't think I'm immortal, so there is a deadline. Thanks for the suggestion, but rest assured I don't need more things to do. --Chealer (talk) 23:23, 30 April 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You removed that many access dates that it would take an entire lifetime to restore them all? My god, I don't know whether to be impressed or horrified. If you did cause such massive disruption, I suggest you do not continue to do so in the future. We can't force you to fix your past mistakes, but keep in mind that every mistake of yours you do not fix, you are imposing on other people's time. Other people are mortal too. Don't be selfish. – FenixFeather (talk)(Contribs) 23:28, 30 April 2014 (UTC)

No. I simply happen to have other things to do in my life than to restore access dates in references which already have a publication date. --Chealer (talk) 23:51, 30 April 2014 (UTC)

Oh and if you don't need more things to do, if you would kindly resign your position as "de facto maintainer" and un"adopt" this article, that would be great. Alternatively, you could just decide to be cooperative and not drive by tag, delete sections for being too confusing to you, remove access dates, "clarify" things without looking at sources, etc. Put some effort into it. – FenixFeather (talk)(Contribs) 23:31, 30 April 2014 (UTC)

One can't resign from a de facto position. What I can do is to welcome other people to make my involvement here unneeded. And I am hereby doing that with great joy. --Chealer (talk) 23:51, 30 April 2014 (UTC)
Any content is "harmful", in the sense that it has a cost. The perfect article could be entirely read in 0 seconds. Unfortunately, that article would be of little use. We are in a world of trade-offs, even though that can be difficult to accept. We also have to accept and deal with the conflicts caused by diverging opinions on where to draw the lines. --Chealer (talk) 21:39, 30 April 2014 (UTC)
I'd just like to note, there is no reason for one editor to be overriding the entire article. Content decisions are based on WP:CONSENSUS, whether we like it or not. I personally feel there is a value in the accessdate as it tells us when the article was last 'touched' by a user, and is convenient to the formation and people looking at the sources. I opt to include. Tutelary (talk) 21:43, 30 April 2014 (UTC)

Wikipedia guidelines specifically say accessdates should be included. See the 2nd paragraph of Wikipedia:CITE#Links and ID numbers. PaleAqua (talk) 22:13, 30 April 2014 (UTC)

What we're supposed to be discussing here is only references which have a publication date set. --Chealer (talk) 22:26, 30 April 2014 (UTC)

Editing Wikipedia is a collaborative effort[edit]

@Chealer: Editing Wikipedia is a collaborative effort that requires editors work in an atmosphere of camaraderie and mutual respect. If you or anyone thinks that their edits edits are more important than other editors', then they are mistaken. Please take the time to understand the concerns of others who have just as much right to edit this article as you do. A Quest For Knowledge (talk) 22:17, 30 April 2014 (UTC)

Does OpenSSL's custom memory management increase the likelihood of sensitive leaks?[edit]

In this diff [18] I added the sentences "As a result, the oversized memory buffer returned to the requestor was likely to contain data from memory blocks that had been previously requested and freed by SSL. Such memory blocks may contain sensitive data sent by users or even the private keys used by OpenSSL." User:Chealer and I have been having a polite chat about this on my talk page, and I think the discussion needs to be brought here. I based the sentences on my reading of the references cited above, but at Chealer's prodding I took a look at the OpenSSL source code (e.g. [19] Line 599 ff] and the situation is a bit more complicated. It seems that OpenSSL maintains its own lists of freed memory chunks. When it needs memory it first tries to get a previously freed chunk off the free_list. If it can't, it requests memory in standardized chunks via the operating system's malloc. When OpenSSL is done with a memory chunk, it tries to place it back on the free_list, which has a count of how many free blocks are on it. There is a maximum value for the number of blocks on the free_list and if the fee_list is full, the memory chunk is instead returned by the OS free() library function. I think what I wrote is still true in this model, as many chunks will be allocated quickly at startup and will likely be near each other, but this is clearly OR on my part and tentative at that (OpenSSL is notoriously hard to read). I notice that the sentences in question were recently removed. I will continue to look for a reliable source for them, and welcome help in the search, but until a reliable source is found, I suggest they should not be restored.--agr (talk) 21:41, 7 May 2014 (UTC)

PaleAqua made an edit regarding free lists a couple weeks ago. I think they came to some conclusion regarding them. – FenixFeather (talk)(Contribs) 00:30, 8 May 2014 (UTC)
I looked at the same code and originally reached a similar conclusion, but it seems that the heartbeat code using the OPENSSL_malloc wrappers directly instead of going through the free list first. So while the first list might make OpenSSL more vulernable in general I no longer think it applies to the heartbleed issue. Another thing to note is that there are actually several free lists ( two per context, one for reading and one for writing ) and the size of the blocks on the free list are fixed as soon as atleast one block is added, so it doesn't seem to have the all same flaws that a general free-list implementation would. See also my talk where Chealer questioned me on it which lead me to revert my changes. I also agree that a lot of this is OR. What it seems like to me is that OpenSSL has been critized not just for issues related to heartbleed, but other possible issues not involved in the heartbleed issue. We need to be careful to be clear on the distinction and not imply that all OpenSSL concerns are part of heartbleed. PaleAqua (talk) 01:21, 8 May 2014 (UTC)
I haven't found any support for de Raadt's assertions about OpenSSL memory management playing a role, so I took out the remaining sentence about memory management from the Behavior section. We still have de Raadt's comments in the Root causes, possible lessons, and reactions section, but I'm wondering if that should go as well, or be balanced in some way.--agr (talk) 20:14, 9 May 2014 (UTC)
I'm not sure what balancing could be done, but Wheeler's How to Prevent the next Heartbleed is very clear on the memory allocator's importance. I'd strongly oppose to complete removal. --Chealer (talk) 22:06, 9 May 2014 (UTC)
Wheeler's main point is that a properly instrumented memory allocator can help prevent bugs like Heartbleed. But he also repeats the claim that Heartbleed's use of a free list contributed to Heartbleed. Apparently it did not, and I don't think we should do any more to perpetuate this story. Balance would be to find a source that says it isn't true. Absent that, we could explain Wheeler's advice on using allocators, while not repeating the apparently untrue claim.--agr (talk) 03:01, 11 May 2014 (UTC)

The article misses some important big picture aspects[edit]

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 suspect the difficulty will be to find reliable information. Claw of Slime has kindly provided one such statistic.--Chealer (talk) 21:58, 9 May 2014 (UTC)

Apple's "recommendation to embed OpenSSL"[edit]

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:

  1. FileMaker using OpenSSL
  2. FileMaker linking OpenSSL statically
  3. The OpenSSL version embedded in some FileMaker versions being vulnerable

At most, Apple's recommendation could have been a factor in 2. --Chealer (talk) 19:55, 10 May 2014 (UTC)

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)

Undid massive, undiscussed changes.[edit]

I'm sorry I had to do this, but I've undone massive undiscussed changes[https://en.wikipedia.org/w/index.php?title=Heartbleed&diff=608181479&oldid=608069774 which unfortunately, did not improve the article. Chealer, please begin discussion on the talk page before making such sweeping undiscussed changes. Thanks. A Quest For Knowledge (talk) 09:36, 12 May 2014 (UTC)

Unfortunately, one of the inaccurate changes has been restored to the article (without engaging discussion) so again, I've made the article more accurate. Again, the Heartbleed bug has not be resolved. Thousands of web servers and millions of Android phones remain vulnerable. A Quest For Knowledge (talk) 23:53, 22 May 2014 (UTC)
Which inaccurate change? --Chealer (talk) 03:06, 25 May 2014 (UTC)
As I just said, "the Heartbleed bug has not be resolved. Thousands of web servers and millions of Android phones remain vulnerable." A Quest For Knowledge (talk) 10:45, 27 May 2014 (UTC)
There is some truth in that, but that doesn't say which inaccurate change you were referring to. --Chealer (talk) 14:48, 28 May 2014 (UTC)
Are you serious? I've told you repeatedly what the inaccurate change was: the part that says that issue has been resolved. Let me repeat myself in no uncertain terms: It. Has. Not. Been. Resolved. Please stop changing the article to say that the issue has been resolved when it hasn't. As eWeek reported, Heartbleed will be a problem for months, if not years to come.[20] In any case, I've reverted the misleading information.[21]] Please stop edit warring to include this change. Instead, please seek consensus on the talk page before doing this again. A Quest For Knowledge (talk) 23:36, 10 June 2014 (UTC)
I am extremely serious. A part is not a change. --Chealer (talk) 16:40, 11 June 2014 (UTC)
Huh? What does that even mean? Changing part of an article is not changing an article? You're not making any sense. A Quest For Knowledge (talk) 05:07, 12 June 2014 (UTC)
Changing part of an article implies changing an article. What I meant is that you're not making sense when you claim that a part of an article was the change you consider inaccurate. A part of an article does not constitute a change. --Chealer (talk) 17:21, 15 June 2014 (UTC)
Yeah, the Heartbleed issue by far isn't resolved. OpenSSL, as a library, was patched, but there are still millions of various devices that are left with vulnerable versions of OpenSSL. Who knows when those will be patched, and probably a large portion of them will remain vulnerable forever – just think of older Android devices receiving no more any software updates from their manufacturers. — Dsimic (talk | contribs) 03:56, 15 June 2014 (UTC)
I agree. Given the technical nature of this topic, I think it would be best if any changes that significantly alter the meaning of the article should be proposed and discussed on the talk page first to avoid unnecessary reverting. – FenixFeather (talk)(Contribs) 06:44, 24 May 2014 (UTC)
Regrettably, Chealer has once again edit-warred his preferred version into this article against this talk page discussion.[22] Chealer, so far, nobody agrees with you and everyone who's expressed an opinion has disagreed with you. Please stop trying to force your changes thru edit-warring. Instead, seek consensus first. If you fail to gain consensus, then you need to accept that nobody agrees with you and you need to let it go. A Quest For Knowledge (talk) 01:44, 20 July 2014 (UTC)
Ahem. If that's what you call massive changes, you must be using a massively different sense of "massive" then those I'm used to, which I encourage you to teach to our article first. --Chealer (talk) 20:30, 9 August 2014 (UTC)
So far, nobody is agreeing with you. If you continue to edit-war against talk page consensus, you risk being sanctioned. Please stop. A Quest For Knowledge (talk) 23:39, 21 August 2014 (UTC)

Infographic in Impact[edit]

In the impact section I feel like File:StickyPassword Heartbleed Infographic.png would be a good display of community effort to educate and help users understand what Heartbleed is about. However the nature of it been very vertical makes the thumbnail pretty ugly and an eyesore. What can we do about that? —f3ndot (TALK) (EMAIL) (PGP) 20:39, 2 June 2014 (UTC)

I personally wouldn't support that infographic in the article. It's certainly useful and explains the situation, but in addition to being hard to place into the article, it doesn't add anything more than what is already said in the prose, and is ultimately promotional of password managers (seeing that the infographic is made by StickyPassword, and the infographic suggests the use of StickyPassword and/or other password managers at the bottom). ~SuperHamster Talk Contribs 22:12, 2 June 2014 (UTC)
I would strongly disagree with inclusion of that infographic, even if its form was optimal. I previously removed "coverage" of that infographic, mostly for other reasons. But I agree with SuperHamster - if there's any new information there, it should be integrated in text, and that infographic is mostly promotional. It offers unnecessary advice (each of the 4 advices). The average person wants to change a password only if the website advises them to do so. You might want to stop using a service if its administrators don't react properly to Heartbleed and other threats, but that's not a call our average audience is in position to make. If one ends up changing many passwords, that might be a good occasion to start using a password manager, but Heartbleed isn't a big reason to do that. I have countless accounts and didn't change a single one. I don't consider myself that daring. Besides, at this point nobody is looking for that kind of advice anyway. I even consider the infographic misleading. --Chealer (talk) 03:33, 3 June 2014 (UTC)