Diskussion:OpenSSL

message: Wie jetzt? Nicht mal eine Erwaehnung des aktuellen Sicherheitsproblems mit schwachen Schluesseln bei Debian-Distributionen? Ich hab wenigstens mal einen Link reingepackt, aber waere ja net swchlecht wenn jemand vielleicht noch etwas ausfuehrlicher darueber schriebe.
http://lists.debian.org/debian-security-announce/2008/msg00152.html --77.1.234.53 10:32, 25. Mai 2008 (CEST)
thread_title:  Debian Sicherheitsproblem 

message: Da 1. Felix ein Experte im Bereich der IT Sicherheit ist und 2. das Forum sich auf Felix Blog bezog und nicht anders herum, habe ich den Entwurf gesichtet. Nun sollte man ersteinmal darüber nachdenken, in wiefern wir hier mit dieser Quelle umgehen - in der Zwischenzeit sollte man aber nicht auf das Forum zurückgreifen, da dieses wissenschaftlich wirklich keinerlei Bedutung hat. Lass uns doch erstmal in Ruhe diskutieren und den Artikel lassen wie er war und dann handeln. --Mullinger 11:19, 24. Okt. 2009 (CEST)
replies: text: Wenn der Fall sogar "besonders prominent" war, lässt sich doch hoffentlich ein seriöser Beleg finden. Ansonsten sollte die Aussage gelöscht werden. --08-15 16:15, 24. Okt. 2009 (CEST)
thread_title:  Sichtung der Wiedereinfügung des Blogs 

message: Seit 5. November 2009 gibt es übrigens die Version 0.9.8l . -- Lukas0907 20:52, 16. Nov. 2009 (CET)
replies: text: Entsperrt und Eingetragen. --Fomafix 13:06, 17. Nov. 2009 (CET)
thread_title:  Neue Version 

message: Da hier erhebliche Mengen an Informationen hinterlegt werden - mal der Vorschlag diese Auflistung in ein neues Lemma z.B. OpenSSL_Versionsübersicht auszulagern um den Artikel lesbar zu lassen. Bitte um euer Pro/Contra. LG --Majx 00:32, 9. Aug. 2011 (CEST)
replies: text: Ggf. auf die wichtigen Punkte kondensieren und ansonsten das Projekt verlinken. Ein eigener Artikel ist nicht sinnvoll. --08-15 02:28, 9. Aug. 2011 (CEST)
replies: text: History ist jetzt aufgelistet. Ist scheinbar doch nicht so schlimm wie erwartet. :) LG --Majx 15:28, 10. Aug. 2011 (CEST)
thread_title:  Versionsübersicht in neues Lemma 

message: Handelt es sich wiedereinmal um die Ausnutzung eines Pufferüberlaufs ? Werden Programmierer und ihre Auftraggeber jemals beginnen, typsichere Programmiersprachen mit zuverlässiger Zuweisungskompatibilität einzusetzen und zu fordern, bei denen das grundsätzlich nicht passieren kann ? --Bautsch (Diskussion) 15:13, 9. Apr. 2014 (CEST)
replies: text: Nein, es handelt sich nicht um einen Pufferüberlauf! Das wird manchmal falsch dargestellt. Es ist auch kein fehlerhafter Zugriff sondern schlicht und einfach uninitialisierter Speicher. Warum initialisiert OPENSSL_malloc den Speicher nicht? Warum wird ein Speicherbereich der freigegeben wird nicht sofort gelöscht, wie es bei sicherheitsrelevanten Anwendungen selbstverständlich sein sollte? Dieser Bug wäre mit einer typensicheren Sprache genauso passiert! Einzig eine Sprache oder Speicherverwaltungsbibliothek, die unitialisierten Speicher nicht zulässt, würde davor schützen. --Hokanomono (Diskussion) 21:54, 9. Apr. 2014 (CEST)

text: Die Payload-Länge aus der Heartbeat-Anfrage wird ungeprüft übernommen, auch wenn der mitgelieferte Payload kürzer ist (z. B. 0 Bytes lang). Der Payload wird aus der Anfrage in einen Antwortpuffer kopiert. Durch den Bug liest man über das Ende des Eingabe-Payloads hinaus und kopiert bis zu 64 KB aus dem Heap in den Ausgabepuffer . Das Problem ist ein fehlender Bounds Check der Payload-Länge: ist der eingebene Payload mindestens so lang wie der Ausgabepuffer? Initialisierung des Ausgabepuffers hilft nicht, da der Ausgabepuffer beim Kopieren vollständig überschrieben wird. --Matthäus Wander 01:24, 10. Apr. 2014 (CEST)
replies: text: Wenn bei einem Datenfeld die Indexgrenzen nicht vom Compiler (bei statischen Datentypen) oder spätestens vom Laufzeitsystem (bei dynamischen Datentypen) überwacht werden (Bounds Check), dann ist das aus meiner Sicht doch ein knallharter Fall von Datentypunsicherheit und manglender Zuwesungskompatibilität (typisch übrigens bei Arrays in der Programmiersprache C, die lediglich über einen Zeiger referenziert werden). --Bautsch (Diskussion) 11:45, 10. Apr. 2014 (CEST)
replies: text: Und OpenSSL ist in C programmiert!--Bautsch (Diskussion) 11:52, 10. Apr. 2014 (CEST)

text: Danke Matthäus Wander. Ich hatte übersehen, dass der entscheidende Schritt beim memcpy passiert. Ich nehme alles zurück. --Hokanomono (Diskussion) 06:18, 11. Apr. 2014 (CEST)

text: Ja, eigenes Lemma wäre gerechtfertigt. --Matthäus Wander 01:54, 11. Apr. 2014 (CEST)

text: Die Frage hat jemand auf der entsprechenden IETF Mailing-Liste gestellt  und von einem der RFC-Autoren eine Antwort erhalten . Die laut RFC erlaubte Länge sind übrigens 16 KB, da das die maximale Länge von TLS-Nachrichten ist. Dass da 64 KB durchgehen, liegt auch schon nur am Bug. --Matthäus Wander 01:48, 11. Apr. 2014 (CEST)
replies: text: OK, aber in der Antwortmail wird von einem Zeitstempel als möglicher Payload geredet. Dafür reicht ein 32 Bit - Wert. Wie kommt man dann dazu 16KB vorzusehen? Das stinkt doch echt danach, als ob da noch eine weitere Idee dahintersteckte. Vielleicht keine Backdoor, aber irgend ein unausgereiftes, später nicht implementiertes Feature. Mal abwarten wa da noch so rauskommt. --129.13.72.198 06:20, 11. Apr. 2014 (CEST)
thread_title:  Heartbleed-Bug 

message: Sollte man die nicht standardmäßig ausblenden, oder gar auslagern? Die ist ja wirklich nur für historische Untersuchungen interessant. --88.66.43.132 00:34, 11. Apr. 2014 (CEST)
replies: text: Lieber ausblenden (also einklappen) statt auslagern. --Matthäus Wander 01:59, 11. Apr. 2014 (CEST)
replies: text: Ne Ahnung wie das geht? Ich find unter einklappen und ausblenden nix. --129.13.72.198 06:27, 11. Apr. 2014 (CEST)
replies: text: Vielleicht hilft diese Seite weiter: Hilfe:Tabellen#mw-collapsible. --Matthäus Wander 01:03, 12. Apr. 2014 (CEST)
thread_title:  Versionsgeschichte 

message: Die Darstellung des genauen Hergangs und Nennung der beteiligten Personen ist wegen des einmaligen Vorgangs der Kompromittierung von sicherheitsrelevanter OpenSource-Software für die Öffentlichkeit von erheblicher Bedeutung. Am Hergang lässt sich erkennen, worauf die Entwicklerkcommunity in Zukunft neben den technischen Aspekten besonders achten muss! --HV (Diskussion) 15:40, 11. Apr. 2014 (CEST)
replies: text: Ja, und bitte Ross und Reiter nennen, also nicht nur den Programmierer Robin Seggelmann (Reiter), sondern auch die von ihm verwendete völlig unsichere Programmiersprache C (Ross). Ich finde es unerträglich und unverständlich, dass sicherheitsrelevante Software in C programmiert werden darf. --Bautsch (Diskussion) 18:47, 11.beim Ausbessern und Erweitern von OpenSSL  Apr. 2014 (CEST)
Muss hier der vollständige Name des Programmierers genannt werden? In den meisten Medien-Berichten wurde er zumindest nicht erwähnt.--91.7.243.155 19:36, 11. Apr. 2014 (CEST)

text: die beschreibung des hergangs ist sicher notwendig. ich sehe aber nicht, welchen enzyklopaedischen mehrwert die namensnennung haben soll. es gilt der grundsatz "Im Zweifel für die Privatsphäre", s. WP:Persönlichkeitsrechte#Weniger bekannte Personen: "Grundsätzlich ist – wie bei jedem anderen in einem Artikel erwähnten Faktum – eine Prüfung der enzyklopädischen Relevanz notwendig. In Grenzfällen sollte die Daumenregel lauten: „schädige niemanden“. Wikipedia ist ein Projekt zum Aufbau einer Enzyklopädie, keine Tageszeitung." es handelt sich zudem nicht um einen einmaligen vorgang, s. OpenSSL#Schwache Schlüssel unter Debian, bei dem zu recht kein name genannt wird. --Mario d 08:22, 12. Apr. 2014 (CEST)
replies: text: Das sehe ich auch so. Andererseits handelt es sich beim Schreiben des fehlerhaften Codes um einen einmaligen Vorgang; wir wüssten nicht, dass der Entwickler jahrelang solche Sachen geschrieben hätte. Es ist zwar für sich genommen ein bedeutender Fehler - keine Frage. Aber für diesen Programmierer ist es ein Einzelfall. Außerdem sehe ich außer ihm auch noch andere Personen in der Verantwortung: Es gibt da auch den OpenSSL-Release-Manager. Natürlich kann der sich nicht jede einzelne Änderung im Detail anschauen. Aber er muss durch Vorgaben an die beteiligten Entwickler zumindest strukturell versuchen sicherzustellen, dass derartige Fehler nicht vorkommen können. Und dann gibt es da noch das Review: Zwar hat der Autor den Code geschrieben, aber es war nicht er, der ihn in das OpenSSL-Repository eingefügt hat. Das war ein anderer Programmierer, der den Code zuerst hätte überprüfen müssen. Ob er das getan hat, weiß ich nicht. Warum ihm diese Fehlerquelle nicht aufgefallen ist, weiß ich auch nicht. Aber gerade bei sicherheitsrelevanter Software hielte ich es für unverantwortlich, wenn er einfach so auf den blauen Dunst irgendeine Änderung merged, die er selbst nicht versteht. Vll. kannte er auch den Programmierer, der den Code geschrieben hatte, wusste, dass der sonst immer gute Arbeit liefert und hat ihm auch in gewissem Maße vertraut. Das weiß ich alles nicht, aber vorstellbar ist es. Langer Rede kurzer Sinn: Es ist nicht nur der Autor des Fehlers, der verantwortlich ist. Derjenige, der den Fehler gemerged hat, weiß, dass die Code-Änderung nicht durch das Schreiben des fehlerhaften Codes, sondern durch seine positive Prüfung in das offizielle Repository gelangt. MMn ist daher wie der Autor selbst, auch der Prüfer in mindestens demselben Maße verantwortlich. Auch dessen Name ist nach WP:Bio unter Berücksichtigung der oben genannten Gründe hier nicht explizit zu erwähnen. --88.130.100.20 12:03, 12. Apr. 2014 (CEST)
replies: text: Ich hab bei den zuständigen Stellen der Wikimedia Foundation angefragt, ob wir ihrer Meinung nach nach der Persönlichkeitsrechtsverletzung noch eine Versionslöschung durchführen müssen und direkt darum gebeten, dass sie die problematischen Versionen ggf. dann auch direkt beseitigen. --88.130.100.20 12:12, 12. Apr. 2014 (CEST)
replies: text: Ist nach der Entfernung des Namens der Rest der Aussage: "arbeitete zu dieser Zeit an seiner Dissertation, die sich mit OpenSSL befasst" - nicht nur dann von Wert für den Artikel, wenn man hinzufügt, ob es (trotzdem) für einen Doktortitel ausgereicht hat? Alexpl (Diskussion) 16:36, 12. Apr. 2014 (CEST)
replies: text: das hier ist der artikel ueber OpenSSL. ob ein mitverursacher eines bugs jetzt seinen titel bekommen hat oder nicht, finde ich sehr weit weg vom thema. --Mario d 16:44, 12. Apr. 2014 (CEST)
replies: text: Dann nehmt die Diss. komplett raus. Alexpl (Diskussion) 16:54, 12. Apr. 2014 (CEST)
replies: text: ist erledigt. --Mario d 19:04, 12. Apr. 2014 (CEST)

text: Die Namensnennung ist im Artikel nicht unbedingt notwendig, jedoch kursiert der Name in den englischsprachigen Medien schon seit Langem (daher habe auch ich ihn) und ist daher bereits hinlänglich öffentlich (vgl.a. en. Der Sachverhalt, dass es sich dabei um das Werk eines Promotionsstudenten handelt, ist jedoch von erheblichem Belang, um zu verstehen, was für ein Personenkreis an den Technologien mitentwickelt, auf die Millionen von Benutzern weltweit täglich vertrauen. Die Nennung der veröffentlichten Dissertation ist als Beleg nach Wikipediaregeln unumgänglich, da darin vom Autor direkt auf das Heartbleed-Problem eingegangen wird. --HV (Diskussion) 09:29, 13. Apr. 2014 (CEST)
replies: text: verschwoerungstheorien und wer wen warum doof findet sind kein thema fuer die WP. dafuer gibt es blogs. --Mario d 10:12, 13. Apr. 2014 (CEST)

text: bisher gibt es keinen einzigen hinweis darauf, adss der bg absichtlich eingebaut wurde. solche spekulationen sollten wir daher unterlassen. --Mario d 10:19, 13. Apr. 2014 (CEST)
replies: text:  Lieber Mario, hier geht es nicht um Verschwörungen, sondern um belegte Tatsachen, im Rahmen des größten Sicherheitsskandals seit es kommerzielles Internet gibt. Inzwischen scheint es Mode geworden zu sein, selbst Tatsachen, bei denen Leute zu Verschwörungstheorien angeregt werden könnten, präventiv als Verschwörungstheorie anzusehen. Deinen vorauseilenden Gehorsam halte ich für reichlich POV. Gehe mal in dich, und begreife, was hier tatsächlich passiert ist. --HV (Diskussion) 10:23, 13. Apr. 2014 (CEST)
replies: text: Zusatz: Nur weil jemand denken könnte, es sei Absicht und von der NSA organisiert, ist das kein Grund diese Tatsache wieder zu entfernen. Ich ziehe genausogut den Schluss, die Tatsache, dass Seggemann einen Fehler, den er selbst kennt, abzusichern vergisst, eher ein Hinweis auf dessen absolute technische Inkompotenz darstellt. In jedem Fall gehört diese Ungeheuerlichkeit zur Bewertung der sicherheitstechnischen Lage von OpenSSL natürlich in den Artikel hinein. --HV (Diskussion) 10:37, 13. Apr. 2014 (CEST)
thread_title:  Genauer Hergang beim Heartbleed-Bug 

message: Ich versuche gerade den Heartbleed-Bug in eine eigene Seite zu überführen, jedoch bekomme ich auch bei 1 zu 1 Übernahme des Artikeltextes Referenz Fehler. Könnte mir jemand behilflich sein?
* Benutzer:Slick/Heartbleed
--Slick (Diskussion) 09:59, 13. Apr. 2014 (CEST)
replies: text: Sehr gute Idee. Fehler gefixt. --HV (Diskussion) 10:25, 13. Apr. 2014 (CEST)
thread_title:  Heartbleed - eigenständiger Artikel 

message: 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)
replies: text: Theo de Raadt ist nicht irgendwelche Kritik und sein inhaltlicher Hinweis ist substantiell. --HV (Diskussion) 10:26, 13. Apr. 2014 (CEST)
replies: text: 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)
replies: text:  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)
thread_title:  kritik am OpenSSL-team 

message: OpenSSL wurd zu LibreSSL geforkt, siehe auch ,  und . --92.231.86.212 18:13, 23. Apr. 2014 (CEST)
thread_title:  Fork zu LibreSSL 

message: Im Abschnitt "Bemerkenswerte Sicherheitslücken" wäre ein Extrakt aus Dr. Falko Strenzkes "An Analysis of OpenSSL's Random Number Generator" anzufügen
(oder der Abschnitt auszulagern). Er geht dabei auch auf die OpenSSL-Alternativen LibreSSL und BoringSSL ein.
Quelle: https://eprint.iacr.org/2016/367.pdf / http://www.cryptosource.de/posts/openssl_rng_flaws_en.html
J744 (Diskussion) 15:46, 13. Apr. 2016 (CEST)
thread_title:  Im April 2016 veröffentlichte Sicherheitslücken