Heartbleed - OpenSSL-Schwäche: Lücken bei heimischen Banken, Ministerien und Medien

Impressum | Werbung

Geizhals » Forum » Security & Viren »

Heartbleed - OpenSSL-Schwäche: Lücken bei heimischen Banken, Ministerien und Medien (140 Beiträge, 2246 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Und jetzt das ganze noch in Verbindung mit Windows XP, welches weiterhin von vielen Banken verwendet wird. Herrlich

Man möchte es hoffen; beim ein oder anderen Bankomaten wird sich jedoch scheinbar nichts ändern >> http://derstandard.at/1395364605581/XP-bleibt-in-Oesterreich-bei-Geldausgabeautomaten-im-Einsatz

Pruhahahah!

Was glaubst du, wievielen Kunden wir derzeit XP Ablöseprojekte anbieten (müssen).

Gerade jene, welche teilweise hohe Securityanforderungen haben, stecken im XP fest, weil sie sehr viel darum herumgebastelt haben, das sie auf Win7 oder 8 küblieren müssen.

Bezüglich Server hast du natürlich recht.

mfg lukas

1.) Glaube ich nicht, dass -irgendwer- noch XP verwendet, der auch nur einen
Grundbedarf an Sicherheit hat...

Der Prozentsatz von XP in der Industrie ist noch gewaltig. Gut, die Rechner sind normal nicht nach außen sichtbar, aber XP ist da noch extrem verbreitet. Da sind eher die Privatnutzer die Vorreiter

Was sollte Windows XP damit zu tun haben??? Die allerwenigsten (Apache) Webserver laufen wohl auf XP!

Und in einem wirklich gesicherten Unternehmens-Netzwerk kannst auch relativ unproblematisch Windows XP weiterverwenden, da die Clients hier durch andere Methoden geschützt werden!

Was sollte Windows XP damit zu tun haben??? Die allerwenigsten (Apache)
Webserver laufen wohl auf XP!

das passiert wenn leute mit wenig IT wissen, den Standard lesen:
http://derstandard.at/1395364697818/Tausende-Webserver-laufen-mit-Windows-XP-auch-in-Oesterreich

Auf einer interaktiven Grafik wird die Verbreitung von XP-basierten Webservern gezeigt. So gibt es in Österreich demnach noch 39 Seiten, die auf Servern mit dem veralteten Betriebssystem gehostet werden.

mir wäre auch noch nie ein XP Server untergekommen.

Auf einer interaktiven Grafik wird die Verbreitung von XP-basierten Webservern
gezeigt. So gibt es in Österreich demnach noch 39 Seiten, die auf Servern mit
dem veralteten Betriebssystem gehostet werden.

Vielleicht geben sie sich auch nur als Windows XP aus!? Egal, mir kommt auch nie ein XP Webserver utner!

FYI: http://www.pctipp.ch/tipps-tricks/kummerkasten/windows-xp/artikel/windows-xp-als-server-einsetzen-56831/ ^^
_______________________________________________________________________________________
"Freude ist Übung - Trauer kommt von allein" ÷ ÷ ÷ Treffpunkt für platonische Leute

GH ist seit gestern knapp vor 11 Uhr Ortszeit nicht mehr vulnerable. Den Tausch unserer Zertifikate muessen wir erst aufgleisen.

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

vor was genau sollten sie DICH warnen?

Das es den Bug gibt, ging gestern durch ALLE Medien und wird hoffentlich jeder vollmündige Bürger der einen Internetanschluss hat, mitbekommen haben.

Deine Betreffzeile klingt auch nach Boulevardmedien.
Warum sollte es Banken nicht treffen?
Verstehst Du überhaupt woher der Bug kommt und was der macht?

ich piss hier niemanden an.
aber das ist so ein typischer "klick-geil" titel - der standard macht das wegen den werbeeinnahmen - hier ist es allerdings unnötig.

Die Gschicht ist wichtig - drum ging sie durch VIELE Medien.

ja für webserver betreiber - für dich als 0815 internet user nicht so.
und wenn ein admin erst im ghf davon erfährt, sollte man ihm dringend alle zugriffe wegnehmen.

Ja schon. Und selbst? Ausser Leute anpissen bringst ja wenig zurande,
scheints...

du machst genau das gleiche, so what?
woher willst gerade DU wissen was ICH zustande bringe?
ich verwalte selbst mehrere server die ich gestern vormittag schon upgedated habe.
in kürze kommen neue zertifikate und gut ists.

dann klick nicht drauf und verpiss Dich zur Abwechslung mal selbst.

der einzige der permanent beleidigen ist, bist du.

Ja klar. Weil man vor -jedem- Aufruf von GHF mal unbedingt auf heise, ...
nachsehen soll, ob es nicht eine wichtige Info wo gibt.

äh ja. als sysadmin ist das deine pflicht.
aber davon hast du ja wenig ahnung.

Nach deinen qualifikationsbefreiten Postings habe ich eine ungefähre Ahnung.

ich kenne auch viele deiner postings und weiß dass du scheinbar niemanden hast zum reden weil du jedes thema hier tagelang diskutieren musst.

Du hast also nix fertig... Dachte ich mir.

meine server sind auch nicht so wichtig.
hättest du halbwegs eine ahnung, wüsstest du dass das nicht instant geht.

Eine Frage an dich, da du dich auszukennen scheinst

Was zeigt mir an, dass das Zertifikat getauscht wurde?
Kann ich das davon ablesen ab wann ein Zertifikat gültig ist?

Nein, da zumindest aufgrund der Heartbleed-Auswirkungen (von der CA gratis neu signierte) rotierte Zertifikate sich vermutlich nur im Public Key-Teil des Certs unterscheiden, und die anderen X.509-Metadaten (Common Name, Valid From/Thru, etc.) 1:1 uebernommen werden. Schaetze ich. Die CAs "verschenken" sicher kein Renewal nach Ablauf der initial gekauten Gueltigkeit.

Ohne Certificate Pinning im User Agent oder einer anderen Datenquelle, die eine Historie der verwendeten Zertifikate fuer den Server aufschluesselt, kannst du das nicht sicher sagen.

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

das geht aber schon noch besser.

https://www.ssllabs.com/ssltest/analyze.html?d=forum.geizhals.at

warum kein FS oder PFS im einsatz? ssl 3.0 kann man eigentlich auch gleich mal kübeln.

Danke fuer deinen gut gemeinten Ratschlag (auch wenn ich persoenlich mit der Formulierung nicht ganz gluecklich bin), aber dafuer gibt es technische Gruende, die nicht so trivial zu beheben sind wie du vielleicht annehmen moechtest. Es ist ja nicht so, dass wir - unter leicht anderen Voraussetzungen - nicht besser koennen: https://www.ssllabs.com/ssltest/analyze.html?d=service.geizhals.at

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

Habe unsere Server schon mit der neuen OpenSSL Version upgedatet. Neuen Key erstellt, Zertifikat-Neuausstellung ist bei unseren zum Glück kostenlos möglich!

Puhh, aber den Stress brauch ich so schnell nicht mehr. War kein schöner Anblick, wie ich unsere Server geprüft habe!

Und jetzt sollten nur noch alle deine User ihre Passwörter ändern, da verschlüsselt übertragene Loginversuche im Nachhinein von der NSA entschlüsselt werden können.

Google-Suchergebnisse, nur mit Privatsphäre? startpage.com!

Once you allow the government to start breaking the law, no matter how seemingly justifiable the reason, you relinquish the contract between you and the government which establishes that the government works for and obeys you, the citizen—the employer—the master. And once the government starts operating outside the law, answerable to no one but itself, there’s no way to rein it back in, short of revolution. -- John W. Whitehead

Zwangsbejagung Ade!

Das ist uns schon klar. Nur machen werdens die wenigsten. Zwangs-Passwortreset wollen wir keinen machen! Sie wurden aber schon informiert und darauf hingewiesen. Dann nehmens statt 123456 halt 654321

und wenn mastercard oder visa seriös wären, würden sie all ihren kunden neuen kreditkarten ausstellen

kann ich mir über den Browser eigentlich irgendwie anzeigen lassen welche OpenSSL-Version ein Server verwendet?

kann ich mir über den Browser eigentlich irgendwie anzeigen lassen welche
OpenSSL-Version ein Server verwendet?

Das erste, das man nach der Installation eines Webservers macht ist, das Anzeigen sämtlicher Versionsstände zu deaktivieren! Egal ob Webserver, Datenbankversion, Scriptsprachen, CMS,....

Wenn ein Angreifer diese Informationen nämlich schon frei Haus geliefert bekommen würde, hätte er es nochmals um einiges leichter!

Daher, um deine Frage zu beantworten, nein! Mir wäre auch kein Weg bekannt, die OpenSSL Version einfach so auszugeben, habe mich damit aber auch nie intensiv beschäftigt

Ich hab schon etwas gefunden:

https://www.ssllabs.com/ssltest/

über den Browser direkt scheint die Prüfung nicht möglich zu sein

09.04.2014, 14:04 Uhr - Editiert von Ovaron, alte Version: hier

Das tool kenne ich, das teilt dir aber nicht mit, mit welcher OpenSSL Version der Key erstellt wurde! Es simuliert nur einen Handshake mit ein paar OpenSSL Versionen, thats it!

Ok, so genau habe ich es mir nicht angesehen.

Ich hab mich aber schlecht ausgedrückt - mit dem Tool kann man prüfen ob ein Server noch von der Schwachstelle betroffen ist.

Ich hab mich aber schlecht ausgedrückt - mit dem Tool kann man prüfen ob ein
Server noch von der Schwachstelle betroffen ist.

Aso ja, das stimmt. Mit diesem Tool kann man u.a. das feststellen!

über den Browser nicht, aber am Server direkt schon mit:

openssl version -a

I. A. teilt ein TLS-Server nicht mit, welche Implementation und in welcher Version diese gerade TLS mit dir aushandelt und umsetzt. Was du aber sehr wohl am Client feststellen kannst ist, welche Version des SSL/TLS-Protokolls zur Abwicklung der Kommunikation eingesetzt wird.

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

der einfachste weg ist zur zeit die pyton implementierung des exploits auszuprobieren um festzustellen ob ein server die lücke hat oder nicht.

Ergänzung: Dinge, die https brauchen (Webbanking, ...) würde ich mal meiden,
bis es die Bestätigung der jeweiligen Firma gibt, dass der Bug behoben ist...

Warum? Auf meinem Client hab ich die aktuelle OpenSSL Version die nicht vom Bug betroffen ist. Ob die Bank davon betroffen ist oder nicht ist mir relativ wurscht, die Haftung dafuer liegt schliesslich bei der Bank, und nicht bei mir.

die Haftung dafuer liegt schliesslich bei der Bank, und nicht bei mir.

Trotzdem hast DU die Probleme, wenn auf einmal Geld auf deinem Konto fehlt. Dann darfst du erst mal von Pontius zu Pilatus laufen bis du es irgendwann hoffentlich wieder hast.

Trotzdem hast DU die Probleme, wenn auf einmal Geld auf deinem Konto fehlt.

Hat heutzutage nicht jeder außer ein paar Paranoiden Code per SMS Bestätigung?

test

Wenn du ein Android Handy hast, gibt es die Möglichkeit, dass die Betrüger die TAN SMS einfach an sich weiterleiten.

Deine Telefonnummer haben sie entweder durch den Heartbleed Bug oder durch das Einloggen ins Netbanking. Dann brauchen sie nur noch einen Exploit in Android, über den sie dich infizieren. Bspw. mit einer manipulierten SMS, über einen Fehler in WhatsApp oder sonstigen Programmen, die mit deiner Telefonnummer verknüpft sind.

Dass es irgendwo noch Zero Day Exploits gibt, sollte man gerade bei Android nicht ausschließen. Immerhin ist es ein populäres System, dessen Quellcode offen liegt und für das es jetzt schon die meisten Viren im Vergleich zu anderen Plattformen gibt. Außerdem sind noch haufenweise uralte (und damit verwundbare) Android Versionen im Einsatz, weil es einfach kaum Hersteller-Updates gibt.

Dazu kommt, dass die Betrüger wahrscheinlich auch deine E-Mail Adresse haben, wenn sie sich bei deiner Bank einloggen können. Wenn du die Mails auch mit dem Handy abrufst, können sie dich auch darüber infizieren.

edit: noch eine Idee: Wenn sie deine E-Mail Adresse haben, können sie auch deinen PC infizieren. Dann müssen sie nur noch deinen Browser entführen und bei deiner nächsten Überweisung gaukeln sie dir vor alles wäre normal, obwohl du ihnen in Wirklichkeit dein ganzes Geld überweist.

12.04.2014, 20:32 Uhr - Editiert von kaufinator1, alte Version: hier

Eher trifft einen ein Ziegelstein am Kopf weil ein Dach von einem Blitz getroffen wurde und ein Auftragsmörder einen Richtung Ziegelstein geschubst hat.

test

Sehe ich überhaupt nicht so. Man kann diesen Angriff super automatisieren und wenn er nur bei 10% der "Zielgruppe" erfolgreich ist, hat es sich schon ausgezahlt.

3 mal falsches Passwort eingeben, dann ist der Online-Zugang verschlossen. Dann kann auch kein Betrüger mehr rein.
Man kann alles genauso gut in einer Filiale erledigen. Ging früher auch problemlos.

Durch den Heartbleed bug haben die ja das richtige passwort. Da müssen die nichts mehr probieren. Und im Unterschied zu betrügereien in einer Filiale können die Gauner hier auch am anderen Ende der Welt sitzen, in einem Land ohne Auslieferungsabkommen mit Österreich.

Der Wiener Linien Onlineshop hat sogar sicherheitshalber die Passwörter aller Benutzer zurückgesetzt.

..und noch

sicherheitshalber

die Fahrkartenpreise erhöht

#--
Hail Freedonia.

du hexe http://wien.orf.at/news/stories/2642593/

Ja, da bin ich im Morgenverkehr draufgekommen!

test

Ich mache ja ungern Werbung für kommerzielle Angebot, speziell für eben diese Firma, aber bei unseren Symantec Zertifikaten (die schweineteuer sind) hat das zurückziehen und neuausstellen der Zertifikate keine 2 Minuten gedauert. Und das obwohl die Webseite teilweise heillos überlastet war. Dennoch, gerade in solchen Situationen weiß man als Firma so etwas sehr, sehr zu schätzen!

*zurücklehn*

unsere Produktivsysteme hatten nopch 0.9.8h oder so... danke IBM!

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

This server is not vulnerable to the Heartbleed attack. (Experimental)
This server's certificate is not trusted. Grade set to F.
The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers. MORE INFO »

Da das nur bei 1.0.1 auftritt und wir eben noch 0.9.8h(?) haben haben wir mit dem kein Problem

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Dann passt ja wirklich!

Der Fehler war ja in einer Heartbeatfunktion, die, soviel mir bekannt ist, ja dafür sorgt das bei Verbindungen die Paketverluste haben nicht sofort die Verbindung trennen, diese Funktion fehlt ja unter 0.9.8 noch.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Wo waren sie denn jetzt? Ich meine die vielen Programmierer, die sich Open Source Programme ansehen und auf Sicherheit überprüfen! Eingesetzt wird OpenSSL ja sehr oft, an mangelndem Interesse an der Software kann es also nicht liegen.

Dass Open source aufgrund der Quelloffenheit sicherer ist, ist einfach ein Blödsinn und das wird immer klarer. Die einzigen, die sich für solche Bugs interessieren sind die Kriminellen, weil die damit Geld "verdienen" können. So dürften das auch die Ersten gewesen sein, die die Lücke entdeckt haben (siehe entsprechende Heise Artikel).

Eben grad das es OSS ist wurde der Bug entdeckt... Auch - dank der offenen Struktur - hat die Verteilung der gefixten Version weniger als 12 Stunden gedauert. Da kann nedmal IBM mithalten (die auch sehr flott beim fixen sind).

Da aber Closed Source Bugs meistens still im Kämmerchen gefixed werden, ist dein Posting eh reines Bashin da Du keinen Beweis antreten kannst das zeigt das Closed Source schneller ist beim beheben von Vulnerabilities.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

das kann man jetzt sehen wie man will. klar wurde das schnell gefixed, aber:

dank open source konnte die lücke jeder finden, teilweise ist dank open source das suchen nach potentiellen lücken einfacher als bei closed source. einer hat sich halt gefunden, der das gemeldet hat, wieviele aber geschwiegen haben und es effektiv ausgenutzt haben, weiss keiner.

ich sehe da jetzt weder einen vorteil oder einen nachteil von closed source. mir ist es eigentlich *PIEP*gal ob open oder closed source. die software soll funktionieren und möglichst bugfrei sein. leider ist das bei openssl halt nicht so der fall. ist ja nicht die erste katastrophe, die da fabriziert wird.

wenn man dann auch noch liest, dass openssl bspw. gezielt die sicherheitsmaßnahmen von openbsd ausser kraft setzt, weil ihnen halt die plattform nicht gut genug performed, dann fragt man sich schon, ob man dieses stück software überhaupt noch einsetzen sollte und nicht doch auf einen anderen ssl stack setzen sollte.

sendmail hatte ja vor jahren ein ähnliches schicksal erlebt, da wurde auch eine nach der anderen katastrophen bekannt. naja und jetzt setzt halt jeder der halbwegs klar im kopf ist nimmer sendmail ein sondern postfix und die erlebnisorientierteren setzen halt noch auf qmail, aber ich glaub das nimmt auch mehr und mehr ab, denn DJB ist ja das lebende beispiel warum es nicht funktioniert.

ob man dieses stück software überhaupt noch einsetzen sollte und nicht doch
auf einen anderen ssl stack setzen sollte.

ok welchen ? Würde mich jetzt als Techniker sehr interessieren.

sendmail

M4 ist auch widerlich..

das kann man jetzt sehen wie man will.

Bingo!

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

ok welchen ? Würde mich jetzt als Techniker sehr interessieren.

da bin sind wir in der firma grad am umschauen. es stösst nämlich schon auf, was openssl so fabriziert in letzter zeit.

da bin sind wir in der firma grad am umschauen. es stösst nämlich schon auf,
was openssl so fabriziert in letzter zeit.

Na bin gespannt ob ihr da was findets das den gleichen Funktionsumfang hat wie OpenSSL, bzw. auch Support von den Endprodukten - da haperts nämlich bei den prop. Lösungen gewaltig.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Recht viele werden [4] oder [5] wählen - und das "OSS ermöglicht schnelle Fixes"-Theorem kränkelt a bissale im Realitätscheck.

nur ein beispiel:

http://bugs.centos.org/view.php?id=7048

beschrieben auch unter

https://bugzilla.redhat.com/show_bug.cgi?id=1068862

ist bis heute nicht im RHEL 6 gefixed bzw. ausgeliefert worden, so auch nicht in CentOS. wir haben das bei uns jetzt mal händisch gefixed. aber man sollte denken, das man so eine kleinigkeit, die man im übrigen selbst mit einem der letzten kernel updates verbockt hat binnen weniger stunden oder tage ausgerollt bekommt.

oder ist das jetzt eine kleinigkeit, wenn man keine cifs shares mehr mounten kann?

insofern schnelle fixes sind nicht immer ein argument bei OSS wie hier bspw. eindrucksvoll bewiesen wird.

Wir wissen nicht, wieviele den Bug schon entdeckt hatten... Und wie Du richtig
sagst, OSS hilft beim Finden von Bugs .

Du weißt auch nicht wieviele Bugs schon in Closed Source entdeckt wurden.. eben wir wissen es nicht

Das weiß auch kaufinator ned...

und das "OSS ermöglicht schnelle Fixes"-Theorem kränkelt a bissale im
Realitätscheck.

hier sind wir wieder bei etwas was ich schon vorhin meinte: Beweis es (was Dir nicht gelingen wird, weil Du eben die entdeckung der Closed Source bugs nicht kennst). die Verteilzeit (Repostiory => Clients) ist unter OpenSource auf jeden Fall schneller, da gibts keine Patchdienstage etc, da wird das verteilt.

Die Cambridge Uni hat vor 3-4 Jahren das auch mal getestet und kam zu dem Schluß das beide Modelle kaum Abweichungen bei der Patchzeit haben, jedoch bei der Verteilzeit die offene Software um längen gewann (wenn ichs find post ichs hier..)

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Du ich kann Dir da nur recht geben, wir werden immer weniger- bzw. gröbere Schnitzer in Software finden, leider eben auch in so oft genutzter Software wie SSL oder sonstig grundlegendes (libc ?).

"release fast, release often".

Was ich persönlich für vernünftig halte da nach dem Leitsatz "Errare Humanum Est" jegliches menschliches Produkt Fehler enthält - auch Software. Die Frage ist nur wie schnell ist es gefixt bzw. wie schnell ist der Patch/Neue Release beim Kunden und da halte ich das sofortige Ausrollen (IBM hat heute z.B. für AIX bereits den Patch released) vernünftiger als auf fixe Patchtage zu pochen.

Wozu braucht man -echt- eine variabel große Payload für ein keepalive?

Fürs Keepalive ned so direkt, eher für das Certifikat (soviel ich verstanden hab) das eintrudelt.

Da hast das gleiche Problem wie bei Android und den Tel-Herstellern: Manche
reagieren flott, manche unendlich langsam, manche sitzen es aus.

Anhand solcher Kriterien entscheide ich was es bei mir wird - HTC z.B. kommt mir nimmer ins Haus

wer SELinux entwickelte...

Gut da glaub ich nicht so an Backdoors, nur weil MS z.B. manche virtualisierungen im Linuxkernel mitentwickelt hat, würden die auch keine anderen aussperren. Aber ich kanns natürlich alleine nicht beweisen

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Eben grad das es OSS ist wurde der Bug entdeckt.

Es hat 2 Jahre gedauert bis der Bug entdeckt wurde. "Schnell" ist anders.

Es hat 2 Jahre gedauert bis der Bug entdeckt wurde. "Schnell" ist anders.

Gegenbeweis das es schneller mit Closed Source ging ? Ansonsten ist es schnell..das ist eine millionenzeilen schwere Software ..

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Gegenbeweis das es schneller mit Closed Source ging ?

Das Argument hat sich also von "OpenSource ist sicherer" zu "man kann nicht beweisen, dass OpenSource nicht sicherer ist" gewandelt. Ich denke das spricht für sich selbst.

"man kann nicht beweisen, dass OpenSource nicht sicherer ist"

Steht genau wo ?

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Na du bittest jeden dauernd zu beweisen, dass Closed Source sicherer ist, anstatt selbst zu beweisen dass Open Source sicherer ist, so wie es immer wieder von den OSS Befürwortern behauptet wird.

Das ist ein Argumentationswechsel von "OSS ist sicher by design" zu "man kann nicht beweisen dass Open Source schlechter ist". Wenn du das nicht erkennst, kann ich dir auch nicht helfen.

Du spinnst Dir da was zusammen, kleines Pipi Langstrumpf.

Ich hab nur gesagt das der Patchvorgang schneller ist als unter properitären Systemen. (bei dem SSL Bug wurde der Bug bei offenen Systemen schneller gefixt als z.B. durch IBM nur so btw.).

Es gibt 3 Komponenten bei der Sicherheit:

- die bei Release vorhandenen Bugs
- die Dauer (über die sprechen wir falls Dir das seit mehreren Postings nicht geläufig ist) die die Entwickler benötigen um die Bugs zu fixen
- und ganz ganz wichtig die Verteilung der Patches zum Endkunden.

Ich kann Dir dazu die Lektüre der Uni-Regensburg empfehlen die diese drei Vorgänge untersucht haben - bei populären Produkten - MS Office vs. OpenOffice und da kam MS garnicht gut weg, da da auch die Patchvorgänge im schlimmsten Fall (rein die Auslieferung) um einiges länger gedauert hat als bei offenen Produkten.

kann ich dir auch nicht helfen.

Das kannst DU eh in keinem Fall.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Ich kann Dir dazu die Lektüre der Uni-Regensburg empfehlen die diese drei Vorgänge untersucht

Achso, weil diese Studie zufällig deine Meinung bestätigt, ist sie also eine gute Argumentationsgrundlage. Ich dachte, Studien soll man nur glauben, wenn man sie selbst gefälscht oder finanziert hat... Naja, man dreht sichs halt wie mans braucht, gell?

Es gibt 3 Komponenten bei der Sicherheit:

Und wo ist die vierte Komponente? Nämlich: Wie lange es dauert bis Bugs entdeckt werden? Darüber spreche ich nämlich die ganze Zeit, falls dir das nicht aufgefallen ist. Weil Open Source eben offen ist, könnte man meinen, dass Bugs besonders schnell gefunden werden. Weil angeblich so viele selbstlose(?) Programmierer den Code gratis untersuchen!

Aber genau das ist eben nicht der Fall. Kein Mensch schaut sich den Code (mit guten Absichten) an, weil er so umfangreich ist. Die einzigen, die wirklich genau hin schauen und jedes Update untersuchen, sind die Kriminellen und die NSA. Und die haben es bei OSS besonders leicht. Da muss die NSA nicht mal einen "National Security Letter" schreiben und die Kriminellen müssen nirgendwo einbrechen oder Fuzz tests durchführen, weil der Code und die Bugs für Jedermann im Internet einsehbar sind.

Ob die Lücke jetzt in ein paar Tagen oder ein paar Wochen gefixt ist, macht daher keinen Unterschied, wenn sie davor 2 Jahre lang offen ist. Aber das ignorierst du natürlich weil "man nicht beweisen kann, dass die Bugs bei Closed Source schneller entdeckt werden". Wenn du vernünftig wärst, würdest du erkennen, dass das auch völlig egal ist, weil die NSA und die Kriminellen die Lücken in Closed Source nicht vom ersten Tag an entdecken können!

Wenn du also schon eine Studie zitieren willst, dann bitte eine Studie die untersucht, wie lange eine Lücke tatsächlich offen ist. Und nicht eine Studie, die sich willkürlich irgendeinen Zeitpunkt heraus pickt und dann misst, wie lange die Reaktionszeit ist. Das ist nämlich absoluter Schwachsinn. Wann soll dieser Zeitpunkt bei OpenSSL denn gewesen sein? Als die NSA den Bug zum ersten mal ausgenutzt hat? Als der erste Kriminelle den Bug zum ersten mal ausgenutzt hat? Oder als die ersten Medien darüber berichtet haben?

Aber genau das ist eben nicht der Fall.

Hast dazu auch nur IRGENDEINE bestätige Studie/Untersuchung etc. oder fallt Dir das so ein ?

Lücke tatsächlich offen ist

Total irrelevant. Errare humanum est, jede Software ist fehlerhaft.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Hast dazu auch nur IRGENDEINE bestätige Studie/Untersuchung etc. oder fallt
Dir das so ein ?

Das ergibt sich aus der Tatsache, dass bei einer der am meisten genutzten Open Source Software (OpenSSL) ein solcher Fehler 2 Jahre lang nicht entdeckt wurde.

Total irrelevant. Errare humanum est, jede Software ist fehlerhaft.

Bei Open Source sind die Fehler für jedermann einsehbar im Netz. Bei Closed Source nicht. Das macht es den "bösen" schwerer. Es ist daher nicht irrelevant.

Das ergibt sich aus der Tatsache,

Also nein, ist ergo nur rein Deine meinung.

Bei Closed Source nicht.

Also du weißt garnicht wieviele schwerwiegende Lücken JAHRELANG(!!) bereits offen sind und wie die schon aktiv ausgenutzt werden...

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

ist ergo nur rein Deine meinung.

Es ist eine Schlussfolgerung, wenn du schon Haare spalten willst.

Also du weißt garnicht wieviele schwerwiegende Lücken JAHRELANG(!!) bereits
offen sind und wie die schon aktiv ausgenutzt werden...

Du weißt es auch nicht. Und jetzt?

Es ist eine Schlussfolgerung, wenn du schon Haare spalten willst.

Nein ist es nicht, eine Schlußfolgerung basiert auf anerkannten Tatsachen, Du mutmaßt aufgrund Deiner Meinung.

Und jetzt?

Deshalb ist Dein Closed Vs. Open Source vergliech auch dämlich, weil Du eben bei Closed Source nicht weißt wann was wie gefixed wird.

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Dass Open source aufgrund der Quelloffenheit sicherer ist, ist einfach ein
Blödsinn und das wird immer klarer.

das war mir eigentlich schon immer klar. der einzige vorteil von OS ist eigentlich auch gleich der grösste nachteil. man hat die source und sieht was verbrochen wurde, wenn ich nun nicht selbst das fixen kann oder kriminell veranlagt bin halt ich brav die fresse und schau mal was so geht.

bei closed source musst erstmal so an bug auf die schnelle finden. klar, dass die bei OS mal etwas vielleicht schneller fixen. das war es dann aber auch schon mit der herrlichkeit.

Das beste war ja das hier:

http://article.gmane.org/gmane.os.openbsd.misc/211963

bzw. http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

11.04.2014, 13:19 Uhr - Editiert von mjy@geizhals.at, alte Version: hier

So in der Art war auch mein erster Kommentar als das Problem bekannt wurde. In der Praxis ist der Umstand dass sich jeder den Code ansehen könnte wertlos und nicht mehr als ein Fanboy-Argument im Konjunktiv, da man das bei so komplexen Projekten schon alleine aufgrund der schieren Menge an Sourcecode eben nicht mehr so einfach Problemstellen erkennt selbst wenn sie so trivial sind.

Karawanken

Bär

Is OpenSSL so zu verstehen wie MySQL? Also: Es gibt auch was gscheiteres, aber kostenpflichtig?

Würds als frechheit empfinden, wenn meine Bank (Volksbank) ein Opensource Produkt für meine Sicherheit verwenden würde.
--------------------------------------------------------------------------------
Geh mit deinen problemen aufs Salzamt

Gibt nix gescheiteres. Das Problem ist der Standard - TLS hat schon so viele (tw. selten genutzte) Features und Optionen, dass es kaum fehlerfrei implementiert werden kann (bzw. nie werden wird).

naja, nix gescheiters, viele sind verschont weil sie auf den loadbalancern mit hardware modulen ssl terminieren.
deswegen wundert es mich das so viele große institute betroffen sind, da die terminierung am webserver resourcenmässig eigentlich recht teuer ist.

12.04.2014, 17:57 Uhr - Editiert von *patrick star*, alte Version: hier

weil sie auf den loadbalancern mit hardware modulen ssl terminieren.

Und weil da ein 10 Jahre altes OpenSSL drauf ist?

Die keys sind auf diesen load balancern jedenfalls möglicherweise auch komprimittiert.

bei denen die ich kenne, wird openssl nur verwendet wenn man cipher verwendet die hardwaremässig nicht abgebildet sind.

bei denen die ich kenne, wird openssl nur verwendet wenn man cipher verwendet
die hardwaremässig nicht abgebildet sind.

Welche wären das z.B.?

Typische aktuelle "hardware load-balancer" sind eigentlich auch nur Linux- oder BSD-Kisten. Wir haben hier noch ziemlich alte Foundry ServerIron herumliegen. Ich glaube, die hatten auch irgendein BSD.

f5 z.b.

Content is not served up using OpenSSL unless you are using something other then the Native/Default ciphers (compact cipher?) - otherwise it's offloaded to the Cavium accelerator card.

https://devcentral.f5.com/articles/openssl-heartbleed-cve-2014-0160#.U0luKuZ_tt0

die f5 war doch selbst im management teil bestimmter versionen betroffen. ausserdem wird es wohl kaum jeder eine f5 gönnen wollen.

erstens habe ich von großen instituten gesprochen und zweitens hab ich nicht gesagt das sie kein openssl verwenden sondern das z.b. bei f5 wenn die hardware accelerator verwendet werden man nicht betroffen ist. und da ssl terminierung bei viel traffic resourcenaufwendig ist, wundert es mich das so viele große institute das eben nicht über hardware accelerator machen.

weil die ein schweine geld kosten.

die bankaustria hat auch die f5 im einsatz. hat sie schlussendlich letzten jahres auch nicht vor dem hack geschützt. ist alles eine kosten/nutzen frage. gibt wohl kaum was, dass ich nicht mit opensource nachbilden könnte.

vor allem für den preis einer guten f5 bekommen grosskunden auch schon jedemenge an bladeblech + vmware + opensource. die garantie, dass du in der f5 nicht auch irgendwo an riesenbock drinnen hast, kann dir eh keiner geben.

die sicherheit hast du nie. in dem fall waren f5 kunden eben nicht betroffen. das heisst nicht das es morgen nicht in einem anderen fall anders ausschaut.

Genauer:

http://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html

Tatsächlich haben die neben einer OpenSSL 0.9.7-Variante auch einen eigenen SSL-Stack. Hat jetzt aber nichts damit zu tun, ob das ein Hardware-Load Balancer ist oder nicht. Der "Native Stack" ist ja auch nur Software (vielleicht ein älteres OpenSSL-Derivat oder eine der ca. 10 anderen herumgeisternden SSL-Stacks).

stimmt schon. auf was der selbstgeschriebene ssl-stack basiert der verwendet wird, weiss ich nicht. auf jeden fall wird eben dieser im zusammenspiel mit den accelerator karten verwendet und dadurch scheidet der heartbleed einmal aus.

hm was machst aber wenn der hardwarechip einen fehler hat? ist ja bei intel auch schon mal öfter vorgekommen. da bist dann ziemlich im eck mit einer hardwarelösung. klar man hart wartungsverträge und alles. im einsatz haben möcht ich derartige konstrukte aber nicht.

auf jeden fall wird eben dieser im zusammenspiel mit den accelerator karten
verwendet und dadurch scheidet der heartbleed einmal aus.

Wieso scheidet der deshalb aus? Die keys sind ja sicher auch irgendwo im Speicher, wie andere sensible Daten auch.

Hast du ein setup mit dem F5 als SSL-frontend mal mit dem Qualys-Check geprüft? Würde mich interessieren, wie der abschneidet.

http://toolbar.netcraft.com/site_report?url=https://online.bankaustria.at

https://www.ssllabs.com/ssltest/analyze.html?d=online.bankaustria.at&s=193.193.172.129

aber keine ahnung welche schweinereien die in italien da so laufen haben und anderweitig schon filtern.

lol. OpenSource ist für die Sicherheit sogar besser, weil Lücken schneller gefunden und wichtig schneller BEHOBEN werden. kann man gerade an diesem openssl bug sehr gut erkennen: irgendwann in der nacht wurde darüber berichtet und paar stunden später war der patch da.

man siehts ja gut an dem beispiel microsoft wie oft bugs gemeldet werden und microsoft absolut uninteressiert ist.

also BITTE bildet euch keine meinug über sachen von denen ihr keine ahnung habt.
danke.

Also: Es gibt auch was gscheiteres, aber kostenpflichtig?

Ja, zb der IIS von Microsoft verwendet für die Keyerstellung was eigenes. Die Frage ist halt, ob ein IIS wirklich mehr Sicherheit bietet, als ein Apache!

Würds als frechheit empfinden, wenn meine Bank (Volksbank) ein Opensource
Produkt für meine Sicherheit verwenden würde.

Frechheit³ Die sollen gefälligst alle Linux Derivate von sämtlichen Firewalls, Webservern, Routern, Switches schmeissen und closes source verwenden, kann ja nicht sein

Ich gehe ja eigentlich von einem eher uninspirierten Trollversuch aus, aber weil's so schoen ist...

Schon ein Mist, dieses von irgendwelchen Amateurfricklern voellig unkontrolliert zusammengeschusterte OpenSSL. Aber das hat man davon, wenn man nicht Enterprise-Qualitaet kauft, wie zum Beispiel der Weltmarktfuehrer in Sachen Netzwerktechnologie, Cisco, sie bietet, stimmt's?

The following Cisco products are affected by this vulnerability:

    Cisco AnyConnect Secure Mobility Client for iOS [CSCuo17488]
    Cisco Desktop Collaboration Experience DX650
    Cisco Unified 7800 series IP Phones
    Cisco Unified 8961 IP Phone
    Cisco Unified 9951 IP Phone
    Cisco Unified 9971 IP Phone
    Cisco TelePresence Video Communication Server (VCS) [CSCuo16472]
    Cisco IOS XE [CSCuo19730]
    Cisco Unified Communication Manager (UCM) 10.0
    Cisco Universal Small Cell 5000 Series running V3.4.2.x software
    Cisco Universal Small Cell 7000 Series running V3.4.2.x software
    Small Cell factory recovery root filesystem V2.99.4 or later
    Cisco MS200X Ethernet Access Switch
    Cisco Mobility Service Engine (MSE)
    Cisco TelePresence Conductor
    Cisco WebEx Meetings Server versions 2.x

Other Cisco products may be affected by this vulnerability. The list of affected products will be updated as the investigation continues.

... whoops!

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

war das nicht apple, die erst vor kurzem eindrucksvoll demonstriert haben wie man certificate chains wirklich prüft

ich weiss jetzt aber nicht was schlimmer ist. der goto fail von apple oder heartbleed

von der auswirkung sicher heartbleed. aber es zeigt das auch kaufsoftware von nahmhaften herstellern nicht unbedingt mehr sicherheit bedeutet.

das ist aber schon generell so. vor allem in zeiten von nsa, abhören, etc. wer sagt uns denn, dass heartbleed oder goto fail nicht gewollt waren?

insofern wenn man hier als unternehmen auf der sicheren seite sein will, kann man eh nur noch hergehen selbst eine menge an entwicklern einstellen, opensourcecode auditieren und selbst fixen was geht. ist halt immer wieder eine kostenfrage. in zeiten wie diesen bin ich echt gespannt, wann der letzte slipsträger kapiert, dass die IT + security im eigenen unternehmen um einiges wichtiger als bisher. und nicht jeder tu-student mal schnell einen exchange server oder ähnliches in 2 stunden hinzaubert.

insofern wenn man hier als unternehmen auf der sicheren seite sein will, kann
man eh nur noch hergehen selbst eine menge an entwicklern einstellen,
opensourcecode auditieren und selbst fixen was geht

Da musst du aber schon bei der Hardware verdammt aufpassen. Intels AMT ist schon mal eine backdoor (mit hoher Wahrscheinlichkeit), dann was auch immer in der Firmware der NICs so passiert ...

AMT hab ich so gut es ging vermieden in der vergangenheit. das ding ist mir suspekt. ist das nicht auch das, das remote wipe von harddisks etc. ermöglicht?

NICs sind natürlich ganz blöd und mittlerweile muss man dann ja auch auf sachen wie GPU aufpassen. verwendet ja auch schon mittlerweile jeder browser irgendwie.

mittlerweile muss man dann ja auch auf sachen wie GPU aufpassen. verwendet ja
auch schon mittlerweile jeder browser irgendwie.

ja, aber die hängen wenigstens nicht direkt am Netz ... Mit NIC + AMT kann man wohl den abedrehten (nicht abgesteckten) Rechner auch kompromittieren.

Ok ok, dann haben halt alle gepfuscht!
--------------------------------------------------------------------------------
Geh mit deinen problemen aufs Salzamt

Ganz im Gegenteil, gerade in der Kryptographie ist OpenSource das einzig ware.

Wie soll man sich denn davon überzeugen können das eine Verschlüsselung oder ein Verfahren entsprechend sicher ist, wenn man nicht im Detail weiß wie es funktioniert?

Es gibt sogar einen Begriff dafür: Security through obscurity

Es gibt sogar einen Begriff dafür: Security through obscurity

und diese hat sogar einen Namen: "Kryptochef"

13.04.2014, 06:32 Uhr - Editiert von user86060, alte Version: hier

gerade in der Kryptographie ist OpenSource das einzig ware.

Wie soll man sich denn davon überzeugen können das eine Verschlüsselung oder
ein Verfahren entsprechend sicher ist, wenn man nicht im Detail weiß wie es
funktioniert?

Ganz allgemein und theoretisch ist das sicher der bessere Ansatz. In der Praxis führt das aber erwiesenermaßen nicht konsistent zu besseren Produkten.

Was definitiv in jeder Situation ein Mehr an Sicherheit bringt, sind attraktive bounties für gefundene Schwachstellen. Man kann bounties für ein Produkt wie eine SSL-library durchaus als Qualitätsmerkmal betrachten. PolarSSL hat z.B. so ein Programm (https://polarssl.org/bug-bounty-program ), für OpenSSL gibt es eins von Google (https://www.google.com/about/appsecurity/patch-rewards/ ). Die bounties dürften aber noch zu niedrig sein um eine adäquate Schar von Security-Spezialisten gegen die eingeschleusten backdoors zu mobilisieren ...

Ist einleuchtend!
Werd ich mir merken.
--------------------------------------------------------------------------------
Geh mit deinen problemen aufs Salzamt

in der Kryptographie ist OpenSource das einzig ware.

Wie soll man sich denn davon überzeugen können das eine Verschlüsselung oder
ein Verfahren entsprechend sicher ist, wenn man nicht im Detail weiß wie es
funktioniert?

Hier klaffen Theorie und Praxis leider weit auseinander. Es kennt sich kaum jemand mit Kryptographie und Programmieren so gut aus, dass er die Sicherheit eines komplexen Programms beurteilen kann.

Die paar Leute, die das doch können, haben jetzt die Wahl ihre Dienste und ihre Zeit gratis zum Wohl der Gemeinschaft zur Verfügung zu stellen oder gegen Entgelt für Regierungen und Kriminelle zu arbeiten.

Der Gedanke hinter Open Source ist ja wirklich lobenswert, aber es funktioniert einfach nicht.

edit: Siehe auch hier: http://www.heise.de/newsticker/meldung/Nach-Heartbleed-OpenSSL-Projekt-bittet-um-Unterstuetzung-2169393.html
Die werden schon wissen warum sie um Geld bitten. Ich tippe mal darauf, weil ihnen die freiwilligen und kompetenten Helfer fehlen.

Es gibt sogar einen Begriff dafür: Security through obscurity

Ich würde sogar sagen: Security through obscurity is still security.
In der Finanzwelt machen viele Menschen sehr viel Geld mit Systemen die kein Mensch versteht. Warum soll dieses Konzept nicht auch die Sicherheit erhöhen?

Ich habe einfach was gegen das Wiederkäuen von Stehsätzen wie "Security through obscurity ist schlecht", die ihre angebliche Richtigkeit nur aus der Tatsache ableiten, dass sie sich toll anhören und oft verwendet werden. Ungefähr so wie: "wer zuerst kommt mahlt zuerst". Oder vielleicht doch: "Die Letzten werden die Ersten sein"?

14.04.2014, 18:52 Uhr - Editiert von kaufinator1, alte Version: hier

Der Gedanke hinter Open Source ist ja wirklich lobenswert, aber es
funktioniert einfach nicht.

Das Problem bei OpenSSL und Geld ist, dass die einfach nirgends wo ein Top-Level Projekt sind, was irgendwie eh komisch ist, da es doch soviele nutzen..

Wäre das ein Top Level Apache Projekt, dann müsste die sich keine Sorgen um Geld machen. Vor allem hat man jetzt gesehen, wer das eigentlich alles nutzt.. Da könnten paar Firmen schon paar € springen lassen um die SW zu verbessern.
Es muss ja kein Vermögen sein, aber großen Firmen sollten >1000€/Jahr nicht weh tun.. Und das würde ja nichtmal das Konzept von Open-Source "sprengen". Open Source hat ja DIREKT nichts mit Free-Source/Software zum tun.

Truecrypt ist das Beste Gegenbeispiel. Da hat man via KickStarter ein Projekt gemacht, welches TrueCrypt überprüfen soll ob eh kein Backdoor drinnen ist.
http://derstandard.at/1397520743417/Truecrypt-Codepruefung-findet-keine-Hintertueren-bei-Festplattenverschluesselung

Bei TrueCrypt kannst du also SICHER sein, dass die kein Backdoor haben. Bei Lösungen von Apple, MS, Google, etc. (egal ob die jetzt sowas anbieten oder nicht) kannst du es nicht wissen, weil die Closed-Source sind. Es könnte eines da sein, muss natürlich nicht..

Die Router-Backdoors was letztes Jahr publik gemacht wurden, waren ja auch sowas. Das war ja auch "Security through obscurity". Aber als es bekannt war, war das ganze ziemlich schlimm. Gleiches beim PS3 Hack wo die Zufallsnummer immer die selbe war..

Ich verstehe einfach deine negative Einstellung zu OpenSource nicht, vor allem da Apple ja auch genug davon nutzt (und es dann in was proprietäres verpackt).
Apple hatte ja nur Glück dass sie eine ewig Alte Version nutzen (so wie meine Router auch

).
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Mich stört an OSS einfach, dass es keine verbindlichen Regeln dafür gibt.
Es gibt keine verbindlichen Qualitätsstandards für die Programmierung (siehe die Kritik an der Kraut und Rüben Programmierung bei TrueCrypt), es gibt keine Updategarantie, es gibt keine Supportgarantie, es gibt keine Einheitliche Bedienung, es gibt nicht einmal ein einheitliches Konzept (siehe die unzähligen Distributionen).

Im Vergleich dazu bietet Apple alles oben erwähnte.

Ich weiss schon, dass das daran liegt, dass die Open Source Software gratis ist. Aber für mich überwiegt nicht dieser "Vorteil".

Dass Open Source auch kein Garant für Sicherheit ist, hat man bei OpenSSl gesehen. Was bleibt also noch, außer dass es nichts kostet?

Mich stört an OSS einfach, dass es keine verbindlichen Regeln dafür gibt.

Tjo, das hat man halt nur innerhalb eines Unternehmen, was meistens bei OSS ja nicht zutrifft..

es gibt keine Supportgarantie

Gerade so, verdienen viele Unternehmen mit OSS ja Geld. Support für OSS-Software.. (Red Hat, SUsE, etc).

Im Vergleich dazu bietet Apple alles oben erwähnte.

Siehe Punkt 1. Weil ALLES von EINEM Unternehmen mit RICHTLINIEN kommt. Und Apple hat da sicher etliche und strenge!

Das ganze hat aber so ziemlich gar nix mit Closed oder Open-Source zum tun. Apple beteiligt sich ja auch an OSS-Projekten.. Glaubst du dort wird deren Source nicht nach Apple-Richtlinien aussehen??
Oder glaubst du das Apache, Mozilla Source-Codes der Zustand sein werden?

Dass Open Source auch kein Garant für Sicherheit ist, hat man bei OpenSSl
gesehen.

Und deswegen ist Closed Source besser? Logik? Bei OSS könntest wenigstens noch den Source prüfen und eventuell selber ändern.
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Bei OSS könntest wenigstens noch
den Source prüfen und eventuell selber ändern.

Das ist eben nur ein theoretischer Vorteil. Wenn man Gewissheit über die Sicherheit haben will, müssen die meisten sowieso ein Code Review bezahlen (wie bei Truecrypt). Und das ist nach dem nächsten Update nicht mehr aktuell.

Ich habe weder die Zeit noch die Lust mir den Code von jedem Programm anzusehen, das ich verwende. Den meisten geht es ähnlich und die beschränken sich dann darauf, zu hoffen, dass die anderen die Fehler schon finden werden. Hier verlässt man sich dann wieder auf unbekannte Dritte. Unterschied zu Closed Source?

Das ist eben die Realität.

Das ist eben nur ein theoretischer Vorteil.

Und bei Closed Source kannst du gar nix -> somit ist es und bleibt es ein Vorteil. Nur weil du ihn nicht überprüfen kannst, heißt das nicht, dass der Vorteil nicht da ist oder nur in Theorie da ist ^^

Hier verlässt man sich dann wieder auf unbekannte Dritte. Unterschied zu
Closed Source?

Und Closed Source ist deswegen auotmatisch Fehlerfreier oder was? Hat man ja super beim Apple-Bug gesehen (goto fail) und bei den ganzen sonstigen Bugs was so ziemlich jede closed-Software auch hat (Windows, etc).

Closed Source oder Open Source sagt mal gar nix darüber aus, ob der Code weniger oder mehr Fehler hat. Das hängt noch immer vom Programmierer ab.. Zu Win XP Zeiten (und früher) gab es solche Fehler wie OpenSSL eigentlich überall, weil kaum jemand die "sicheren" Speicherfunktionen von C/C++ genutzt hat (bzw. es nichtmal überall eine gab).

Das ist eben die Realität.

Was? Das du OpenSource aus welchem Grund auch immer schlecht redest? So nebenbei setzen iOS und Mac OS auch auf Open-Source SW (BSD).

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Nur weil du ihn nicht überprüfen kannst, heißt das nicht, dass der Vorteil
nicht da ist oder nur in Theorie da ist ^^

Das hab ich auch nicht behauptet.

Und Closed Source ist deswegen auotmatisch Fehlerfreier oder was?

Das hab ich auch nicht gesagt.

Wenn du mir schon Worte in den Mund legen musst um deine Argumentation durch zu bringen, spricht das Bände.

Und bei Closed Source kannst du gar nix

Also die Jailbreaker finden immer wieder Sicherheitslücken im iPhone, die Apple dann schließt. Irgendwie muss es also doch möglich sein, Closed Source auf Fehler zu überprüfen. Und irgendwie kommt es mir fast so vor, als würde das bei closed source intensiver passieren, als bei open source. Denn das Jailbreak Team braucht nach jedem Update immer länger um wieder einen Fehler in Apples Sicherheitssystem zu finden.

Ich fühle mich daher mit meinem 5S und iOS 7.1 (für das es derzeit weder einen Jailbreak noch Viren gibt) relativ sicher. Ganz im Gegensatz zum "sicheren" Open Source Android.

Das hab ich auch nicht behauptet.

Aha, also wenn du schreibst: "Das ist nur ein theoretischer Vorteil", dann hast du das nicht behauptet? WTF?

Das hab ich auch nicht gesagt.

Wenn du mir schon Worte in den Mund legen musst um deine Argumentation durch
zu bringen, spricht das Bände.

Dann ersetz das Wort "Fehlerfreier" mit "sicherer" und lies dir DEINE Antworten hier im Thread durch.. Weißt du nicht mal mehr was du so schreibst?

Also die Jailbreaker finden immer wieder Sicherheitslücken im iPhone, die
Apple dann schließt. Irgendwie muss es also doch möglich sein, Closed Source
auf Fehler zu überprüfen.

Du hast keine Ahnung wie sowas geht und deine Meinung baut auf sowas dann auf.. Also auf Missverständnisse und nicht Wissen hast du eine Meinung, von der du nicht weg kommst..
Es ist ja nicht so, als wäre ich der einzige der wegen dem Thema (OSS) mit dir deswegen diskutiert..

Denn das Jailbreak Team braucht nach jedem Update immer länger um wieder
einen Fehler in Apples Sicherheitssystem zu finden.

Verfolge das schon lange nicht mehr, aber als ich es noch verfolgt habe, hat man meistens ABSICHTLICH die Jailbreaks verzögert, damit Apple diese nicht noch schneller fixen kann.

Und so nebenbei, die schlimmsten Lücken sind jene, von denen keiner was hört, bis es dann zu spät ist (so wie Heartbleed, goto fail bei Apple, etc).

Ich fühle mich daher mit meinem 5S und iOS 7.1 (für das es derzeit weder einen
Jailbreak noch Viren gibt) relativ sicher. Ganz im Gegensatz zum "sicheren"
Open Source Android.

Also mir wäre von Android keine Version bekannt gewesen, wo man via einem PDF im Browser Root-Rechte erlagen konnte.
Und wie du schon sagst, du fühlst dich sicher. Es ist nur ein Gefühl und keine Sicherheit, weil du den Source nicht kennst..
Man könnte bei Android (ohne Google-Services) auch ein Kickstarter Projekt machen und das komplett durchprüfen lassen.. Beim iOS wirst du sowas nie machen können und du musst dich immer auf den Source-Anbieter verlassen und auf dein ach so tolles Gefühl..

PS.: http://www.mobile-spy.com/blog/mobile-spy-ios-7-x-compatible-on-iphone-ipad-and-ipod/ ^^
Die setzen zwar offiziell auf den Jailbreak auf (daher noch nicht für 7.1), aber wenn es sowas offiziell/legal gibt, was glaubst du was Regierungen/Virenhersteller noch so alles können ^^
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Apple hatte wieder mal eine eigene SSL-Lücke

http://www.heise.de/newsticker/meldung/Apple-stopft-Sicherheitsluecken-in-iOS-OS-X-und-WLAN-Basisstationen-2174670.html

Also warum ist Closed Source nochmals besser?
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Also warum ist Closed Source nochmals besser?

Weil die Wahrscheinlichkeit hoch ist, dass diese Lücken ausser Apple kaum jemand kannte, weil der Quellcode nicht einsehbar ist.

Kann sein, muss aber nicht sein..

Siehe Netgear Router:
http://forum.geizhals.at/t837812,7265063.html#7265063

Die haben das Backdoor nicht abgedreht, sondern weiterhin nur "besser" versteckt. Pech für sie war halt, dass es jemanden so langweilig war und das besser überprüft hat.

Und man sollte die kriminelle Energie nie vergessen.. Wie ich schon oben erwähnt habe, sind die schlimmsten Lücken meisten jene, von denen man viel zu spät was hört (und wer weiß schon wielange sie ausgenutzt werden).
Da spielt Open oder Closed Source überhaupt keine Rolle..

Und bei Crypto-Software ist es halt besser, den Source zu kennen, damit man absichtliche Backdoors erkennen (eigentlich überall, aber gerade im Crypto Bereich ist das heikles).
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Kann sein, muss aber nicht sein..

OSS muss auch nicht sicherer sein...

Die haben das Backdoor nicht abgedreht, sondern weiterhin nur "besser"
versteckt.

Und es wurde trotz closed source gefunden. Sehr interessant.

Und bei Crypto-Software ist es halt besser, den Source zu kennen, damit man
absichtliche Backdoors erkennen

So lange du den code nicht selbst prüfst, verlässt du dich auch hier auf andere.

OSS muss auch nicht sicherer sein...

Muss nicht, aber das heißt nicht, das Closed-Source besser ist ^^

Jedenfalls bei Crypto Sachen würde ich NUR zu OpenSource greifen, weil dort ein Backdoor finden ist nicht so leicht wie bei Routern...

Und es wurde trotz closed source gefunden. Sehr interessant.

Mit OSS hätte man es noch schneller gefunden ^^
Des weiteren hat Netgear das ja sehr billig gemacht. Die nutzen noch immer den gleichen Port?!

So lange du den code nicht selbst prüfst, verlässt du dich auch hier auf
andere.

Und wo ist da der Unterschied zu Closed-Source?
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Und wo ist da der Unterschied zu Closed-Source?

Bei Closed Source kann ich mir aussuchen wem (welchem Unternehmen) ich vertraue. Bei Open Source habe ich keine Ahnung wer sich den Code ansieht. Manchmal weiss man nicht mal, wer ihn programmiert (siehe Truecrypt). Welchem anonymen Gebilde vertraue ich da eigentlich?

Das kannst du aber nicht generell sagen..
BSD kommt von einer Uni. Der Linux Kernel ist auch OpenSource und wird sogar von paar Firmen mitgepflegt..

Für OpenSSL hat sich irgendwie niemand zuständig gefühlt.. LibreSSL sollte das ja jetzt ändern.

Die ganzen Top-Apache Projekte, Android, Chrome, etc. Alles OpenSource und wird von Firmen gemacht.

Und durch NSA & Co geht es den meisten nichtmal darum, ob der Open-Sourcecode sauberer/fehlerfreier ist als Closed Source, sondern dass sich jemand (Spezialisten) den Code ansehen kann und auf Backdoors überprüfen kann.
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Die ganzen Top-Apache Projekte, Android, Chrome, etc. Alles OpenSource und
wird von Firmen gemacht.

Du weisst aber schon, dass das kein Argument für Open Source ist, sondern eher dagegen, oder?
Weil das nahe legt, dass diese Projekte nicht deshalb erfolgreich sind, weil sie Quelloffen sind, sondern weil sie von Firmen (Profis) programmiert werden.

Oder etwas plakativer formuliert: wenn firmen gute opensource programme erstellen können, warum sollen die closed source programme von unternehmen dann schlecht sein?

Oder etwas plakativer formuliert: wenn firmen gute opensource programme
erstellen können, warum sollen die closed source programme von unternehmen
dann schlecht sein?

Habe ja nie behauptet das sie schlecht sind.. Du sagst ja immer Open-Source ist schlecht ^^

Des weiteren geht es um Backdoors zum 3000000000. Wer weiß ob Google nicht welche in den Google-Services hat.. Man weiß es nicht, weil es keinen Source dazu gibt. Im normalen Android is nix drinnen..

Bei iOS kannst du das auch nie wissen, außer es kommt jemand darauf.

Und genau um das geht es die ganze Zeit, wenn es um OpenSource und Crypto-Sachen geht!!
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Des weiteren geht es um Backdoors zum 3000000000. Wer weiß ob Google nicht
welche in den Google-Services hat.. Man weiß es nicht, weil es keinen Source
dazu gibt. Im normalen Android is nix drinnen..

Du wirst auch nie wissen ob in Open Source Backdoors drinnen sind. Du kannst nur darauf vertrauen, dass andere sie finden, weil ein Menschenleben nicht ausreicht um auch nur alle Zeilen Code der Programme zu überprüfen, die du verwendest.

Du vertraust auf die anonyme Masse und ich auf den Druck der Kunden, der auf den Unternehmen lastet. Wir werden es beide nie aus erster Hand wissen, ob Backdoors in unserer Software sind.

Was ich ned ganz versteh, warum es soviele Server - speziell im staatlichen Betrieb - gibt, welche diese Lücke scheinbar länger (noch immer?) aufweisen.

Diejenigen, die sich öfters um Updates scheren, werden die Lücke doch eher umgehend geschlossen haben.

Diejenigen, die es nicht tun, werden imho zu einem großen Prozentsatz eine ältere Version (1.0.0 z.b.) installiert haben, welche diese Lücke nicht aufweist...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung