Jump to content

Talk:Heartbleed/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

ITN/DYK

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

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

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

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 and 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

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)

  • 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

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

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?

@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

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

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

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)

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"

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)

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

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)

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

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

  • 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

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"

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

Git vulnerability

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)

earlier bug

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)

reverse heartbleed

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)