Login
Newsletter
Werbung

Thema: Die Nachwirkungen von Heartbleed

47 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Helen Lovejoy am Fr, 11. April 2014 um 15:41 #

s.o.

[
| Versenden | Drucken ]
0
Von HMEDW am Fr, 11. April 2014 um 17:09 #

Da steckt die NSA und der Mossad dahinter. Und vmtl. die
Großindustrie. Warum muss ich jetzt an Theodor Körners
Spruch denken?

[
| Versenden | Drucken ]
  • 0
    Von akf am Sa, 12. April 2014 um 10:37 #

    Ich gehe immer noch von einem Versehen aus.
    Andererseits ist es auch plausibel, dass die Geheimdienste und andere finstere Gestalten diesen Fehler früher entdeckt und ausgenutzt haben. Insofern kommt es letztendlich auf das selbe hinaus.

    [
    | Versenden | Drucken ]
0
Von gol am Fr, 11. April 2014 um 18:06 #

"Was wir hier bei OpenSSL gerade haben, ist die kleinste Risikostufe."

[
| Versenden | Drucken ]
0
Von Anonymous am Fr, 11. April 2014 um 18:18 #

+++ FakeTicker +++:

Robin S. bekennt: Ich war jung und ich brauchte das Geld ;)

[
| Versenden | Drucken ]
  • 0
    Von Herzlos am Fr, 11. April 2014 um 20:35 #

    In der Tagesschau wird damit argumentiert, dass der Entwickler ja schon länger bei OpenSSL mitwirken würde und dies dann ein Indiz wäre, dass es eben keine Absicht wäre:
    http://www.tagesschau.de/wirtschaft/heartbleed100.html


    Tja, auch wenn ich ebenfalls der Meinung bin, dass er hier nur einen unbeabsichtigten Programmierfehler gemacht hat, so ist das Argument mit dem langen Mitwirken doch völliger Unsinn.

    Jeder weiß doch, dass bei der Verbrechensbekämpfung die Maulwürfe ganz langsam und über Wochen immer mehr in die Verbrechensstrukturen eingeschleust werden, um erst so spät wie nur möglich, nachdem so viele Informationen wie möglich abgegriffen wurden und wichtige Daten anvertraut werden, weil er ja kein Neuling mehr ist, zuzuschlagen.

    Übertragen auf den Bug ist eine lange Mitarbeit an einem Open Source Projekt also eher ein Argument für einen durch Geheimdienste plazierten Bug als eine Entlastung dieser Verschwörungstheorie.

    [
    | Versenden | Drucken ]
    • 0
      Von Moo0 am So, 13. April 2014 um 19:23 #

      Und dabei sollte doch Open Source helfen, dass andere auch mal einen Blick darauf werden können, Mängel zu entdecken. Wenn also Robin S. schon länger mitgewirkt hat, haben sich dann die anderen blind auf ihn verlassen?

      Und wieso prüft niemand Strukturen in Aoftware, die so gavierend in Sicherheitskonzepte eingreifen? Wieso dauern so einfache Software-Probleme Jahre, bis öffentlich darüber diskutiert wird? Wieso wird für Software-Herstellung das Tool verwendet, dass am nächsten liegt und nicht das, was die bestmöglichste Sicherheit bietet?

      Das sagt doch alles (das Fazit):
      http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

      Das alles erschüttert mich, und ich habe aufgehört mich mit Onlinebanking zu beschäftigen, weil ja der Onlinebanker die Verantwortung für sein Tun selber übernehmen muss. Auf Basis solcher Probleme wie oben? Ich kann garnicht soviel k. wie ich essen müsste

      Dann lieber Papier statt Online. Das kann man in die Hand nehmen und es fällt auf, wenn jemand manipuliert.

      [
      | Versenden | Drucken ]
0
Von DerRuhri am Sa, 12. April 2014 um 08:00 #

..sondern von MediaMonks

[
| Versenden | Drucken ]
0
Von baboon am Sa, 12. April 2014 um 08:37 #

