Diskussion:OpenSSL

Letzter Kommentar: vor 9 Tagen von 62.156.206.53 in Abschnitt Neue Version

Debian Sicherheitsproblem Bearbeiten

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

Kommentar: Warum über eine Sicherheitslücke so ausführlich (Hälfte des Artikels) geschrieben wird, wenn das Problem nicht bei OpenSSL sondern bei Debian lag ist mir nicht klar. Vielleicht sollte man den Abschnitt auf die Wikipedia Seite von Debian schieben ... (nicht signierter Beitrag von 87.163.105.145 (Diskussion) 21:13, 27. Mai 2010 (CEST)) Beantworten

Linklöschung zu FeFes Blog Bearbeiten

Als Nutzer der Wikipedia protestiere ich dagegen, dass durchgeknallte <PA entfernt -- Cymothoa Reden? Bewerten 00:15, 24. Okt. 2009 (CEST)> jetzt schon dazu übergehen Primäquellen zu revisionieren, weil sich daraus eine Relevanz an anderer Stelle ableiten läßt. Unabhängig davon bitte ich den "Liberalen Humanisten" doch mal ein wenig Abstand von Wikipedia zu nehmen, offensichtlich tut ihm der intensive Einsatz hier nicht gut -- 89.247.200.85 02:38, 23. Okt. 2009 (CEST)Beantworten

+1 --Schumbitrus 03:44, 23. Okt. 2009 (CEST)Beantworten
1) Sehe ich genau so - 2) Er ist selbst zur Einsicht gekommen - 3) Statt zu Flamen, hättest du lieber mal gucken können, wie zum Einen die Formatierung hier funktioniert und zum Anderen halt die Geschichte des Artikels und der Diskussionsseite näher anschauen. --T-Man 04:05, 23. Okt. 2009 (CEST)Beantworten
Also für mich ist das die Anwendung von Doppeldenk. --Re-aktor 09:37, 23. Okt. 2009 (CEST)Beantworten

Nach meiner Ansicht ist sowohl vom gesunden Menschenverstand, als auch von den Wikipediaregeln nicht ersichtlich, warum eine Quelle entfernt wird, aber der Inhalt weiterhin bestehen bleibt. Entweder sollte nun eine bessere Quelle angegeben werden, oder es sollte auch der nun unbelegte Inhalt entfernt werden. Das ist mir alles nicht ersichtlich. (Auch warum vor der Vollsperrung der Inhalt nicht auf die Version vor dem Editwar gesetzt wurde). --Wikieditoroftoday (disk.) 11:45, 23. Okt. 2009 (CEST)Beantworten

Siehe auch Benutzer Diskussion:Sargoth#OpenSSL Sperre --Wikieditoroftoday (disk.) 12:14, 23. Okt. 2009 (CEST)Beantworten
Nur ein Beispiel. Also: wissenschaftlich valide belegen bitte - oder gar nicht. Ein invalider Beleg suggeriert wissenschaftliche Nachprüfbarkeit. Wurde Leitners Beitrag peer-reviewed? Erschien er zumindest in einer Fachzeitschrift? Gibt es mindestens unter allen Autoren dieses Artikels einen Konsens, dass der Artikel in Leitners Online-Tagebuch wissenschaftlichen Kriterien genügt? Eine Frage sollte mit ja beantwortet werden.−Sargoth 12:32, 23. Okt. 2009 (CEST)Beantworten
Da es zu dem Thema keine wissenschaftliche Publikationen gibt, sind nach Wikipediarichtlinien auch nicht wissenschaftliche Belege erlaubt. Natürlich muss man bei nicht wissenschaftlichen Publikationen sehr vorsichtig sein. Aber dies rechtfertigt nicht, dass der Beleg (siehe Belegpflicht) für die Informationen entfernt wird. Das Beispiel ist hinfällig, da sich die Information problemlos widerlegen lässt.
Das Problem sind die Informationen! Nicht die Belege. Passen Dir die Informationen nicht, dann belege bitte, dass diese falsch sind und wir können diese (samt - dann falschem - Beleg) entfernen. Ansonsten sehe ich keinen Grund, warum die Belegpflicht verletzt werden sollte, weil die Form des Beleges nicht Deinem persönlichen Geschmack entspricht.

--Wikieditoroftoday (disk.) 12:39, 23. Okt. 2009 (CEST)Beantworten

Deine Argumentation hinkt, denn dann müsste auch jede Zeitung als Quelle gelöscht werden. Professioneller als 9 von 10 Zeitungsartikeln ist dieser Beitrag allemal recherchiert. --TheK? 22:02, 23. Okt. 2009 (CEST)Beantworten
Das Online-Tagebuch einer Person außerhalb des wissenschaftlichen Diskurses ist kein Beleg und wird es nicht dadurch, dass es als solches in einem Wikipedia-Artikel eingebunden wird, denn Wikipedia ist und wird nie zitierfähig. −Sargoth 12:49, 23. Okt. 2009 (CEST)Beantworten
Weblogs sind teilweise hochwertige journalistische Erzeugnisse und deine "Begründung" erweist sich als billiger Vorwand angsichts dessen, was du sonst als "seriöse Quelle" pushst (Springerpresse und Co als Beispiel) --87.185.52.84 23:55, 23. Okt. 2009 (CEST)Beantworten
Es ist die Quelle für die Information in der Wikipedia. Daher bleibt nur übrig, die Information zu entfernen (da sie ja sonst unbelegt ist) oder den Beleg durch einen besseren zu ersetzen oder einfach alles auf dem Stand vor dem Editwar zu belassen. (und eine mögliche Diskussion über die Glaubwürdigkeit der Quelle auf den Zeitpunkt verschieben, wenn diese wirklich von jemandem angezweifelt wird (in dem die Informationen angezweifelt werden)) --Wikieditoroftoday (disk.) 13:07, 23. Okt. 2009 (CEST)Beantworten

Also wie gerade im Chat gesagt: Felix von Leitner wurde von u.a. der c't oft genug als "Sicherheitsexperte" bezeichnet, dass man ihn hier als "Fachmann" einstufen kann, der darüber urteilt. Als solcher _sind_ seine Erkenntnisse für einen ref ausreichend qualifiziert. Das bezieht sich aber ausdrücklich nur auf das Thema IT-Sicherheit, nicht seine Ergüsse zur Tagespolitik (aber das sind auch nur Links auf andere Meldungen). --TheK? 22:14, 23. Okt. 2009 (CEST)Beantworten

<PA entfernt -- Cymothoa Reden? Bewerten 00:15, 24. Okt. 2009 (CEST)>Beantworten

Sichtung der Wiedereinfügung des Blogs Bearbeiten

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

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

Neue Version Bearbeiten

Seit 5. November 2009 gibt es übrigens die Version 0.9.8l [1]. -- Lukas0907 20:52, 16. Nov. 2009 (CET)Beantworten

Entsperrt und Eingetragen. --Fomafix 13:06, 17. Nov. 2009 (CET)Beantworten


Es gibt übrigens neue Updates.
Für die Versionsgeschichte: Version 3.0.13 wurde im Januar 2024 released.
Wie ist das eigentlich mit den anderen Versionen, die bei OpenSSL.org auch aktuell verfügbar sind aber in der Versionsgeschichte nicht gelistet werden? Die Versionen 3.1.x und 3.2.x werden im Artikel zum Beispiel gar nicht erwähnt.
Hier mal eine Liste der bei OpenSSL.org aktuell verfügbaren Versionen:

OpenSSL download files release dates
Datum Zeit Release Bemerkung
2024-Jan-30 14:03:52 openssl-3.0.13 LTS version
2024-Jan-30 14:03:52 openssl-3.1.5
2024-Jan-30 14:03:52 openssl-3.2.1
2024-Apr-09 12:26:08 openssl-3.3.0

(Source: https://www.openssl.org/source/index.html) (nicht signierter Beitrag von 62.156.206.53 (Diskussion) 10:35, 24. Apr. 2024 (CEST))Beantworten

Versionsübersicht in neues Lemma Bearbeiten

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

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)Beantworten
History ist jetzt aufgelistet. Ist scheinbar doch nicht so schlimm wie erwartet. :) LG --Majx 15:28, 10. Aug. 2011 (CEST)Beantworten

Aussprache Bearbeiten

Kann bitte jemand der weiss wie das gehört die Aussprache von SSLeay nach IPA ergänzen? Besten Dank. --Taxi1729 (Diskussion)

Heartbleed-Bug Bearbeiten

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

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)Beantworten
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 [2]. 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)Beantworten
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)Beantworten
Und OpenSSL ist in C programmiert!--Bautsch (Diskussion) 11:52, 10. Apr. 2014 (CEST)Beantworten
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)Beantworten

Die Medien sprechen von der grössten Sicherheitslücke seit Beginn der Zeitrechnung (oder so): Dürfte damit nicht etwas mehr zu diesem Bug stehen? Würde das nicht gar ein eigenes Lemma rechtfertigen? Danke. 92.106.151.60 11:35, 10. Apr. 2014 (CEST)Beantworten

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

Heise erklärt hier [3], wie der Bug funktioniert. Dabei stelltsich mir die Frage: Wie kommt man auf die Idee, mit einem Verschlüsselungsprotokoll bis zu 64kByte beliebiger, sinnloser Daten durch die Welt zu schicken? Wieso frei wählbare Länge? Für ein keep-alive-Paket? Eine 64 Bit lange Zufallszahl wär irgendwie logischer, denk ich. Man könnte ja echt auf Verschwörungstheorien verfallen. --88.66.43.132 00:26, 11. Apr. 2014 (CEST)Beantworten

Die Frage hat jemand auf der entsprechenden IETF Mailing-Liste gestellt [4] und von einem der RFC-Autoren eine Antwort erhalten [5]. 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)Beantworten
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)Beantworten

Versionsgeschichte Bearbeiten

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

Lieber ausblenden (also einklappen) statt auslagern. --Matthäus Wander 01:59, 11. Apr. 2014 (CEST)Beantworten
Ne Ahnung wie das geht? Ich find unter einklappen und ausblenden nix. --129.13.72.198 06:27, 11. Apr. 2014 (CEST)Beantworten
Vielleicht hilft diese Seite weiter: Hilfe:Tabellen#mw-collapsible. --Matthäus Wander 01:03, 12. Apr. 2014 (CEST)Beantworten

Genauer Hergang beim Heartbleed-Bug Bearbeiten

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

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

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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
Dann nehmt die Diss. komplett raus. Alexpl (Diskussion) 16:54, 12. Apr. 2014 (CEST)Beantworten
ist erledigt. --Mario d 19:04, 12. Apr. 2014 (CEST)Beantworten

Nachdem ich nun eine Weile nicht in den Artikel hineingesehen habe, finde ich es erschreckend, wie einige Mitautoren, im offensichtlichen Bestreben, den Vorfall herunterzuspielen, und dessen Verursacher in Schutz zu nehmen, nicht einmal davor zurückschrecken, frei erfundene Sachverhalte in den Artikel einzubauen. Die Fehlinformation, der Fehler sei beim "beim Ausbessern und Erweitern von OpenSSL" eingestellt worden, muss auf jeden Fall erst mal raus! --HV ([[Benutzer Diskussion:::::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) HV|Diskussion]]) 08:42, 13. Apr. 2014 (CEST)Beantworten

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

Heartbleed - eigenständiger Artikel Bearbeiten

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?

--Slick (Diskussion) 09:59, 13. Apr. 2014 (CEST)Beantworten

Sehr gute Idee. Fehler gefixt. --HV (Diskussion) 10:25, 13. Apr. 2014 (CEST)Beantworten

kritik am OpenSSL-team Bearbeiten

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

Theo de Raadt ist nicht irgendwelche Kritik und sein inhaltlicher Hinweis ist substantiell. --HV (Diskussion) 10:26, 13. Apr. 2014 (CEST)Beantworten
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)Beantworten
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)Beantworten

fortsetzung auf Diskussion:Heartbleed#kritik am OpenSSL-team. --Mario d 13:06, 13. Apr. 2014 (CEST)Beantworten

Fork zu LibreSSL Bearbeiten

OpenSSL wurd zu LibreSSL geforkt, siehe auch [6], [7] und [8]. --92.231.86.212 18:13, 23. Apr. 2014 (CEST)Beantworten

Im April 2016 veröffentlichte Sicherheitslücken Bearbeiten

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