Diskussion:Heartbleed

Weiterleitung auf TLS fehlt, da eine Funktion von TLS

Zitierter Hinweis aus [Diskussion:Transport_Layer_Security#Kapitel_zu_Heartbleed-Erweiterung_fehlt_.28f.C3.BCr_Korrektur_der_.22Weiterleitung_Heartbleed_auf_OpenSSL.22.29]

Aktuell gibt es sehr viel Presse zum Bug in OpenSSL durch die TLS-Erweiterung "Heartbleed". Zur Zeit gibt es irrtümlich eine Weiterleitung von Heartbleed auf OpenSSL. Das ist fachlich falsch, weil Heartbleed ist eine Technik von TLS und muss dort behandelt werden. Ich zitiere kurz folgenden Satz aus Golem: „Die Sicherheitslücke steckt im Code für die sogenannte Heartbeat-Erweiterung von TLS. Sie wurde vor zwei Jahren in OpenSSL 1.0.1 eingeführt und soll langlebige, TLS-gesicherte Verbindungen erleichtern. Genutzt wird sie nur selten, aber in der Standardeinstellung von aktuellen OpenSSL-Versionen ist die Erweiterung aktiv.“ (Quelle http://www.golem.de/news/sicherheitsluecke-keys-auslesen-mit-openssl-1404- 105685.html)

Es kann nicht Aufgabe vom Artikel OpenSSL sein zu beschreiben für was Heartbleed dient und wo es angewendet werden soll in der Praxis. TLS ist nicht mein Spezialgebiet und daher habe ich keine zugehörige Sammlung von passenden Einzelnachweise für eine qualifizierte Ergänzung eines neuen Unterkapitels. Ich bitte die üblichen Artikelschreiber von TLS hier aktiv zu werden. --ocrho (Diskussion) 10:58, 9. Apr. 2014 (CEST)

--ocrho (Diskussion) 11:07, 9. Apr. 2014 (CEST)

ich habe auf Diskussion:Transport Layer Security geantwortet, bitte dort weiterdiskutieren. --Mario d 11:11, 9. Apr. 2014 (CEST)

kritik am OpenSSL-team

uebertrag von D:OpenSSL --Mario d 13:04, 13. Apr. 2014 (CEST)

bitte nicht irgendwelche kritik unreflektiert wiedergeben. auch hier gilt WP:NPOV. wenn, dann sind alle seiten darzustellen, das wuerde den rahmen aber sprengen. --Mario d 10:24, 13. Apr. 2014 (CEST)

Theo de Raadt ist nicht irgendwelche Kritik und sein inhaltlicher Hinweis ist substantiell. --HV (Diskussion) 10:26, 13. Apr. 2014 (CEST)

trotzdem ist es nicht neutral, die kritik einfach zu uebernehmen. er kritisiert eine bewusst getroffene entwurfsentscheidung, fuer die es auch gruende gibt. --Mario d 10:35, 13. Apr. 2014 (CEST)

wenn Du darüber belegbare Informationen hast, dann trage diese bitte in den Artikel ein, um einen neutralen Stadtpunkt herzustellen. Das würde ich sehr begrüßen. Fest steht jedoch, dass diese Entwurfsentscheidung sich aktuell als wohl größte Fehlentscheidung des OpenSSL-Teams herausstellt, da die malloc-Tools geholfen hätten, den Fehler zu vermeiden, auch wenn sie die Entwicklung auf den Testservern etwas verlangsamen. Soviel Zeit muss sein, wenn die Sicherheit von Millionen von Usern daran hängt. --HV (Diskussion) 10:54, 13. Apr. 2014 (CEST)

nein, es laeuft nicht so, dass du POV einbaust und es dann an anderen ist, das ganze neutral zu gestalten. dass etwas die "wohl größte Fehlentscheidung des OpenSSL-Teams" ist, ist deine private meinung und steht keineswegs fest. i moment greifst du aus einer laufenden diskussion einen standpunkt heraus und bringst ihn unkommentiert in den artikel. das geht nicht. --Mario d 13:10, 13. Apr. 2014 (CEST)

Natürlich geht das. Es handelt sich um den belegten Stadtpunkt einer für diese Thematik relevanten Persönlichkeit. Andere Standpunkte sind mir nicht bekannt. Falls Du sie kennst und belegen kannst, dann bitte ich Dich, diese auch im Sinne der Arbeitsteilung entsprechend einzubringen. Wir arbeiten hier mit Belegen, und nicht mit Vermutungen und Annahmen. Also halte Dich bitte daran, und lösche nicht einfach belegte Aussagen, bloß weil Du vermutest, dass jemand auch anderer Meinung sein könnte, ohne dies deinerseits belegen zu können. --HV (Diskussion) 14:13, 13. Apr. 2014 (CEST)

Es ist letztlich egal, um welche Behauptung es konkret geht: Nur eine Seite der Medaille darzustellen, ist nicht WP:NPOV. --88.130.72.218 19:35, 13. Apr. 2014 (CEST)

Ich habe ja gar nichts dagegen, dass die Gegenseite dargestellt wird, aber dazu muss ich 1. wissen und nicht nur mutmaßen, dass es in der Tat eine Gegenseite gibt, und wer das ist, und ob es sich um relevante Debattenteilnehmer handelt, 2. muss ich die inhaltliche Position der Gegenseite kennen und formulieren können und 3. benötige ich dann noch Belege. Nichts davon habe ich, also stellt sich für mich die Situation wikipediaseits bis auf Weiteres so dar, dass es auch keine Gegenseite gibt, selbst wenn ich mir das denken könnte. Wenn Mario hier besser informiert ist, dann soll er die Gegenseite gerne wikipediakonform darstellen. Ich würde das begrüßen. Das ist aber noch lange kein Grund, diejenigen relevanten Verlautbarungen, die immerhin jetzt schon belegbar sind, in Frage zu stellen. --HV (Diskussion) 20:59, 13. Apr. 2014 (CEST)

Auch ich hab bei deinen Äußerungen manchmal das Gefühl, du legst es absichtlich drauf an, tendenziöse Artikel zu schreiben. Die relevanteste Gegenseite sind bei einer Software, die durch Dritte kritisiert wird, naturgemäß die Entwickler, denn ohne deren Willen hätte es die kritisierte Änderung so gar nicht gegeben. Und zu behaupten, das OpenSSL-Team sei bei einer Änderung des OpenSSL-Quellcodes nicht relevant, ist ja schon ein Witz! Hintergründe, Überlegungen, Patches udglm. findet du im OpenSSL-Bugtracker. Muss ich dir die Issue, in der die Sicherheitslücke eingeführt wurde, raussuchen, oder schaffst du das selber? --88.130.72.218 22:23, 13. Apr. 2014 (CEST)

Nein, es geht hier nicht um Tendenz, sondern um objektiv vorgetragene Kritik. Weder der Öffentlichkeit noch dem openSSL-Team ist jetzt damit gedient, unbequeme Kritik zurückzuhalten oder abzuwehren. Der Bug ist in den Code hineingekommen und dafür gibt es konkrete Umstände, auch wenn sie einem nicht gefallen. Mit einem Shit-happens und Weiter-so ist es hier nicht getan. Allen Beteiligten sollte wohl klar sein, dass hier nun alles auf den Prüfstand muss: angefangen von den beteiligten Personen, über die verwendeten Technologien, bis hin zu den Abläufen und Verfahren (unabhängig davon, ob es ein Social Engineering durch Dritte gegeben hat oder nicht, muss natürlich auch hier ein Verfahren gefunden werden, dass das wirksam ausschließt, denn es hätte ja eines gewesen sein können, und könnte übrigens auch Nachahmer finden!). Für die Beteiligten ist das alles andere als erfreulich und viel Stress und Arbeit, aber das ist nun mal so. Für die betroffenen Anwender ist es das übrigens auch alles andere als erfreulich.

Die Aufgabe der Wikipedia dabei ist es, den Sachverhalt der Öffentlichkeit enzyklopädisch korrekt und vollständig darzustellen (zudem ist sie - d.h. wir als Community - ja auch entscheidend davon mitbetroffen). Dabei sind keine unangenehmen Punkte in der Darstellung auszulassen, auch wenn einem das openSSL-Team oder der verantwortliche Programmierer irgendwie nahestehen oder menschlich leid tun. Wenn eine Brücke wegen des Fehlers eines Statikers zusammenbricht, dann tut mir der arme Statiker oder seine Firma auch nicht leid, sondern ich benenne den Pfusch. Als Softwareentwickler kann man immerhin noch heilfroh sein, dass man wegen eines Fehlers nur seinen Job verliert, und nicht in den Bau einfährt (was ich übrigens persönlich im vorliegenden Falle für durchaus angemessen hielte, aber das tut hier nichts zur Sache).

Ins Gefängnis gehen für einen Programmierfehlers? Na, das wird der Open-Source-Community bestimmt guttun, bei solchen drakonischen Strafen finden sich bestimmt massenhaft Leute, die dann umso motivierter an OpenSSL weiterschreiben. Gehts noch? Warum sollte ich überhaupt noch an Open-Source-Projekten schreiben, wenn ich für Fehler sogar ins Gefängnis müsste? Man sollte, bevor man solche unqualifizierten Kommentare schreibt, auch mal darüber nachdenken, dass dieses nur aus Freiwilligen besteht. Wenn der Fehler nun in einem großen Unternehmen passiert dann steht wenigstens das Unternehmen als ganzes dafür gerade, da wird auch nicht bekanntgegeben welcher Angestellte das verbockt hat. Als Open-Source-Entwickler in OpenSSL ist man in diesem fall namentlich bekannt und muss eine Hexenjagd über sich ergehen lassen die jeder Beschreibung spottet. und dann auch noch Gefängnis? Eine solche Gefängnisstrafe setzt in unserem Rechtssystem nunmal auch Vorsatz voraus, solange der nicht erwiesen ist ist diese Forderung niveauloser Populismus. --129.217.151.246 15:00, 14. Apr. 2014 (CEST)

Ich habe Dir hierzu auf meiner Disk-Page geantwortet, da das ja Off-Topic ist und nicht in den Artikel hineingehört. Mein Statement sollte nur verdeutlichen, dass meine persönliche Meinung hier völlig irrelevant ist, und ich mir dessen auch bewusst bin. Ebenso sollte es verdeutlichen, dass auch die Inschutznahme des Programmierers und des OpenSSL-Teams ein POV, bzw. eine persönliche Meinung ist, die im Artikel nichts verloren hat. Darzustellen sind Tatsachen, auch dann, wenn sie einem moralisch nicht in den Kram passen. --HV (Diskussion) 08:17, 15. Apr. 2014 (CEST)

Wenn Du oder jemand anderes die Positionen von openSSL kennt und bewerten kann, dann bitte ich Euch, das auch selbst in den Artikel einzupflegen. Ich kenne sie wie gesagt nicht. --HV (Diskussion) 23:17, 13. Apr. 2014 (CEST)

Dissertation

Obwohl der Programmierer in seiner Dissertation auf die Möglichkeit hinweist, dass Payload-Informationen durch Lengthguessing ausgenutzt werden könnten,[10] hat er mit seiner Änderung zuvor selbst eine ebensolche Sichrheitslücke eingebaut.

Hier wird ein Zusammenhang konstruiert, der nicht existiert. Der Autor spricht auf Seite 67 davon, dass man einen Known-Plaintext-Angriff durchführen könnte, wenn man den genauen Inhalt des Payload kennt, und man deshalb mindestens 16 zufällig gewählte Padding-Bytes mitsenden soll, um Known-Plaintext-Angriffe zu erschweren. Mit der Länge des Payloads und dem Heartbleed-Bug hat das nichts zu tun. Den Begriff "Lengthguessing" gibt es nicht. --Matthäus Wander 17:02, 13. Apr. 2014 (CEST)

Danke für die Information. Könntest Du uns bei dieser Gelegenheit mal genau erklären, wodurch sich eine en:Known-Plaintext Attack von der bei Heartbleedt gegebenen Sicherheitslücke unterscheidet? Müssen wir nicht trotzdem davon ausgehen, dass sich der Programmierer demnach als Sicherheitsexperte umfassend mit der Thematik der Gefahr der Ausbeutung von Payloads (wenn auch auf anderem Wege) auseinandergesetzt hat? Wenn ja, wie kann es sein, dass er diese Überlegungen bei der konkreten Umsetzung seines Vorhabens auf einmal wieder vergisst und aus Nachlässigkeit eine Sicherheitslücke detailliert auf einem Gebiet produziert, mit dem er sich ausgiebig beschäftigt hat? Entweder er tut es absichtlich oder er ist ein miserabler Sicherheitsexperte. Letztere Alternative zu entscheiden wird wohl niemals gelingen. Es ist aber für Wikipedia auch nicht notwendig, sich dafür zu interessieren, was die Artikelautoren, die Leser oder die allgemeine Öffentlichkeit glauben. Wir beschränken uns auf die Darstellung der belegbaren Fakten.

Ich suche daher nun nach einer wikipediatauglichen Formulierung, die am Ende den objektiven Sachverhalt darstellt, ohne zu einer Bewertung der subjektiven Motive zu kommen oder diese zu implizieren. Aus Gründen der historichen Darstellung der Begleitumstände der Entstehung dieses Bugs halte ich das für unbedingt notwendig. Ich halte es dabei mit Bruce Schneier (Amateurs hack systems, professionals hack people.), der davon ausgeht dass gute Hacks in der Regel das Ergebnis von Social Engineering sind und nicht von Technik. Deshalb gehört die Darstellung dieser Belgleitumstände zur Darstellung des Bugs untrennbar hinzu, wenn wir schonmal das Glück haben, dass sie uns zufällig so genau bekannt sind, wei hier. --HV (Diskussion) 17:41, 13. Apr. 2014 (CEST)

Bei einem Known-Plaintext-Angriff kennt der Angreifer den Klartext oder Teile davon, und kann mit diesem Wissen den übrigen Geheimtext entschlüsseln oder den Schlüssel wiederherstellen. Diese Klasse von Angriffen kann allgemein auf ein Verschlüsselungsverfahren oder eine bestimmte Implementierung eines Verschlüsselungsverfahrens angewendet werden, je nach Anfälligkeit. Ein Beispiel ist die Turing-Bombe, mit der ein Known-Plaintext-Angriff auf die Enigma durchgeführt wurde. Durch die 16 Bytes Padding sollen Known-Plaintext-Angriffe auf das Verschlüsselungsverfahren erschwert werden. Der Heartbleed-Bug ist dagegen ein Programmierfehler in der OpenSSL-Implementierung (kein Schwäche in TLS oder in der Heartbeat-Spezifikation) aufgrund einer nicht durchgeführten Eingabevalidierung, etwa vergleichbar mit einer SQL Injection. Der Angreifer braucht keinen Klartext zu kennen und entschlüsselt keinen Geheimtext, sondern sendet ein präpariertes Datenpaket, das fehlerhaft verarbeitet wird. --Matthäus Wander 20:52, 14. Apr. 2014 (CEST)

Lieber Matthäus, vielen Dank für Deine Erklärung, die mir sehr beim Verständnis der Textstelle in der Dissertation weitergeholfen hat. Würdest Du mir dahingehend recht geben, dass der Programmierer aber somit dennoch immerhin mit der Problemstelle, an der der Bug letztendlich entstanden ist, vertraut war, und dass es sich demzufolge nicht um einen Fehler handelte, der daraus entstand, dass der Programmierer überhaupt nicht erwarten konnte, dass an dieser Stelle überhaupt Informationen abgegriffen werden können? Sein Code-Release war also nicht einfach unvorhersehbares Shit happens, sondern schon ein ziemlich unbedachter Schritt. Ein Sicherheitsexperte hätte den Fehler bei ausreichender Qualifikation und Erfahrung eigentlich sofort sehen müssen (s. Dein Hinweis auf SQL-Injection: das weiss und erkennt ja jeder, der sich nur am Rande mal mit Security auseinandergesetzt hat). --HV (Diskussion) 08:31, 15. Apr. 2014 (CEST)

Ich hab mir das grad überlegt nachdem ich gestern auf der S.67 gelesen habe und komme genau zu dem Ergebnis wie Matthäus: Es sind einfach 2 deutlich unterschiedliche paar Stiefel. Man kann lediglich folgern dass Seggelmann Sicherheitsbewusstsein hatte. Man kann daraus nicht herleiten, dass er sich des Fehlers des unberechtigten Speichereinblicks bewusst gewesen sein muss. Dazu bräuchte es andere Beweise bzw. Indizien. Es bleibt also weiter möglich dass es ein 'unbedachter Schritt' war. Ein Shit happens ist es so oder so, nämlich zumindest für alle Betroffenen. --Itu (Diskussion) 16:25, 15. Apr. 2014 (CEST)

Du hast völlig recht, wenn man das Ganze nur unter dem Blickwinkel betrachtet aussagekräftig beurteilen zu wollen, ob Seggelmann den Fehler absichtlich eingebaut hat. Aber das halte ich ohnehin für ein hoffnungsloses Unterfangen. Mich interessiert im Moment mehr die Frage nach Seggelmanns Professionalität: hätte er den Fehler nicht sehen müssen. Und ist der Fehler daher nicht einfach als unvorhergesehene, bislang völlig unbekannte Art von Sicherheitslücke zu bewerten, die man auch als routinierter Sicherheitsexperte erst mal nicht erkennen würde (wie es zur Zeit impliziert wird), oder handelt es sich um fahrlässige Schlamperei, für die man keinerlei Verständnis aufbringen sollte? (Das meine ich mit Shit happens.)

2. Interessiert mich natürlich auch die Frage, ob die Konstellation, die hier aufgetreten ist (Entwickler bei OpenSSL mit Renomee baut während seiner Promotionsphase einen Bug ein, der aussieht wie ein Flüchtigkeitsfehler) nicht als Pattern für einen Social Hack par excellence darbieten würde (mal völlig abgesehen von der Frage ob es hier einer war oder nicht)? Dasselbe Muster könnte an anderer Stelle spätestens ab jetzt jede beliebige Interessengruppe anwenden, um eine Sicherheitslücke implementiert zu bekommen. Das muss übrigens nicht einmal ein Geheimdienst wie NSA oder BND sein. Es können auch private Firmen, Kriminelle oder Spaßvögel sich einer solchen Strategie bedienen, wenn sie einen Weg finden, einen Promovenden (der sich finanziell ohnehin in einer prekären Lage befindet) zu instrumentalisieren. Nicht nur technologisch, sondern auch soziologisch muss hier für OpenSSL und andere sicherheitsrelevante Open Source Software ein Verfahren gefunden werden, das dies ausschließt. Andernfalls leben wir damit auf einer Zeitbombe, die jederzeit wieder hochgehen kann. --HV (Diskussion) 08:17, 16. Apr. 2014 (CEST)

3. denke ich bei dem Artikel auch etwas über den Tag hinaus. Wenn der OpenSSL-Bug mal Geschichte geworden ist, werden sich Leser z.B. auch vergleichend mit anderen Bugs auseinandersetzen wollen, um z.B. wiederkehrende Muster für deren Entstehung zu erkennen, o.ä. Der Hinweis auf die Beschäftigung des Fehlerautors mit verwandten Fragen in einer eigenen Schrift, was dann aber am Ende doch zu einem Fehler führt - aus welchen mentalen Gründen auch immer - ist für eine solche Fragestellung ein wichtiges Faktum, das in einer Enzyklopädie nicht vorenthalten werden sollte. Es sollte einfach alles in den Artikel, was einmal von Interesse sein könnte, unabhängig davon, ob wir heute schon voraussehen können, für welche Fragestellung. --HV (Diskussion) 08:43, 16. Apr. 2014 (CEST)

All das ändert nichts daran, das die aussage die du ständig wieder einbaust schlicht und einfach falsch ist! Das ist keine ähnliche Sicherheitslücke – diese beiden Dinge haben rein gar nichts miteinander gemeinsam. Und Natürlich hat er sich Gedanken gemacht, ob die von ihm Entworfene Heartbeat-Erweiterung nicht zu neuen Sicherheitsproblemen führen kann, dass ist Schicht und einfach die wichtigste Aufgabe eines jeden Kryptologen. Der Absatz ist deshalb in der jetzigen, von mir entschärften zwar nicht mehr falsch aber völlig inhaltslos, daher würde ich ihn komplett streichen.

Zu deinen Kommentaren zum Heartbleed-Bug: Speicherüberläufe sind die häufigsten aller sicherheitsrelevanten Programmfehler, da es unzählige Stellen in einem Code gibt in dem sie sich einschleichen können. Das jemand in Rahmen seiner Dissertation an einem OpenSource-Projekt mitarbeitet ist nichts ungewöhnliches, ein Großteil des Codes ist von Freiwilligen. Auch das sich dabei ein Fehler einschleicht und später nicht klar ersichtlich ist ob es ein Fehler oder eine absichtlich eingebaute Hintertüre war ist nichts neues. Insgesamt sehe ich beim Heartbleed – von seiner Auswirkung abgesehen – keine Besonderheiten. -- Michi 11:07, 16. Apr. 2014 (CEST)

ad Abs. 1) Inhaltslos ist eine subjektive Bewertung, weil die Stelle vielleicht nicht Deinem persönlichen Erkenntnisinteresse entgegenkommt. Andere Leser mit anderem Interesse könnten das anders sehen. Ob man den Fehler als ebensolchen, ähnlichen oder dgl. attribuiert ist mir relativ egal. Wenn man zwei Dinge miteinander vergleicht gibt es immer eine gemeinsame Vergleichsebene, die man nicht über- aber auch nicht unterspezifizieren darf. Hierfür suche ich noch nach einem adäquaten und konsensfähigen Adjektiv. Bitte um Vorschläge.

ad Abs 2.) Umgekehrt wird ein Schuh draus: Eben weil Speicherüberläufe und Code-Injections so häufig sind, ist das ja gerade keine Entschuldigung dafür, dass ein ausgewiesener Sicherheitsexperte sie übersieht. Etwas anders wäre es, wenn es sich um eine völlig neue, noch nie dagewesene Art von Sicherheitslücke gehandelt hätte. Das OpenSSL-Team hat ja mittlerweile eingeräumt, dass es aufgrund zu dünner Personaldecke mit der Aufrechterhaltung der Sicherheit, wie man sie von OpenSSL erwartet, überfordert ist [1]. Das gilt natürlich nicht nur für die Anzahl der Entwickler, sondern auch für deren Auswahl. OpenSSL ist eben kein beliebiges Open Source-Projekt, sondern eines mit ganz besonderem Anspruch auf Sicherheit. Es wäre fatal, sich den Entwicklungsprozess etwa so wie den von Wikipedia vorzustellen.

Allen Beteiligten ist das nicht erst jetzt gedämmert, sondern war und ist natürlich schon lange bewusst und wurde entsprechend kritisiert. Man hat halt darauf vertraut, dass bislang nichts passiert ist und untätig zugewartet, bis es mal kracht. So etwas nennt man normalerweise grobe Fahrlässigkeit, und diese Schlußfolgerung muss auch aus den Informationen im Artikel gezogen werden können. Andernfalls würde ich das als aktiven POV seitens zugunsten der Entwicklergemeinde bezeichnen, die sich hier durch Vertuschung und Herunterspielen selbst vor entsprechenden Vorwürfen schützen möchte. --HV

(Diskussion) 11:54, 16. Apr. 2014 (CEST)

Der Vorschlag lautet es wegzulassen, weil es keinen inhaltlichen Zusammenhang zwischen den beiden Aussagen gibt. Der Versuch es in einen Zusammenhang zu stellen, ist TF. --Matthäus Wander 13:26, 16. Apr. 2014 (CEST)

Es wird kein Zusammenhang hergestellt. Dass ein Leser einen solchen Zusammenhang herstellen könnte ist nicht hinreichend für TF. Das Weglassen der Information, dass es sich um keine neuartige, sondern lang bekannte Art von Sicherheitslücke handelt ist aggressiver POV, um Seggelmann aus falsch verstandener Kolegialität zu verteidigen. Benutzer:Matthäus Wander ist nicht neutral, sondern befangen, vgl. [2] --HV (Diskussion) 13:56, 16. Apr. 2014 (CEST)

"Obwohl der Programmierer ..." Damit werden die beiden Aussagen zusammen verknüpft. Nicht durch den Leser, durch den Autor des Satzes. Eine Argumentation ad hominem finde ich nicht in Ordnung. Bleib sachlich. --Matthäus Wander 14:04, 16. Apr. 2014 (CEST)

Genau wegen dieser Argumentation ad hominem, die mir als unregistrierter Benutzer schon mehrfach aufgefallen ist, werde ich mich hier auf Wikipedia nicht registrieren sondern weiterhin als IP bearbeiten. Da kann man mir nicht so einen an den Haaren herbeigezogenen Unsinn unterstellen. Kindergarten. -A. --129.217.151.246 11:08, 17. Apr. 2014 (CEST)

Dann entferne bitte das obwohl, und nicht den ganzen Absatz. Es handelt sich hier nicht um eine Argumentation ad hominem, sondern um den Vorwurf der Befangenheit. Dass Du Dich unter Klarnamen an dieser Diskussion beteiligst, weiss ich zu würdigen, aber wenn Deine Edits offensichtlich in die Richtung gehen, Schaden von Seggelmann, der Uni Duisburg-Essen, dem OpenSSL-Team oder der Open Source-Entwicklergemeinde schlechthin abzuwenden, geht mir das als motivierter POV entschieden gegen die Hutschnur, zumal ich selbst Open Source-Entwickler bin, und der Heartbleed-Bug geeignet ist, über OpenSSL hinaus weitreichenden Schaden anzurichten. Die Selbstverteidigung der Verursacher kann ich nachvollziehen, aber an erster Stelle hat in dieser Situation allerkritischste Selbstreflektion und Ursachenerkenntnis zu stehen. Das gebietet schon allein die Professionalität. Dazu müssen der Öffentlichkeit alle wichtigen Details - auch die peinlichen - schonungslos offenbart werden. --HV (Diskussion) 14:57, 16. Apr. 2014 (CEST)

Nicht das Wort obwohl ist das Problem, sondern die getätigte Aussage. "selbst einen solchen Fehler gemacht" im selben Satz ist genauso TF. Wenn du mir aufgrund von persönlichen Unterstellungen nicht glaubst, glaube zumindest den unzähligen anderen Personen, die dich hier auf der Diskussionsseite und bei en darauf hingewiesen haben, dass zwischen den beiden Aussagen null Zusammenhang besteht und die Verbindung der beiden Aussagen daher spekulativ ist. Meine Edits als "Selbstverteidigung der Verursacher" abzutun, empfinde ich als persönliche Beleidigung. --Matthäus Wander 15:27, 16. Apr. 2014 (CEST)

Wenn Du nicht einsiehst, dass Du objektiv befangen bist, weil Du nicht nur selbst Informatik-Promostionsstudent bist, sondern ausgerechnet auch noch am selben Institut wie Seggelmann, hat es keinen Sinn zu versuchen, mit Dir konstruktiv weiterzuarbeiten. Du wirst es auf einen Edit-War ankommen lassen, um Deine Position durchzudrücken. Eigene Vorschläge machst Du ja nicht. Der Verweis auf WP:en ist hinfällig, weil Dir aufgefallen sein sollte, dass ich die Diskussion dort nicht weitergeführt habe und auch die inzwischen hier gewonnen Einsichten nicht eingebracht habe, solange es mir schien, dass in WP:de eine konstruktive Debatte mit sinnvollem Ergebnis möglich sein könnte. die ich dann später in WP:en wieder einbringen kann. Ich werde nun noch ein letztes Mal Deinen POV revertieren. Dann hast Du nochmals Gelegenheit, hier einen alternativen Formulierungsvorschlag zu machen, den wir dann gemeinsam abnicken können, so wie das in der Wikipedia üblich ist. Andernfalls betrachte ich Dein Verhalten als Vandalismus und ziehe mich da raus. --HV (Diskussion) 16:00, 16. Apr. 2014 (CEST)

Mein Vorschlag ist hier: [3]. Nein, ich promoviere nicht am selben Institut wie Seggelmann, auch nicht in derselben Fakultät. An derselben Uni an einem anderen Campus, ja. --Matthäus Wander 16:16, 16. Apr. 2014 (CEST)

Mir geht es nicht um die Darstellung eines Zusammenhangs, auch wenn mir das wahrscheinlich immer wieder da hineinrutscht, sondern um die Darstellung der Tatsachen. Wer daraus als Leser später welchen Zusammenhang zieht, ist mir egal. Selbst wenn es falsche Zusammenhänge sind. Sonst müssen wir den Artikel Heartbleed vorsichtshalber gleich ganz löschen, denn es gibt mit Sicherheit jede Menge Verschwörungstheorien, aufgrund dessen, was alles schon darin steht.

Befangenheit: selbst wenn Du an einer ganz anderen Universität in Informatik promovieren würdest, dann bist Du immer noch befangen, sobald Aussagen getroffen werden, die Deinen Berufsstand und die damit verbundene Arbeitsweise betreffen, es sei denn Dir gelingt professionelle souveräne Selbstdistanz, wie sie gegenwärtig gefordert ist.

Genau um die Analyse der Arbeitsweise geht es aber bei der Aufarbeitung der Entstehungsgeschichte des Bugs: Wie kann es sein, dass einem promovierten/promovierenden zukünftigen Sicherheitsexperten trotz umfangreichster Ausbildung ein Fehler unterläuft, der nach eigenen Aussagen eigentlich ein Flüchtigkeitsfehler ist? Dürfen einem als Promovierter Flüchtigkeitsfehler unterlaufen, weil man sich ja eigentlich mit komplizierteren Fragestellungen befasst? Wenn nach so gewonnenen Selbstbewusstsein die Flüchtigkeitsfehler dann von subalternem Personal auszuräumen sind, dann muss man dann aber wenigstens noch soviel Grips besitzen, sich darum zu kümmern, ob entsprechendes subalternes Personal in dem Projekt, in dem man mitarbeitet auch zur Verfügung steht. Genau das scheint mir das strukturelle Problem und die von mir bezeichnete Fahrlässigkeit zu sein, die zur Entstehung von Heartbleed geführt hat. Und deren Ursache liegt weniger bei Robin Seggelmann, als im starr hierarchischen Teamaufbau einer deutschen Universität, den auch Du verinnerlicht zu haben scheinst. Dies in Wikipedia auszuformulieren wäre in der Tat TF. Aber es sollen für all diejenigen, die Wikipedia benutzen, um solche Primärforschung betreiben, alle Fakten und Quellen bereitgestellt werden, die für sie von Wert sein könnten. Das ist die Aufgabe eine Enzyklopädie. --HV (Diskussion) 16:50, 16. Apr. 2014 (CEST)

Niemanden geht es hier darum Seggelmann zu verteidigen. Die Information die du ständig wieder einfügst ist und bleibt schlicht und einfach Falsch es handelt sich nicht um den selben, noch um einen ähnlichen Fehler. Mit denen Aussagen "Obwohl", "selbst einen solchen Fehler gemacht", etc. implizierst du genau dies. Das ist einfach falsch. Hör damit auf! Wenn du das weiterhin einbaust, trotz dem, dass es dir hier zahlreiche Leute erklärt haben, dass das Unsinn ist, werde ich das als Edit-War melden. Und hör auf Benutzer:Matthäus Wander Dinge die offensichtlich haltlos sind zu unterstellen.

Was dann noch bleibt ist die Frage ob man einen Hinweis auf die von Seggelmann in der Arbeit erläuterten potenziellen Probleme hinweist. Antwort meiner Meinung: Nein. Denn es hat mit dem Heartbleed-Bug nichts zu tun, es würde höchstens in einen (nicht vorhandenen) Artikel Heartbeat gehören. -- Michi 19:54, 16. Apr. 2014 (CEST)

Bitte schau Dir doch zuerst mal den aktuellen Kompromiss im Artikel an, bevor Du ein obwohl kritisiert, das schon seit Urzeiten dort nicht mehr auftaucht. --HV (Diskussion) 20:37, 16. Apr. 2014 (CEST)

Vorabinformierung von Unternehmen (Erl.)

Ein sehr wichtiger (und umstrittener) Punkt ist, dass die einige ausgewählte Firmen schon früher als die Öffentlichkeit informiert wurden. Das sollte in den Abschnitt "Entdeckung". Auch währen korrekte Daten besser als "Anfang April". (Ich finde gerade die Quelle dafür nicht.) -- Michi 17:40, 13. Apr. 2014 (CEST)

Leider konnte ich hierüber nichts finden. Die "gleichzeitige" Entdeckung lässt vermuten, dass die Öffentlichkeit hier, wie oft, immer nur einen Teil der Wahrheit erfährt. --HV (Diskussion) 18:27, 13. Apr. 2014 (CEST)

Welche Firmen sollen angeblich früher informiert worden sein? Und wer sagt das überhaupt? Redest du hier von Google und Codenomicon? Natürlich waren die vorher drüber informiert - was denn sonst! Dass ein Arbeitgeber wissen möchte, was seine Mitarbeiter in ihrer Arbeitszeit machen, ist ja jetzt nichts Besonderes. --88.130.72.218 19:32, 13. Apr. 2014 (CEST)

Michi zweifelt an, dass der Bug tatsächlich erst am 7. April entdeckt wurde und das dann sofort bekanntgegeben wurde, und dass dann auch noch zeitgleich in zwei unterschiedlichen Firmen jemandem die entscheidende Idee kam. Dazu gibt es mit Sicherheit eine Vorgeschichte, von der wir nichts erfahren werden. Vielleicht ist irgendjemandem, schon länger etwas spanisch vorgekommen, und man hat unter Geheimhaltung lange danach gesucht, vielleicht gab es einen Tipp vom NSA, damit die Sache ordentlich aufgedeckt wird, bevor es nach den Snowden-Enthüllungen jemand zufällig merkt, vielleicht waren Außerirdische im Spiel, oder Nostradamus hat es auch schon gewußt, ... wir werden es wohl nie erfahren. --HV (Diskussion) 20:48, 13. Apr. 2014 (CEST)

Das sind alles Mutmaßungen. Die genauen Abläufe speziell von OpenSSL kenn ich jetzt auch nicht, aber häufig nutzen die Entwickler ein "responible disclosure"-Verfahren an: Sicherheitsrelevante Fehler werden nicht-öffentlich an die Entwickler gemeldet, die überlegen sich einen Fix, kommunizieren mit dem "Finder" und wenn der Fix funktioniert, wird ein Release mit entsprechenden Release-Notes vorbereitet. Ich kenn in diesem konkreten Einzelfall die Hintergründe nicht, aber ich kann dir sagen, dass das alles definitiv nicht an einem Tag passiert. Der genau Zeitpunkt der Mitteilung des Bugs an die Entwickler ist letztlich egal; Hauptsache man installiert flott den Fix. Denkbar ist auch, dass die Entwickler nicht genau Auskunft über ihre internen Abläufe geben wollen, z.B. darüber wie lange sie im Schnitt brauchen, um ein solches Problem zu beheben. Das alles ist aber keine Besonderheit für OpenSSL - ich weiß wie gesagt noch nicht mal, ob das bei denen überhaupt vergleichbar läuft, aber bei vielen Open-Source-Projekten läuft es in der Art. --88.130.72.218 21:53, 13. Apr. 2014 (CEST)

Klar, aber in den Belegen steht nun mal, dass es sich um eine spontane Entdeckung an einem Tag in zwei unterschiedlichen Firmen handelt. Alles andere ist den Journalisten wohl zu kompliziert. Obwohl das offensichtlich Unfug ist, und wir es eigentlich alle besser wissen, können wir es nicht anders schreiben, weil das sonst Theoriefindung wäre (endlich mal ein schönes Beispiel, das ich in anderen Diskussionen schon viel früher mal gebraucht hätte!). Aber ein besseres Verfahren als die Belegpflicht fällt mir nach langer Mitarbeit in der Wikipedia auch nicht ein, selbst wenn es manchmal komische Blüten treibt... --HV (Diskussion) 22:17, 13. Apr. 2014 (CEST)

Wir müssen aber auch nicht wissentlich Falschinformationen verbreiten; manchmal wird ein Text besser, wenn man dubiose Informationen halt auslässt. Mittlerweile spricht der Artikel nur noch vom 7. April als "Veröffentlichungsdatum" des Bulletins; so ist das OK. --88.130.72.218 22:28, 13. Apr. 2014 (CEST)

Nein, ich wollte hier nichts unterstellen oder Verschwörungstheorien aufstellen. Worauf ich mich bezog war dieser Bericht – aber das war wohl eine Fehlmeldung, die darauf zurückgeht, dass Cloudflare den Bug zufällig simultan gefunden hat. -- Michi 01:02, 14. Apr. 2014 (CEST)

Ich habe es in den Artikel gepackt. Es ist ausreichend belegt das einige vor dem öffentlichen Bekanntwerden informiert waren und z.T. ihre System bereits abgesichert hatten. --Slick (Diskussion) 08:49, 23. Apr. 2014 (CEST)

Erstens sollte es dann auch im Artikel selbst belegt werden, zweitens ist das was du sagst erstmal nur ein Fakt und keine Kritik. Die Kritik wäre dann auch nochmal zu begründen und zu belegen. --129.217.151.246 18:57, 23. Apr. 2014 (CEST)

Ubuntu

Ubuntu wird scheinbar nicht gefixt. Kann das jemand erklären? --Itu (Diskussion) 21:17, 13. Apr. 2014 (CEST)

Ne, kann ich nicht - es wird nämlich gefixt. ;-) Ubuntu ist scheinbar ab Version 12.04 betroffen. Der Seite kannst du auch entnehmen, welche Ubuntu-Packages sicher sind. Die oberste Antwort hier zeigt außerdem, wie man Ubuntu aktualisiert. --88.130.72.218 21:47, 13. Apr. 2014 (CEST)

Unklarheit bzgl. Entdeckungs/Veröffentlichungsdatum.

• Durch die Presse ging das ganze am 7. – den haben wir auch im Artikel stehen.
• Hier seht das die Öffentlichkeit aber schon am Sonntagabend informiert wurde.
• Dort steht auch, dass der Bug am Freitag zuvor (das wäre dann der 4.) entdeckt worden sei
• cloudflare hat den Bug aber laut eigenen Informationen schon am 31. März geschlossen.
• Dieser Bugfix bei RedHat ist auf den 21. März datiert.
• heartbleed.com spricht davon das der Bug am 3. April gefunden wurde

Alles in allem ist das also sehr verwirrend. Kennt jemand vertrauenswürdige Quellen? -- Michi 01:23, 14. Apr. 2014 (CEST)

Wahrscheinlich ist die ganze Geschichte noch viel komplizierter und wird im detaillierten Ablauf erst allmählich erläutert werden. Die Quellen betonen ja, dass der Zeitpunkt der Bekanntgabe, wie das ganze Procedere, auch etwas damit zu tun haben, dass Gegenmaßnahmen ergriffen werden mussten bevor Hacker in der Zwischenzeit die Lücke ausnutzen können, und dass daher eine bestimmte Strategie erdacht wurde, den Schaden auf ein Minimum zu begrenzen. Wenn man mal davon ausgehen kann, dass es nahezu keine unsicheren openSSL-Dienste mehr im Netz gibt, werden wir vermutlich mehr erfahren. --HV (Diskussion) 07:30, 14. Apr. 2014 (CEST)

Siehe Heartbleed disclosure timeline: who knew what and when --Matthäus Wander 11:27, 15. Apr. 2014 (CEST)

Whois heartbleed.com hat den 5.April als Registrierdatum. --Itu (Diskussion) 21:53, 15. Apr. 2014 (CEST)

Auslesbare Speichergröße

Warum steht hier im Artikel etwas von max. 16 KB, die mit dem Bug ausgelesen werden können, während "überall sonst"(tm) im Internet von max. 64 KB die Rede ist? Im Heise-Artikel [4] steht inzwischen auch 64 KB. --79.210.53.61 16:51, 14. Apr. 2014 (CEST)

Steht am Ende des genannten Artikels:

Update 11:30, 11.4.2014: Größe des maximal möglichen Speicherblocks korrigiert. Ursprünglich waren als Obergrenze die in der Originaldokumentation des Heartbleed-Bugs aufgeführten 64 KByte angegeben. Die RFCs und auch die Demo-Exploits lassen jedoch nur maximal 16 KByte zu

2. Update 11:19, 14.04.2014: Erneute Korrektur der maximalen Palyoad-Größe: OpenSSL checkt auch diese Größe nicht, sodass tatsächlich die von den Entdeckern der Lücke angegebenen 64 KByte möglich sind.

Letzteres ist also die korrekte Größe. --129.217.151.246 18:04, 14. Apr. 2014 (CEST)

Gibt es dafür eine Quelle abgesehen vom (etwas unklaren) Heise-Artikel? Mit dem Python-Exploitskript von Jared Stafford erhalte ich von www.cloudflarechallenge.com nur 16384 Bytes, auch wenn ich die Payload-Length im Request auf 30000 oder 65535 setze. --Matthäus Wander 22:23, 14. Apr. 2014 (CEST)

Die Quelle ist die heartbleed.com Seite:

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed. (nicht signierter Beitrag von 129.217.151.246 (Diskussion) 11:25, 15. Apr. 2014 (CEST))

Ok, got it. Der Server sendet mehrere Heartbeat-Antworten, die jeweils ca. 16 KB lang sind. Beispiel. 64 KB ist richtig. --Matthäus Wander 22:57, 14. Apr. 2014 (CEST)

Ist das Minuszeichen im Satz "[...]mit einer Anfrage bis zu 64 kByte-1 Byte[1] des Arbeitsspeichers der Gegenstelle auslesen[...]" ein Überbleibsel vom Editieren oder soll es etwas bedeuten (und wenn ja, was)? --ph0nq (Diskussion) 10:09, 15. Apr. 2014 (CEST)

Es soll aussagen, dass man ein Byte weniger vom Server bekommen würde, da man mindestens ein Byte Payload schicken müsste. Die Aussage stimmt allerdings nicht, man muss keinen Payload an den Server schicken: [5] --Matthäus Wander 11:23, 15. Apr. 2014 (CEST)

Die vorzeichenlose 16-Bit-Zahl payload_length kann die Werte von 0 bis 65535 annehmen. Demnach müsste ein Speicherblock mit einer Länge von 0 bis 65535 Byte ausgelesen werden können. 65535 Byte sind 64 Kibibyte − 1 Byte. Die verständlichste Angabe für den Artikel ist daher „bis zu 65535 Byte“.

Danke, erscheint sinnvoll. --Matthäus Wander 17:36, 15. Apr. 2014 (CEST)

Letzten Endes ist es IMHO auch sowohl für diesen Artikel als auch für die Bewertung der Sicherheitslücke selbst reichlich irrlevant ob nun 64kB oder 64kB-1B ausgelesen werden können, das macht nun auch keinen erwähnenswerten Unterschied mehr. -A. (nicht signierter Beitrag von 129.217.151.246 (Diskussion) 11:28, 17. Apr. 2014 (CEST))

Veranschaulichung

Ich würde ein anderes Bild zur Veranschaulichung des Bug's nutzen. Der xkcd veranschaulicht das sehr sehr gut: http://imgs.xkcd.com/comics/heartbleed_explanation.png (nicht signierter Beitrag von 141.71.113.65 (Diskussion) 15:56, 16. Apr. 2014 (CEST))

Unter Welcher Lizenz steht dieses Bild? --HV (Diskussion) 16:12, 16. Apr. 2014 (CEST)

Steht doch drunter: CC-BY-NC -- also inkompatibel zur WP. -- Michi 20:09, 16. Apr. 2014 (CEST)

Ich hatte es übrigens schonmal als Referenz eingestellt, bevor es wieder entfernt wurde: [6] --HV (Diskussion) 16:20, 16. Apr. 2014 (CEST)

Bin dafür, es als referenz einzustellen. -A. --129.217.151.246 11:21, 17. Apr. 2014 (CEST)

Habs unter "Trivia" eingebaut. Die zeitgeschichtliche Rezeption des Vorfalls ist definitiv relevant, und xkcd wird sehr weit rezipiert. --129.13.72.198 18:12, 20. Apr. 2014 (CEST)

Path MTU Discovery

Bitte folgenden Satz allgemeinverständlicher formulieren: "Bei DTLS kann das Heartbeat-Verfahren zur Path MTU Discovery verwendet werden." Was genau ist Path MTU Discover? (Halbsatz in Kommas genügt). Wir schreiben auch für normales Publikum. --HV (Diskussion) 17:44, 16. Apr. 2014 (CEST)

Ist verlinkt und dort erklärt. --Matthäus Wander 17:50, 16. Apr. 2014 (CEST)

Ja, aber auch dort leider sehr fachchinesisch. Ein bisschen Rücksicht auf die Nicht-Insider sollten wir gerade bei der gegenwärtigen Aktualität schon nehmen. Ich kann das leider nicht, ohne selbst unzulässig zu verkürzen oder alternativ zu ausschweifend zu werden. --HV (Diskussion) 18:18, 16. Apr. 2014 (CEST)

Dann sollte man eher den dort verlinkten Artikel umformulieren, anstatt hier jedes Details zu erklären. Bei jemandem, der den fehler technisch verstehen möchte, sollte man davon ausgehen dass er selbst auf die verlinkte Seite geht. -A. (nicht signierter Beitrag von 129.217.151.246 (Diskussion) 11:28, 17. Apr. 2014 (CEST))

Das wäre mir persönlich egal. Ich selbst kriege es halt wahrscheinlich nicht ohne Geschwurbel hin, weil ich in diese Materie nicht eingearbeitet bin. Ist mir nur auf Anhieb als schwerverdaulich aufgefallen. --HV (Diskussion) 13:25, 17. Apr. 2014 (CEST)

"Ist" versus "war" im Einleitungssatz

Aus der Einleitung:

Der Heartbleed-Bug ist ein schwerwiegender Programmfehler in der Open-Source-Bibliothek OpenSSL, der durch seine Tragweite Auswirkungen auf große Teile des Internets hatte und 2014 weltweites Medienecho erzeugte.

Ich schlage vor, "ist" durch "war" zu ersetzen, "ist" hört sich für mich so an als gäbe es diesen Fehler immer noch, obwohl er schon behoben wurde. --84.60.102.199 18:51, 18. Apr. 2014 (CEST)

Den Fehler gibt es noch, er existiert weiter in den OpenSSL-Versionen 1.0.1 bis 1.0.1f und den Systemen, die eine dieser Versionen einsetzen. Da der Fehler seit weniger als zwei Wochen öffentlich bekannt ist, kann man nicht annehmen, dass alle betroffenen Systeme behoben seien. --Matthäus Wander 18:59, 18. Apr. 2014 (CEST)

Ausschlaggebend sollte doch aber seien, dass er im offiziellen OpenSSL-Repo behoben ist. Wenn ich als Unbeteiligter aber diesen Einleitungssatz lesen würde dann würde ich davon ausgehen dass genau das eben nicht der der Fall ist. "Der Heartbleed-Bug ist ein schwerwiegender Programmfehler in der Open-Source-Bibliothek OpenSSL..." klingt für mich so als sei die neuste Version von OpenSSL gemeint. --84.60.102.199 00:41, 19. Apr. 2014 (CEST)

Ein Fehler bleibt er weiterhin: „Heartbleed ist ein Fehler, der in den OpenSSL-Versionen 1.0.1 bis 1.0.1f war.“ Es sollte aber bereits in der Einleitung aufgeführt werden, dass der Fehler in OpenSSL behoben ist. Ein „war“ alleine drückt das nicht klar aus. --Fomafix (Diskussion) 12:50, 19. Apr. 2014 (CEST)

Mit dem Satz „Heartbleed ist ein Fehler, der in den OpenSSL-Versionen 1.0.1 bis 1.0.1f war.“ bin ich auch zufrieden. Momentan wird aus dem Einleitungssatz gar nicht klar dass dieser Fehler in der aktuellen OpenSSL-Version bereits behoben wurde. Oder auch "Heartbleed ist ein Fehler in den OpenSSL-Versionen 1.0.1 bis 1.0.1f". Alternativ ein Zusatzsatz "Betroffen waren die OpenSSL-Versionen 1.0.1 bis 1.0.1f" - Wobei, aus letzterem geht auch nicht hervor dass es bereits eine neuere Version gibt.--84.60.98.78 13:27, 19. Apr. 2014 (CEST)

Betroffene Versionen (und etwas mehr) ergänzt. --Matthäus Wander 16:12, 19. Apr. 2014 (CEST)

Begründung für beliebigen Payload beliebiger Länge?

(wurde auf Disk:OpenSSL schon mal gefragt, kam aber bis jetzt nichts) Gibt es mittlerweile irgendwelche Begründungen für die Implementation einer beliebigen Payload beliebiger (<16 kbyte) Länge? Es wurde ja vom Author ein Zeitstempel angeführt [7], nur reichten da feste 32 Bit (und man könnte gleichzeitig die Längenvariable einsparen, effektiv also 16 Bit). Im Moment scheint es, als ob der Bug an einer völlig überflüssigen Funktionalität aufgetreten wäre. Das läd zu Verschwörungtheorien ein. Wurde das echt noch nirgendwo in der Computrpresse thematisiert? --129.13.72.198 17:57, 20. Apr. 2014 (CEST)

doch, schon mehrfach: Path MTU Discovery. --Mario d 10:04, 21. Apr. 2014 (CEST)

Nein, dafür gibt es ja das in der verlinkten Mail erwähnte padding, mit der man die Pakete auf dem Hinweg beliebig aufblähen kann. --129.13.72.198 13:03, 21. Apr. 2014 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• https://www.openssl.org/news/secadv_20140407.txt
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/https://www.openssl.org/news/secadv_20140407.txt

– GiftBot (Diskussion) 17:43, 13. Feb. 2016 (CET)

Katastrophenskala

Tut mir leid, ich lese das hier heute zum ersten Mal. Und da fällt mir auf, dass der Artikel noch von der (ersten?) Aufregung geprägt ist, sehr verständlich! Übrigens Glückwunsch zur verständlichen Erklärung des Mechanismus’. Ich stelle mir allerdings vor, dass die Auswirkungen auf Otto Normalbürger wie mich Null waren, auf jeden Fall, dass es von Fall zu Fall draufankommt. Konkret tät’ ich bitten, die alarmistische Aussage von Bruce Schneier ersatzlos zu streichen:

Der Kryptologe und Sicherheitsexperte Bruce Schneier beschreibt die Tragweite des Heartbleed-Bug als:

   “Catastrophic is the right word. On the scale of 1 to 10, this is an 11.”
   „Katastrophal ist das richtige Wort. Auf einer Skala von 1 bis 10 ist dies eine 11.“

– Bruce Schneier[21]

Wir sind hier kein Sensationsblatt, und gerade Meinungen sind Ansichtssache. Sich – wie anderswo auch gern – hinter einem Zitat zurückzuziehen, ist Leitartikelstil statt gepflegter Fakten. Sorry, nicht bös gemeint. – Fritz Jörn (Diskussion) 14:22, 12. Feb. 2017 (CET)

Bruce Schneier ist nunmal der meist zitierte Crypto-Experte. Und die Einschätzung das dies ein GAU im wahren sinne des Wortes war ist nicht nur seine Meinung, sondern die allgemeine Einschätzung aller Experten. Über Jahre hinweg waren die Verschlüsselungen zu den allermeisten Webservern der Welt wirkungslos. Auch nach Veröffentlichung dauerte es bei vielen Seiten Tage bis sie wieder sicher waren und einige wenige System sind heute noch betroffen. Man könnte höchstens den zweiten Satz streichen, weil inhaltslos, aber die Einschätzung als "Katastrophal" sollte meiner Meinung nach auf jeden Fall drin bleiben. Im Gegensatz, das Kapitel "Auswirkungen" müsste dringend ausgebaut werden, es fehlen beispielsweise die ganzen Spätfolgen, wie die Gründung der Core Infrastructure Initiative fehlen. -- Michi 17:49, 12. Feb. 2017 (CET)

Trivia: The Unguided – Zusammenhang zu Bug wirklich gegeben?

Die schwedische Metalcore-Band The Unguided widmete dem Heartbleed-Bug auf ihrem Album "And the Battle Royale" ein Lied

Weder aus dem auf YouTube vorhandenen Liedtext, noch nach dem benutzen Einzelnachweis ist ersichtlich, dass hier im Lied wirklich der Heartbleed-Bug dieses Artikels gemeint ist. Es wird zwar expklizit "Heartbleed-Bug" genannt, jedoch nicht in technischen Zusamenhang: "True love, a chemical illusion, a heartbleed bug…"

Ich würde das also entfernen, außer jemand hat einen Beleg für den Zusammenhang? Oder lohnt es sich diesbezüglich bei der Band nachzufragen? --rugk (Diskussion) 00:29, 19. Jan. 2018 (CET)

Insbesondere, dass das Album ja einige Jahre nachdem Bug veröffentlicht wurde, lässt da Zweifel offen. --rugk (Diskussion) 00:51, 19. Jan. 2018 (CET)

Ja, entfernen. Der Zusammenhang ist nicht offensichtlich, nicht belegt und somit TF. --Matthäus Wander 11:48, 24. Jul. 2023 (CEST)

Betroffenheit nicht vernachlässigbar!

Mit Yahoo Namen und Fake-Absende-Mailadressen werden seit 2014 viele Menschen "vollgespamt". Die Mails enthalten häufig Links zu Viren-verseuchten Inhalten. Es werden Verteiler verwendet, die dem Empfänger Vertrauen suggerieren, da es sich um Kreise handelt, in denen er sich bewegt. Unsere Tochter ist eines der Opfer und hat jede Menge Vorwürfe auszuhalten, kann aber nichts mehr dagegen unternehmen. Lt. Fachleuten waren ihre Daten vor März 2014 im Rahmen dieser "Heartbleed"-Lücke entwendet worden. Wenn das nicht widerlegt ist, dann betrifft es sicher auf ähnliche Weise auch viele andere Mitmenschen, die seinerzeit einen Yahoo-eMail-Account hatten. - Auch wenn die Betroffenen den Anbieter gewechselt haben, werden diese Spam-Mails ja weiterhin versandt, und zwar jetzt seit 7 Jahren. Es betrifft allein in meinem Bekanntenkreis noch mehrere Personen, die z. T. auch Vorwürfen ausgesetzt sind. Unter diesem Aspekt kann die Aussage nicht stehen bleiben, dass kaum jemand betroffen sein dürfte. Vgl. auch folgende Quelle:

https://www.heise.de/security/meldung/Heartbleed-Yahoo-und-Web-de-raten-zum-Passwortwechsel-2167630.html (nicht signierter Beitrag von DietVo (Diskussion | Beiträge) 21:56, 2. Aug. 2021 (CEST))

An welcher Stelle steht denn die Aussage, dass kaum jemand betroffen sein dürfte? --Matthäus Wander 19:25, 28. Jul. 2023 (CEST)