Was mich irgendwie entäuscht ist einseitige Berichtsweise von Pro-Linux. Wäre das eine Closed-Source Software, hätte Pro-Linux es längst in der Luft zerissen, einschließlich Kommentare. Das ist aber mit Open-Source passiert und alles was man erfährt ist ein Sosolala mal nebenbei.

Kritik an OSS?! No Way!

Klar, Pro-Linux ist ein Wurstblatt für möchtegern Erleuchtete. Aber in sachen Qualität und neutralität, schadet das einfach jedem. Echt, selbst Apple-Fanseiten üben mehr Kritik an ihren Produkten als ihr.

[
| Versenden | Drucken ]
  • 0
    Von fx am Sa, 12. April 2014 um 09:07 #

    :) :? :lol: :x :huh: :roll:

    [
    | Versenden | Drucken ]
    0
    Von White Rabbit am Sa, 12. April 2014 um 10:07 #

    Mit Closed Source wüßtest du immer nicht mal was von dem "Bug".

    [
    | Versenden | Drucken ]
    • 0
      Von Herzlos am Sa, 12. April 2014 um 20:11 #

      Bei CSS kennen Geheimdienste auch nicht alle Bugs der SW kurz nach Release,
      bei OSS schon, denn der Quellcode ist ja verfügbar und das 1000 Mann Team aus qualifizierten Leuten des Geheimdienst wartet nur darauf, in bezahlter Vollzeitarbeit einen Code Audit des OSS Quellcodes zu machen ohne das Ergebnis an das Projekt zurückzuliefern.
      Ohne Quellcode hat es hier auch der Geheimdienst schwieriger.

      [
      | Versenden | Drucken ]
      • 0
        Von snafu am So, 13. April 2014 um 00:10 #

        Das ist wohl wahr. Wenn dazu noch schön in einem öffentlichen Repo entwickelt wird, dann ist es im Fall von sicherheitsrelevanter Software eine herzliche Einladung für jeden Cyber-Kriminellen oder entsprechenden Geheimdienstmitarbeiter (gibt's wirklich Unterschiede zwischen den beiden Gruppen?), dass man da in Ruhe vorab im Code stöbern kann und nichts dekompilieren muss. Bei all meiner Sympathie für Open Source, ist dieser Umstand leider nicht von der Hand zu weisen.

        [
        | Versenden | Drucken ]
        • 0
          Von Merker am Mo, 14. April 2014 um 10:01 #

          ich glaube kaum, dass ein Geheimdienst Probleme hätte, sich den Quellcode von closed source zu besorgen.

          [
          | Versenden | Drucken ]
          • 0
            Von White Rabbit am Mo, 14. April 2014 um 11:37 #

            Zum einen das, und zum anderen ist es aber auch nicht so schwer ein Binary durch den Decompiler bzw. Disassembler zu jagen, und den daraus reultierenden Code zu analysieren.

            Was auch den Vorteil hat, das man den Ist-Zustand des Binaries analysiert. Wie wir ja vor ein paar Wochen gelernt haben, werden durchaus im Quellcode vorhandene Sicherheitschecks von den Compileren "herausoptimiert".

            [
            | Versenden | Drucken ]
            • 0
              Von Herzlos am Mo, 14. April 2014 um 21:24 #

              Zum einen das, und zum anderen ist es aber auch nicht so schwer ein Binary durch den Decompiler bzw. Disassembler zu jagen, und den daraus reultierenden Code zu analysieren.

              Das ist schwerer als mit Quellcode.
              Insbesondere bei der Interpretation des Binärcodes in die richtigen Opcodes und in Folge in durch Menschen verständliche Assemblerbefehle können auch vom Disassembler Fehler gemacht werden, da die Rückführung vom Binärcode in Opcodes nicht immer eindeutig ist.
              http://en.wikipedia.org/wiki/Disassembler#Problems_of_disassembly

              [
              | Versenden | Drucken ]
        0
        Von White Rabbit am So, 13. April 2014 um 10:47 #

        "Security by Obscurity" natürlich auch eine Lösung. Ernsthaft? Natürlich nicht!

        [
        | Versenden | Drucken ]
        • 0
          Von Herzlos am So, 13. April 2014 um 20:06 #

          Habe ich nicht behauptet.
          Natürlich bietet Obscurity keine technische Sicherheit, aber man darf die menschliche Komponente nicht übersehen, es wird aufwendiger und nicht mehr habe ich gesagt.

          Das ist im Prinzip wie bei Fahrradschlössern oder jede andere Sicherheitstechnologie.
          Absolute Sicherheit gibt es auch bei guten Schlössern nicht, aber der Dieb braucht länger um es zu knacken.

          [
          | Versenden | Drucken ]
          • 0
            Von White Rabbit am Mo, 14. April 2014 um 11:07 #

            Doch hast du! Mit der Aussage, das es mit Closed Source aufwendiger ist, implizierst du, das Closed Source sicherer sei. Also "Security by Obscurity"

            Gerade Geheimdienste haben mehr als genug Ressourcen, das es keinen großen Unterschied macht, ob es jetzt Closed Source oder Open Source ist. Mit 1000 Mann ist der Unterschied nur marginal.

            [
            | Versenden | Drucken ]
            • 0
              Von Herzlos am Mo, 14. April 2014 um 21:41 #

              Doch hast du! Mit der Aussage, das es mit Closed Source aufwendiger ist, implizierst du, das Closed Source sicherer sei. Also "Security by Obscurity"

              Nein, siehe oben. Guck dir das mal an, welche Probleme beim Disassemblieren entstehen können.


              Und bezüglich der Frage der Sicherheit gibt es immer zwei Sichtweisen.
              Zum einen die technische Sicherheit, die erreicht man mit Obscurity niemals.
              Ganz anders sieht es aber mit dem menschlichen Faktor aus, weiß kein Mensch eine Sicherheitslücke auszunutzen, weil er keine Kenntnis über ihre Existenz hat, dann bietet die Software technisch zwar weiterhin keine Sicherheit, aber die Daten sind dennoch sicher, da niemand weiß, wie er da rankommen soll.
              Zur Frage der Sicherheit gehört also nicht nur die Frage, ob eine Sicherheitslücke besteht, sondern auch, ob sie gefunden wird.

              Sicherheit ist somit nicht gleich Sicherheit.
              Man sollte hier differenzieren, welche Sicherheit genau gemeint ist, eine absolute, also die technische, oder eine die den menschlichen Faktor berücksichtigt.

              Gerade Geheimdienste haben mehr als genug Ressourcen, das es keinen großen Unterschied macht, ob es jetzt Closed Source oder Open Source ist. Mit 1000 Mann ist der Unterschied nur marginal.
              Auch ein 1000 Mann Team hat die obigen Probleme bei der Disassemblierung.
              Der Aufwand ist damit nicht nur größer, sondern auch fehlerträchtiger.

              Daraus folgt folgende Überlegung:
              Während bei einem verfügbaren Quellcode ein 1000 Mann Team genügt, brauchst du bei fehlendem Quellcode gleich ein wesentlich größeres Team um den Code Audit in der gleichen Zeit zu schaffen.

              [
              | Versenden | Drucken ]
    1
    Von seblin am Sa, 12. April 2014 um 11:17 #

    Open Source ist nicht das Problem. Das Problem ist hier der bedenkenlose Einsatz einer Open Source Software im sicherheitsrelevanten Bereich in Verbindung mit der Tatsache, dass das Projekt offenbar viel zu wenige Mitarbeiter hat. Die Lösung ist also nicht die Verwendung von Closed Source, sondern die die Unterstützung von Open Source Projekten, wenn es in heiklen Bereichen nötig ist. Das macht man aber typischerweise nicht als kleiner Server-Admin, sondern hofft darauf, dass sich die großen Konzerne, die ebenfalls diese Software benutzen, hier finanziell oder mit eigener Manpower (Fehlerberichte, Einfließen von Patches) entsprechend engagieren - und zwar vorwiegend, um nochmal über den bestehenden Code zu schauen und weniger für tolle neue Features.

    [
    | Versenden | Drucken ]
    • 0
      Von baboon am Sa, 12. April 2014 um 11:41 #

      Das mag zwar schön und gut sein, weiß ich übrigens selbst, dein Kommentar geht an meinem völlig vorbei. Mir geht es hier um Pro-Linux das nur einseitig berichtet und damit überhaupt nicht neutral wirkt. Darum geht es mir. Damit verspielt diese Seite ihre glaubwürdigkeit. Dreck passiert nunmal überall und Pro- Windows/Apple Seiten sind hier deutlich kritischer. Pro-Linux arbeitet schon beinahe desinformativ.

      [
      | Versenden | Drucken ]
      • 0
        Von asdfghjkl am Sa, 12. April 2014 um 11:51 #

        DESINFORMATIV??? Was bitte soll man mehr tun als darüber zu berichten, dass der Bug "katastrophal" sei und auf einer Skala von 1-10 eine 11?
        Ok, ich weiß - du willst nicht über den Bug informiert werden, sondern du willst hören, dass Open Source Mist ist...

        [
        | Versenden | Drucken ]
        0
        Von PsycoMike am Sa, 12. April 2014 um 23:05 #

        Da muss ich Dir mal recht geben, die Welt ist so ungerecht,
        wirklich deprimierend. Aber erzähl mir doch mal was wirklich
        Trauriges!
        Deine Geburt wäre ein guter Einstieg. 8)

        Küss die Hand
        P.M.

        [
        | Versenden | Drucken ]
      0
      Von Herzlos am Sa, 12. April 2014 um 20:14 #

      Die Lösung ist also nicht die Verwendung von Closed Source, sondern die die Unterstützung von Open Source Projekten, wenn es in heiklen Bereichen nötig ist.

      Nein, die Lösung kann eigentlich nur Software sein, deren Fehlerfreiheit mathematisch garantiert werden kann.

      Kann dies nicht gewährleistet werden, dann ist jede Software, ob CSS oder OSS generell als unsicher einzustufen.


      Dies gilt insbesondere dann, wenn die Software auch gegen Geheimdienste sicher sein soll.

      [
      | Versenden | Drucken ]
    0
    Von StefanO am Sa, 12. April 2014 um 11:59 #

    Es ist eben eine Frage der Wahrnehmung:
    Pro-Linux, wie auch der größte Teil der Leserschaft, geht mit diesem eklatanten Fehler sachlich und lösungsorientiert um.
    Niemand hier versucht das Problem zu beschönigen oder zu bagatellisieren, es gibt konstruktive Kritik am fehlerhaften Produkt und genügend Hinweise wie die Lösung aussieht.
    Auch taucht die Frage auf, wie zukünftig solche Situationen vermieden werden können.

    Was also soll an der Berichtserstattung von Pro-Linux falsch sein?

    Um den Rest, wie Selbstkritik an OpenSource usw., kann man sich doch gerne später kümmern. Sich derzeit damit zu befassen hilft wirklich niemandem echt weiter. Fehler passieren - in geschlossener wie auch offener Software, wer etwas anderes behauptet argumentiert unseriös.

    [
    | Versenden | Drucken ]
    • 0
      Von amoibos am Sa, 12. April 2014 um 13:47 #

      Also wenn man fremden Code den man offensichtlich nicht verstanden hat importiert und das einzige was einem dabei auffällt Performanz ist muss man sich doch fragen, warum man überhaupt OSS einsetzt. Die Codequalität ist sowohl bei GnuTLS als auch OpenSSL unter aller Sau. Man ist nicht mal gewillt gewesen ein Testcase dafür zu schreiben wo es sicher jemanden aufgefallen wäre, dass die Annahme Länge des Payload gleich eigene Payload ist. Und der Quatsch mit den malloc bei OpenSSL darüber will ich gar nicht erst reden.

      [
      | Versenden | Drucken ]
      • 0
        Von seblin am Sa, 12. April 2014 um 14:37 #

        Es ist aber eigentlich üblich, dass fremder Code importiert wird, ohne dass man weiß, was dieser im Detail tut. Hier vertraut man z.B. auf die Maintainer des verwendeten Distribution. Und die beschränken sich wohl mehrheitlich darauf, den Autoren der Software und der Community zu vertrauen ("irgendwer wird schon was sagen"). Eine mitunter sehr gefährliche Situation...

        Wie schon im anderen Kommentar geschrieben: IMHO sollte es deutlich mehr Code-Audits geben, auch wenn diese natürlich nicht kostenfrei sind. Es wird schon soviel Crowfunding für alle möglchen Sachen gemacht. Wieso dann nicht mal Spenden für ein ausführliches Audit von OpenSSL?

        Und achja, wie du schon selbst angedeutet hattest: Bei einem besseren Ausbau der Testsuite sind viele Fehler vermeidbar. Aber hinterher ist man natürlich immer schlauer.

        [
        | Versenden | Drucken ]
        • 0
          Von Herzlos am Sa, 12. April 2014 um 20:47 #

          den Autoren der Software und der Community zu vertrauen ("irgendwer wird schon was sagen"). Eine mitunter sehr gefährliche Situation...

          Was letzten Endes leider ein versagen des Open Source Modells ist, weil dessen Sicherheit darauf basiert, dass es auch Leute gibt, die sich den Code durchsehen.

          Wenn aber nur die 3 Entwickler übrig bleiben, dann kann man annehmen, dass so manche CSS sauberer und ordentlicher programmiert wird, firmenintern Codeaudits von anderen bezahlten Vollzeitmitarbeitern erhält und eine oder mehrere Drittfirmen aus dem Sicherheitsbereich auch noch gegen Geld mit einem Code Audit beauftragt wird die Software durchzuchecken.

          Fehler können überall passieren, ob CSS oder OSS, das ist vollkommen richtig.
          Schwerwiegend ist hier allerdings, dass die Mittel für den Sicherheitsgewinn, die OSS eigentlich bieten soll, nicht gegriffen haben weil sie nicht genutzt wurden und das über einen Zeitraum von 2 Jahren, was zu viel ist.

          Dies führt zu meiner obigen Schlussfolgerung.
          Jede Software, deren Sicherheit nicht mathematisch gewährleistet werden kann, ist als generell unsicher einzustufen. Damit ist in letzter Konsequenz auch OSS generell unsicher, wenn sie nicht mit entsprechenden Programmiersprachen und Werkzeugen, die diesem Ziel näher kommen können, entwickelt wurde.

          Und achja, wie du schon selbst angedeutet hattest: Bei einem besseren Ausbau der Testsuite sind viele Fehler vermeidbar. Aber hinterher ist man natürlich immer schlauer.
          Ähm, nein. Das erstellen von Testsuites ist heutzutage eine wesentliche Grundlage jeder Ausbildung, Lehre oder Studium im Bereich der Softwareentwicklung.
          Da muss man also nicht erst reinfallen um hinterher daraus zu lernen und schlauer zu sein, dass wusste man schon vorher.
          Man hat dieses Wissen nur in den Wind geschlagen.

          Wieso dann nicht mal Spenden für ein ausführliches Audit von OpenSSL?

          Sinnvoller wäre es, eine Implementierung von SSL in einer anderen Programmiersprache neu zu implementieren, deren Ergebnis beweisbar sicher ist oder diesem Ziel wenigstens annähernd entgegen kommt oder diesbezüglich hilft, diesem Ziel näher zu kommen.
          Eventuell also z.B. mit einer Programmiersprache aus dem Bereich der funktionalen Programmiersprachen.

          [
          | Versenden | Drucken ]
        0
        Von Anon Y. Mouse am Sa, 12. April 2014 um 15:22 #

        Was mich am meisten schockt ist dass cisco, juniper etc. das einfach so in ihre teuren produkte einbauen...

        [
        | Versenden | Drucken ]
        • 0
          Von gol am Sa, 12. April 2014 um 20:14 #

          Ebenfalls schockierend Red Hat, Suse, X(beliebige Linuxdistro), Y(BSDs) hat solche Pakete ebenfalls ausgeliefert.

          [
          | Versenden | Drucken ]
          • 0
            Von Herzlos am Sa, 12. April 2014 um 20:48 #

            Auch so manche Bank oder andere Unternehmen die viel Geld haben.
            Von Valve (Steam) bis Google ist da fast alles dabei.

            [
            | Versenden | Drucken ]
            0
            Von k_tz am So, 13. April 2014 um 14:41 #

            Das gilt so nicht allgemein. So war z.B. RHEL6 von der Sicherheitslücke betroffen, RHEL5 aber nicht. Nicht jede Openssl-Version ist verwundbar.

            Das MITRE CVE-Wörterbuch beschreibt das Problem wie folgt:

            The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

            Demzufolge sind z.B die Openssl-Versionen 1.0.0 und 0.9.8 nicht betroffen.

            Man sieht, dass die konservative Pflege einer Linuxdistribution, die auf den nachträglichen Einbau neuer Softwarefeatures aus neueren Versionen der gleichen Software verzichtet, durchaus Vorteile haben kann.

            Wir tendieren hier zwar oft zu sehr allgemeinen und angeblich global gültigen Aussagen, nur taugen diese angesichts solcher, auf bestimmte Versionen einer Software begrenzten Sicherheitslücken, die von der absichtlich panikartigen Berichtserstattung einiger Mainstreammedien benutzt wurden (ich meine damit nicht Pro-Linux) und teilweise zu hexenjagdähnlichen Communityhysterien geführt haben, nicht wirklich.

            Genau das wissen auch die Pro-Linux-Autoren und deshalb haben sie Ihre Artikel so verfasst wie das hier nachzulesen ist.

            [
            | Versenden | Drucken ]
        0
        Von k_tz am Sa, 12. April 2014 um 16:05 #

        Der Code wurde verstanden, sowohl vom Einreichenden als auch vom Rezipienten, es wurde lediglich ein Fehler im Code übersehen. Dieses Vorkommnis hat nichts mit der Art der Software zu tun. Dies passiert ständig, ansonsten bräuchte u.a. Microsoft nicht ständig Patchdays zu veranstalten. Oder denke einmal an die letzten Gnutls-Sicherheitslücken oder an das eine oder andere der letzten 50 Updates, das Dir in den letzten paar Monaten für Deine Linuxdistribution angbeoten worden ist.

        Das, was hier vor allen Dingen nicht funktioniert hat, ist Folgendes: Es gibt offenbar Leute, die schon vor über einem Jahr diese Sicherheitslücke bemerkt haben. Freie Software-Enthusiasten genauso wie ganz normale Leute hätten nun - immer vorausgesetzt, sie hätten auch über das hierzu notwendige Spezialwissen verfügt - diese Sicherheitslücke sofort an das Openssl-Team oder Ihren Linuxdistributor gemeldet und diese Lücke wäre sogleich geschlossen worden. Leider haben die Entdecker dieser Sicherheitslücke dann diese für Ihre eigene Zwecke missbraucht und offenbar darauf gehofft, dass der katastrophale Fehler möglichst lange offen bleiben möge. Diese Strategie wird auch im Closed Source-Bereich offen angewandt, zum Teil werden diese Sicherheitslücken direkt den Softwareherstellern zum Kauf angeboten, die im Gegensatz zu Openssl dann auch über das Geld verfügen, um diese Lücken bzw. das Wissen über diese gewissermaßen zu "kaufen", um Ihre Anwender zu schützen.

        Was Openssl somit fehlt, ist wohl ein aktives Code Auditing, um solche Sicherheitslücken vor "Externen" zu finden. Und hier bräuchte Openssl Hilfe von außen, alleine schon wegen des Aufwandes und der Kosten für einen dann in Vollzeit anzustellenden, Openssl in- und auswendig kennenden Programmierer.

        [
        | Versenden | Drucken ]
0
Von akf am Sa, 12. April 2014 um 10:51 #

Derweil kommen die Zertifizierungsstellen nicht schnell genug hinterher, Zertifikate zu erneuern. Somit verbleiben für die nächste Zeit immer noch Server in ungepatchtem Zustand […]

Die Zertifizierungsstellen haben mit dem „Patchen“ erstmal nichts zu tun. Dazu muss man einfach nur sein System updaten, bzw. eine aktuelle Version von OpenSSL einspielen.

Allerdings müssen die Zertifikate durch die Lücke als kompromitiert angesehen werden und danach auch ausgetauscht werden.

Anwender sollten zum Schluss auch all ihre Passwörter ändern. Aber erst, nachdem die Zertifikate erneuert wurden.

[
| Versenden | Drucken ]
  • 0
    Von cornelinux am Sa, 12. April 2014 um 12:31 #

    ...eben, und weil die Zertifikate revoket werden müssen und neue ausgestellt werden müssten, haben die CAs eine menge voll zu tun...

    [
    | Versenden | Drucken ]
    • 0
      Von cornelinux am Sa, 12. April 2014 um 12:32 #

      nachtrag:

      die Server verbleiben in einem potentiell kompromittierten Zustand, weil evtl. schon jemand den privaten Key und PWs hat.

      "ungepatchter" Zustand ist natürlich nicht korrekt.

      [
      | Versenden | Drucken ]
      • 0
        Von Christian Wetzel am Sa, 12. April 2014 um 16:32 #

        der Private Key alleine bringt aber nicht viel. Ich kann damit zwar perfekt die
        Webseite einer Bank nachbauen bekomme aber trotzdem keine Besucher.
        Erst wenn ich zusaetzliche z.B. einen DNS unter meine Kontrolle bringe
        kann ich auch Clients auf mich umleiten.

        [
        | Versenden | Drucken ]
0
Von Anonymous am Mo, 14. April 2014 um 00:55 #

> http://cubeupload.com/im/cFJAFg.jpg

vielleicht ist es ja nicht jedermanns Sache, aber ich bin gerade auf mavericks zurueckgelaufen - und werde jetzt mit virtuellen maschinen das reinzaubern, was ansonsten nur ueber linuxdirekt erreicht wurde...

eine art metabetriebsystem - ist immer noch das nonplusultra Wunschsystem.

bis dahin - mal wieder / vielleicht diesmal laenger mOS

rm1911/meesdorf.rangers (Ruedige Mueller)

> http://cubeupload.com/im/CpKznG.jpg

[
| Versenden | Drucken ]
0
Von maestro_alubia am Mo, 14. April 2014 um 20:50 #

Wieso gibt es beim Login auf Pro-Linux im Jahre 2014 eigentlich noch immer eine Checkbox [ ] SSL-Login? Gibt es noch irgendeinen Grund, nicht SSL/TLS zu verwenden? Es sollte zumindest der Default-Wert sein...

[
| Versenden | Drucken ]
  • 0
    Von Herzlos am Mo, 14. April 2014 um 21:46 #

    Gibt es noch irgendeinen Grund, nicht SSL/TLS zu verwenden?

    Aus Serverbetreibersicht wäre dies Performance.

    Performance ist übrigens ein Hauptgrund, warum die OpenSSL so weit verbreitet ist, obwohl es durchaus auch andere SSL Alternativen gibt. Die sind nur wesentlich langsamer.

    [
    | Versenden | Drucken ]
    • 0
      Von maestro_alubia am Di, 15. April 2014 um 18:51 #

      Ich glaube kaum, dass es sich für den Serverbetreiber lohnt an der Verschlüsselung zu sparen. Auf heutigen Prozessoren macht sich der Overhead doch kaum bemerkbar. Außerdem muss der Serverbetreiber dann wohlmöglich auch mehr Arbeit und Rechenleistung in die Beseitigung von Problemen investieren, die durch gestohlene Zugangsdaten entstehen können, beispielsweise Spam, rechtliche Probleme usw.

      Hast du einen Beleg für die Aussage mit OpenSSL? Wäre mir zumindest neu, dass beispielsweise GnuTLS _wesentlich_ (im Sinne von > 10%) langsamer ist.

      [
      | Versenden | Drucken ]
      • 0
        Von Herzlos am Mi, 16. April 2014 um 09:38 #

        Ich glaube kaum, dass es sich für den Serverbetreiber lohnt an der Verschlüsselung zu sparen.
        Das hängt davon ab, ob es dem Serverbetreiber egal ist.
        In manchen Fällen ist es ja nur für den Konsumenten wichtig, dass verschlüsselt wird.

        Auf heutigen Prozessoren macht sich der Overhead doch kaum bemerkbar.

        Der Overhead zwischen Verschlüsselung und ohne macht sich sehr wohl bemerkbar.
        Dies liegt vor allem auch daran, das es gleich ein paar tausend Zugriffe auf Webserver sind, da macht es also die schiere Menge die an der Performance der Rechner zehren.
        Außerdem sind verschlüsselte Inhalte in den Proxy-Caches der ISP nutzlos, während unverschlüsselte Inhalte die Webseitenbetreiber entlasten, das spart Traffickosten.

        Einige Webseitenbetreiber die Verschlüsselung anbieten leiten den Benutzer deswegen oftmals erst dann, wenn Verschlüsselung wirklich wichtig ist, auf die Verschlüsselte SSL Seite und in allen anderen Fällen wird der Webseitencontent bevorzugt unverschlüsselt an die User geschickt.
        GMX macht das z.B. so.


        Kommt Verschlüsselung dennoch zum Zuge, dann setzen manche Anbieter sogar bewusst Kryptografieverfahren mit geringerer Keybreite ein oder bevorzugen bei Fingerprints SHA-1 anstatt z.B. SHA-256, eben weil das alles Performance kostet.
        Einige Webserver setzen daher auch heute noch auf das heute eigentlich nicht mehr als ausreichend sicher einzustufende RC4 Verfahren, eben deswegen, weil es sehr schnell ist.


        Hast du einen Beleg für die Aussage mit OpenSSL? Wäre mir zumindest neu, dass beispielsweise GnuTLS _wesentlich_ (im Sinne von > 10%) langsamer ist.
        Du kannst so einen Test durchaus selbst durchführen, beide Libs sind ja kostenlos verfügbar.

        Hier hat sich mal jemand diese Mühe gemacht, leider ist GnuTLS nicht dabei, aber dafür viele andere und es ist überdeutlich, dass OpenSSL auf Geschwindigkeit hochtoptimiert wurde, wie auch die Zahlen im Vergleich zu anderen Bibliotheken in diesem Test zeigen:

        https://panthema.net/2008/0714-cryptography-speedtest-comparison/

        Auf der lftp Mailingliste hat mal jemand OpenSSL mit GnuTLS verglichen, und da waren das nicht nur > 10 %, sondern gleich sieben mal so schnell bei wesentlich geringerer CPU Last:
        https://www.mail-archive.com/lftp-devel@uniyar.ac.ru/msg01487.html

        [
        | Versenden | Drucken ]
0
Von pmller am Mi, 23. April 2014 um 01:39 #

OpenBSD hat OpenSSL als LibreSSL geforkt.

Laut de Raadt ist es nicht möglich, im Rahmen des alten OpenSSL-Projektes den OpenSSL-Code so zu reparieren bzw. umzuschreiben, dass man diesem trauen kann.

Siehe:

http://www.libressl.org/

http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/

LibreSSL wird bereits in OpenBSD 5.6 zu finden sein.

OpenSSL hat letztlich unser Herz gebrochen. Game Over.

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung