„Heartbleed“: Entwickler spricht über Fehler bei OpenSSL-Programmierung

Heartbleed800

Ein blutendes Herz steht derzeit symbolisch für eine Schwachstelle bei der Verschlüsslung-Software „OpenSSL“, die von vielen Internet-Angeboten genutzt wird – unter anderem auch beim E-Mail-Dienst von T-Online. Was die Telekom auf ihren Servern unternommen hat, um die „Heartbleed“-Lücke schnell zu schließen, und was unsere Experten den Kunden beim Umgang mit E-Mail, Virenschutz und Passwörtern raten, das findet Ihr in einem aktuellen Beitrag aus unserem Sicherheits-Special.

 

Das Thema wird medial sehr breit diskutiert – einige Artikel sprechen von der gravierendsten Sicherheitslücke in der Geschichte des Internets. Eine gute Zusammenfassung der aktuellen Diskussion gibt es bei Spiegel Online. Im Spiegel-Artikel findet sich auch der Hinweis auf den Programmierer der fehlerhaften Software, der heute bei der Telekom arbeitet. Unser Kollege – der zwischenzeitlich sogar in den Dunst von Verschwörungstheorien geriet – hat uns seine Sicht auf die Dinge aufgeschrieben. Das wollen wir hier gern veröffentlichen. Aus Respekt vor seiner Privatsphäre verzichten wir allerdings darauf, ihn namentlich zu nennen:

 

„Ich habe im Rahmen eines Forschungsprojektes an der FH Münster die bekannte Verschlüsselungsbibliothek OpenSSL genutzt und die während meiner Arbeit entstandenen Bugfixes und neuen Features dem OpenSSL Projekt zur Verfügung gestellt. Nach Prüfung durch ein Mitglied des OpenSSL Entwicklungsteams wurden die jeweiligen Änderungen in den offiziellen Code übernommen. Bei einer Erweiterung, der TLS/DTLS Heartbeat Extension, unterlief mir der Fehler, eine Variable mit einer Längenangabe nicht auf einen sinnvollen Wert zu überprüfen. Dies ermöglichte den jetzt gefundenen und nach der Erweiterung benannten Heartbleed Bug. Leider hat auch der OpenSSL Entwickler, der den Review des Codes durchgeführt hat, die fehlende Überprüfung nicht bemerkt. Dadurch wurde der fehlerhafte Code in die Entwicklungsversion übernommen, aus der später die veröffentlichte Version wurde.

 

Da die Länge nicht auf Plausibilität geprüft wurde, konnte unter Angabe von eigentlich ungültigen Werten mehr Speicher als vorgesehen ausgelesen werden. Dadurch entstand eine Zugriffsmöglichkeit auf sicherheitsrelevante Daten, und ein eigentlich einfacher Fehler hat schwerwiegende Folgen.

 

Ob der jetzt bekannt gewordene und behobene Fehler durch Geheimdienste oder andere ausgenutzt wurde, ist schwer zu beurteilen. Um solche Fehler in Zukunft zu verhindern oder zumindest die Wahrscheinlichkeit zu minimieren, dass so schwerwiegende Probleme so lange unentdeckt bleiben, ist es wichtig, kritische und sicherheitsrelevante Software so oft wie möglich zu kontrollieren. Das ist ein großer Vorteil von Open Source Software, die für jeden frei verfügbar ist, der sich beteiligen möchte. Leider mangelt es aber gerade bei OpenSSL trotz sehr weiter Verbreitung und dem Einsatz durch Millionen von Nutzern beständig an ausreichender Unterstützung. Denn trotz der vielen Nutzer gibt es nur sehr wenige, die sich aktiv an dem Projekt beteiligen.“

Kommentare (31)

  1. Kai Gärtner sagt:

    Mich wundert ja, dass die Telekom, obwohl offenbar zumindest beim Mailservice von dem Problem betroffen, die Kunden nicht dazu anhält ihre Passwörter zu ändern.
    Viel mehr verwundert, dass OpenSSL zwar von etwa 2/3 aller Webserver verwendet wird, die Unterstützung so gering ist. Es müsste ja nicht einmal durch Entwickler geschehen, es würde ja schon reichen, wenn die Nutzer einen entsprechenden Beitrag für die Verwendung von OpenSSL spenden würden. https://www.openssl.org/support/donations.html

    • Oliver sagt:

      Passwort-Reset war gemeint … und ich hatte das so verstanden, die Telekom hätte sich inzwischen finanziell an dem Projekt beteiligt. Na das kann ja noch werden … ein Fall für die Marketing-Abteilung würde ich sagen. ;)

    • Christian sagt:

      Geschehen? Was? Eine Spende an die OSF für jahrelange kostenfreie Nutzung von OpenSSL?

  2. Martin Reti sagt:

    Ich finde es interessant, einen Blick hinter die Kulissen zu bekommen. Wie kann ich mir das vorstellen mit der Längenangabe?

  3. Lars Schotte sagt:

    Tha … FeFe meint, eh, das war keine Backdoor. Ich meine, die Neoliberalen haben sich Mühe gegeben es zu verstecken und T-Systems ist ja eh ein Arm der CIA. Ich würde mir also anstelle der Telekommitarbeiter eine andere Frage stellen. Was für eine Welt hinterlassen diese Leute ihren Kindern, wenn die für so ein Unternehmen arbeiten. Und viel wichtiger noch, ob es sich lohnt, nach einer Revolution dann auf der Anklagebank zu stehen, so wie hier in Nürnberg schon Tradition ist. Denn die Urteile sind spätestens jetzt klar.

    • Guido sagt:

      Hallo Lars,

      Sitenote: Ich wäre mit den Vergleichen bzgl. “Revolution”, “Anklagebank”, “Nürnberg” etwas vorsichtiger – ich verurteile nach wie vor aufs Schärfste alles, was in der Zeit 33-45 in Deutschland geschah, und sehe die Prozesse in Nürnberg als sehr gerechtfertigt an. Und ich sehe überhaupt keinen Zusammenhang mit der DTAG/T-Systems. Wenn man deinen Kommentar so liest, könnte man mit “Revolution” genau die o.g. Zeitspanne sehen – welche ich klar als “Totalitäres Regime” bezeichne.

  4. Obwohl der Qualitätssicherungsprozess bei OSS mehrfach gescheitert ist wird wieder einmal in diese Richtung Argumentiert.
    Hauptproblem ist fehlende Verantwortlichkeiten und daraus fehlende gewährleistung

    • Richard Weitz sagt:

      Haben hier eine Cisco-Büchse stehen inkl Gewährleistung (allerdings nicht auf Fehlerlosigkeit), die diesen Bug ab Werk hat bzw. hatte. Also taugt wohl auch die Qualitätskontrolle solch großer Firmen nichts.

    • Marco sagt:

      Als professioneller Software-Entwickler, der auch in Freie-Software-Projekten aktiv ist, kann ich Dir versichern, daß die Qualität freier Software im Schnitt um Größenordnungen besser ist als die Qualität proprietärer Software.

      Warum?

      Weil freie Software größtenteils von Leuten aus Spaß und ohne Zeitdruck geschrieben wird. Da wird der Code zig Mal umgeschrieben und verbessert, bis er den eigenen (hohen) Ansprüchen genügt und man sich damit brüsten kann (es geht bei freier Software schließlich auch ums Image – immerhin kann jeder den Code einsehen).

      Proprietäre Software hingegen wird mit knappen Budgets geschrieben. Wenn der Code funktioniert, dann ist die Aufgabe erfüllt. Die nächste Aufgabe drängt schon und Software-Entwickler-Zeit ist sehr teuer. Die wenigsten Firmen ermöglichen es daher ihren Mitarbeitern, den Code noch zig Mal zu überarbeiten und daran herumzufeilen. Das kann sich doch (fast) keine Firma leisten!

      Desweiteren arbeiten an Freie-Software-Projekten die gleichen Leute über sehr lange Zeiträume hinweg. In den meisten Firmen herrscht dagegen rege Personalfluktuation. Und jeder weiß: Zu viele Köche verderben den Brei. Der zehnte Maintenance-Programmierer versteht oft nur noch ansatzweise, was die 9 vor ihm mit dem Code eigentlich bewirken wollten.

      • Das cisco sich ungeprüft auf oss verlässt (wie andere auch) ist eher ein Indiz für meine These. Qualität und Oss haben keinen Zusammenhang.
        Was niemand wegdiskutieren kann, ist die fehlende Verantwortung. Nur gut das in anderen Bereichen wo’s drauf ankommt nicht sogearbeitet wird. Alle relevanten sicherheitsleaks der letzten Zeit kamen aus dem Oss Lager, blieben jahrelang unentdeckt und wurden nicht durch source Review sondern Trading und Parsing entdeckt.

        • Marco sagt:

          Hannes, in welcher Welt lebst Du eigentlich? Seit wann sind denn Firmen dafür bekannt, Verantwortung zu übernehmen???

          Firmen, die relevante Verantwortung übernehmen, gibt es nicht!!! Spätestens seit der Bankenkrise sollte das doch wirklich jedem klar sein! Die Banken haben der Gemeinschaft die Verantwortung aufgedrückt (dank unserer korrupten Politiker – in Island lief das besser und die Bankster gingen in den Knast).

          Die Banken sind natürlich nicht die einzigen Firmen, die sich um die Verantwortung drücken.

          Oder übernimmt etwa Coca Cola die Verantwortung für den von ihnen verursachten Wassermangel in Indien? Nein!

          Wie sieht’s mit den zahlreichen Ölkatastrophen und anderen Umweltverbrechen aus? Übernehmen die Palmölhersteller etwa die Verantwortung für die Zerstörung von Sumatra und anderen Inseln Indonesiens? Nein, natürlich nicht! Wie auch, sie ziehen ja gerade daraus ihre exorbitanten Profite. Müßten sie für die von ihnen begangenenen Verbrechen bezahlen, würden sie ja kaum noch Gewinn einfahren. Die ganz seltenen Fälle, in denen der Staat nicht vor einem Konzern kuscht, sondern ihn wirklich zur Verantwortung zieht, zeigen dies: BP steht wegen der Ölpest in Mexiko vor existenziellen Problemen.

          Firmen übernehmen nur bei Lappalien die Verantwortung und das mit viel PR-Tam-Tam – bei wirklich großen Schnitzern drücken sie sich.

          Abgesehen davon: Warum zum Henker setzt Cisco bitte schön OpenSSL ein, ohne es je gereviewed zu haben?

          Und nochwas: Deine Aussage, daß der OpenSSL-Bug nicht nurch Review gefunden wurde, ist FALSCH. Der Bug wurde gleichzeitig auf zwei Arten gefunden – und eine davon war ein Code-Review!!!

        • Andreas Göb sagt:

          “Alle relevanten sicherheitsleaks der letzten Zeit kamen aus dem Oss Lager”?

          Definitiv nicht. Was ist z.B. damit, dass über Jahre hinweg der Standard-Zufallstahlengenerator der (kommerziellen) RSA-Kryptobibliothek einer war, der dank Lobbyarbeit der NSA standardisiert wurde und nachweislich schwach war? Keine OSS. Das Problem des offenen Ports 32764 auf unzähligen Routern? Keine OSS. Aber mit Sicherheit beides relevant.

        • dos sagt:

          “das cisco sich ungeprüft auf oss verlässt (wie andere auch) ist eher ein Indiz für meine These. Qualität und Oss haben keinen Zusammenhang.”

          Ganz recht!

          Aber: ich sehe OSS auch “in der letzten Zeit” pari beim (Sicherheits)-Fehleraufkommen, – nicht hinter Proprietär.

        • dos sagt:

          Da wüsste ich gern mehr – zur Entdeckungsgeschichte: links?

          Wenn an der NSA-Sache (seit 2 Jahren !!?) was dran ist, spielt “Code-Review” vermutlich schon eine Rolle:
          OpenSource-Nachteil ist, daß entspr. Kreise solche Schwachstellen gezielt suchen können, ohne die Sourcen ist es viel schwieriger, da muß man an der Kommunikation rumdrücken, vergessene Verben finden usw.

      • dos sagt:

        “Weil freie Software größtenteils von Leuten aus Spaß und ohne Zeitdruck geschrieben wird. ”
        Menschenskinder!!
        Zeitdruck herrscht IMMER, der OpenSSL-Code kam “im Rahmen eines Forschungsprojektes an der FH Münster” (= i. d. R. ein bißchen Ehr’, wenig Geld und KEINE SICHERHEIT!!) quasi eher nebenbei zustande, und es macht sich GUT, wenn man sich bei T-Systems o. sonstwo bewerben will/muss, viele gutgemachte Dinge IN KURZER ZEIT vorweisen zu können. Dazu gehört auch die Übernahme von “Koppelproduktionen” aus einem Projekt in die offiz. Distribution eines SICHERHEITS-Tools, das auf den fettesten Sites eingesetzt wird: Da freut sich jeder Arbeitgeber.

        Auch der Rest ihres Kommentars ist die übliche Rosa-Brillen-Sicht, die Opensource=bessere-Sicherheit-als-Proprietär-Verfechter in Bedrängnis von sich geben: Sie begründen, warum das besser sein MÜSSTE, aber ignorieren die Erfahrungstatsachen, – und die bei näherem Hinsehen haltlosen Vorteilsgründe (siehe auch meinen Kommentar unten) helfen nicht wirklich:
        “Proprietäre Software hingegen wird mit knappen Budgets geschrieben. ” Klar, bei OpenSource hagelts nur so vor üppigen Mitteln.
        “Desweiteren arbeiten an Freie-Software-Projekten die gleichen Leute über sehr lange Zeiträume hinweg. In den meisten Firmen herrscht dagegen rege Personalfluktuation.”
        Und der Programmierer hier WAR noch nichtmal bei openSSL selbst! Wieviel Zeit hat er an wieviel opensource-Sachen verbracht und wieviel an proprietären?

        Mir scheint manchmal “OpenSource” wirke bei 50% aller Leute als quasi “Absolute Metapher” (H. Blumenberg”) bzw. als Stigmergentium, allerdings nicht als konstruktiver Automatismus, wie z. B. bei Termiten und ihren “zwingenden Mark(ierung)en”, sondern als Wahn-Trigger.

      • dos sagt:

        Ach ja, und dass langfristige Köpfe wichtigen Projekten/Zielen genausogut förderlich wie hinderlich sein können ist auch klar.

        Die Fragen nach digitaler Demokratie u. v. a. werden seit LANGEM von Leuten verstopft, die äußerst langristig ihre “Positionen” in der ach so tollen “Szene” halten: CCC, Piraten, Beamte u. Verwaltungen (vergl. Enquete-Kommission Dig. Gesellschaft usw.)

  5. Pingback: OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts | NHAT NET

  6. way sagt:

    Option 1: Backdoor mit guter Entschuldigung
    Ein prominenter Blogger hat ja dezent aber unverbindlich darauf hingewiesen das er eine Backdoor genau so umsetzen würden. Sollte es eine Backdoor sein hat Herr S. sich jedenfalls Mühe gegeben es wie einen Fehler aussehen zu lassen, darauf muss man erst mal kommen. Alleine das wäre schon in gewisser Weise Anerkennung wert (sofern man Moral hinter die paranoide Angst vor Terroristen und das böse böse Internet stellt).

    Option 2: Einfach nur ein Fehler an “suboptimaler” Stelle
    Viel wahrscheinlicher ist das der Mann einen simplen Fehler begangen hat. Einfach ausgedrückt fehlt nur die Überprüfung “stimmt das was mein Gegenüber da behauptet?”. Jeder Entwickler macht Fehler aber die wenigsten arbeiten für die Community. Diese Option geht mal davon aus das sich Herr S, für ein freies Netz einsetzen wollte, er arbeitete an einem Projekt das vor den Diensten schützen soll/könnte und hat jetzt die Anschuldigung an der Backe das er genau diese helfen wollte.

    Fazit:
    S. hat’s programmiert Andere haben es durchgewunken. Die Hetze bringt nichts außer das sich Entwickler jetzt mehrfach überlegen an solch prominenten open source Projekten mitzuwirken aus Angst bei einem Fehler zerfleischt zu werden. Egal warum dieser (echt fiese) Fehler entstanden ist schadet die Hetze dem freien Netz. Im schlimmsten Fall haben die Dienste eine ihrer Quellen verloren und Entwickler haben Angst davor Fehler zu machen und bleiben in ihrem stillen proprietären Kämmerlein. Und genau das schadet meiner Meinung nach dem Netz wie wir es kennen.

    • way sagt:

      Nachtrag:
      Nutzt T-Systems eigentlich openSSL? Wenn ja (davon gehe ich mal aus) inwiefern engagiert sich ein Unternehmen mit solch enormen Ressourcen für ein Projekt wie openSSL? Solche Fehler hätten mit der Leistung die die Telekom zur Verfügung hat unterbunden werden.
      (Da ich mir nicht sicher bin was man denn aktuell glauben kann ist der Nachtrag unter der Annahme verfasst das Herr S, erst NACH dem Commit bei dem pinken T angefangen hat, so wie es an manchen Stellen, ich glaube auch bei erwähntem Blogger, zulesen war)

  7. Alex sagt:

    Dass man als Student schon mal einen nicht unüblichen Fehler begeht, kann schon sein.
    Dass man aber einen an sich sinnlosen Heartbeat implementiert, da es das Protokoll bereits kann, und dieser zudem noch einen Payload hat, ist schwer vorstellbar.
    Dass er dann auch noch übernommen wird, ist ein Witz.
    Als Konsequenz sollte man dringend Commits von Neulingen öfter überprüfen; Open Source bedeutet eben nicht, dass jeder daran arbeiten kann.

    Der Hauptpunkt ist aber, dass freigegebener Speicher nicht vor dem Freigeben und/oder Wiederbenutzen gelöscht wurde. Denn sonst würde Heartbleed gar nicht funktionieren. Insofern finde ich die Öffentlichkeit um die Längenprüfung falsch.

    • dos sagt:

      Ein “sauberer” Hauptspeicher, auf den ruhig auch mal falsch zugroße Zugriffe durchgeführt werden können, OHNE nicht AUCH ein Sicherheitsrisiko darzustellen, ist eine Illusion:

      Prozesse & Threads können ihr “Ende” längst nicht immer selbst bestimmen und demzufolge auch oft nicht für die nötigen “Aufräumarbeiten” sorgen, die Sie obligatorisch machen wollen und die eine Vergrößerung der Codierungsvolumina um 30% und der Laufzeiten vor allem zur Beendigungszeit bis zur ähnl. Größenordung nach sich ziehen würden.

      Mit eher besserem Recht wäre an die Übung zu erinnern, die Sie ebenfalls anklingen lassen: IN-ANSPRUCH-GENOMMENE Speicherbereiche/Variablen VOR ihrer (Teil-) Füllung mit evtl. unbekannt geringerer Datenbreite adäquat zu “löschen”, also mit unverfänglich-unwichtigen/sinnlosen Zeichen zu füllen, und dann erst eigene, gegebenenfalls kürzere, Inhalte darin zu platzieren. (Berufsschule)
      DAS hat hier mit Sicherheit nicht stattgefunden, hätte aber ebenfalls den Leak verhindert: Den Speicherbereich nach Maßgabe der falschen Längenangabe so zu INITIALISIEREN.
      Das muß aber schon in den Stackschichten unterhalb TLS/SSL passieren (wenn man nicht eine offenbar korrekte Requestrecord-Length hat, aus der die wahre Größe des Payloads errechnet werden kann”, wie das im Fix jetzt der Fall ist): Die offenbar gewordenen HS-Inhalte legen ja auch nahe, daß sie aus einem übertragungsnahen Bereich stammen können.

      Soweit ich bisher sehe/einen Eindruck habe/, IMPLEMENTIERT OpenSSL die TLS, setzt also die Spezifikation um, was die Beschwerde, die Heartbeat-Implementierung sei hier eh sinnlos, da das Protokoll das schon könne, ziemlich irre aussehen lässt, zumal sowohl der Payload darin, als auch dessen “Übernahme” (Rückgabe an den Client) eben auch zur Spez. gehört. (Über die Sinnfälligkeit der TLS-RFC wäre da zu streiten).

      In jedem Fall zeigt sich wieder das “Open”-Kriterium als NICHT in der notwendigen Weise belastbar, wenn es um SICHERHEITS-Fragen geht, selbst wenn man allen mehr oder weniger guten Faustregeln bis Allgemeinplätzen (“… dringend Commits von Neulingen öfter überprüfen”; Nicht jeder daran arbeiten) umsetzen könnte/wollte/sollte/dürfte.

      Die “Öffentlichkeit” um die Längenprüfungen ist eher noch zu gering: Das Längenparadigma ist der Kommunikations- u. Verarbeitungsarchitektur bis in die Prog.-Sprachen hinein inhärent: Gerade wohl auch deshalb bemüht sich die TLS-Spez. um eine Anzahl von VT_-Variablen, wie mir beim durchscrollen
      auffiel. Und die haben sich schon vielerorts bewährt, aber sie erübrigen NICHT die Fragen nach weiteren ähnl. Leaks im Netzwerk-Stack, der Frage nach der Rolle einer content-length-Angabe im Request-Header beim http usw.
      Faktisch brauchen wir (auch längen-) gecheckte Net-Stack-Varianten für die Allgemeinheit/User und für (BSI-?) zertifizierte Sites/Anbieter/Provider, ggfls. auch Check proprietärer Komponenten. (Staat+Geheimh.-Pflicht = Einsichtnahmerecht in “geschützte Werke”, notfalls OpenSource-Ersatz INDUZIEREN, d. h. ggfls. auch bezahlen, oder disassemble ff. usw.)
      Dabei sehe ich weniger SourceCode im Focus als vielmehr die Analyse von Traffic: Es würde mich wundern, wenn in der Entdeckungsgeschichte des Bugs die Trafficanalyse keine frühe Rolle spielen würde. Schon die Bastelei eines bzw. an einem Client(s) kann über einen bloß provisorisch falsch fixierten content-lengt-Header eine INTERESSANTE Ausgabe eines OpenSSL-Servers erzeugt haben …
      Ich jedenfalls bin fassungslos was und wieviel auch sonst da so rübergeht, wenn ich allein nur einen hochgefilterten Hook auf den FF-Ausgang (in eigener FF-Extension) lege (Requests), quellen in Sekunden SEITENWEISE Daten raus.
      Sowas ist gut, wenngleich teuer, systematisch testbar, aber eben nicht außschließlich durch Einzelpers. , Gruppen von Volonteers usw. Das setzt Mittel voraus, die gegenüber 19-Mrden-für-55-Leute-Deals sich wie ‘ne Pusteblume auf’m Heavy-Metal Konzert ausnehmen, aber eben auch nicht vom Himmel fallen. Von der Strukturierung (“ich fasse nix Proprietäres an”), Planung, Verantwortung und den Rechten bis zur Ausstattung hapert’s da noch.

  8. Amthor sagt:

    Nehmen wir mal an, die Welt sei gut und allen Menschen ist Altruismus angeboren.

    Nehmen wir weiter an, ein amoklaufender SSL-Client (!) sendet aufgrund eines Fehlers eine falsche Längenangabe.

    Nehmen wir zu guter Letzt an, die Längenangabe bezieht sich auf Adressen außerhalb des Speichers der Server-Applikation. Diese wir nun mit der berühmten “allgemeinen Schutzverletzung” aus der Prozesstabelle gekegelt und verabschiedet sich darob auf unerfreuliche Weise komplett.

    In C ist es ja so ziemlich das Erste, was man begreift, solche Dinge immer zu überprüfen. Und weiter ist es zwingend, bei allen “fremden” Daten zunächst Plausibilisierungen und “sanitizing” drüber laufen zu lassen. Ich kann mir nicht vorstellen, dass ein anerkanntes Open-Source-Mitglied zur Code-Änderung zugelassen wird, wenn es solche Fehler produziert.

    Dieser Programmierfehler ist so naiv und simpel und anfängerhaft, dass isch sehr wohl der Verdacht erheben kann, dass hier eine gewisse Absicht am Werk gewesen sein könnte.

  9. Pingback: OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts - Latest and fast news on India, World, State, Hacking, Sport, Science and Technology--cyber news adda

  10. Pingback: Is Heartbleed a bug or a backdoor? Is open source inherently insecure? - 4sysops

  11. Jule sagt:

    Komme ich deswegen jetzt nicht mehr in mein GMX Konto? Das PW stimmt zu 100 Prozent.

  12. Möglich, aber extrem unwahrscheinlich. In Wahrheit ist der Bug viel weniger schlimm als in den Medien dargestellt.

    Ich habe mein E-Mail- und mein Kundenpasswort nicht geändert, denn die Wahscheinlichkeit, dass irgendwelche Hacker angegriffen und genau das Stück Hauptspeicher erwischt haben, in dem MEIN Passwort stand, liegt, denke ich, bei <0,001 %.

    Es wurden ja kürzlich massenhaft E-Mail-Passwörter geknackt. Das könnte eher die Ursache sein. Um der Sache auf den Grund zu gehen, hilft die Seite des BSI weiter: https://www.sicherheitstest.bsi.de/

    Es kann auch sein, dass GMX ihren E-Mail-Server wegen der Geschichte mit den Heartbleed oder dem geknackten E-Mail-Passwörtern heruntergefahren haben. War bei meinem Provider auch so; witzigerweise informierte mein Provider weder auf seiner Internetseite noch per Mail darüber; entsprechend überlaufen war deren Hotline…

    Ich habe wegen einer anderen Geschichte ein kleines JAVA-Progrämmchen geschrieben, dass eine Testmail verschickt, und alle Schritte wie Verbindungsaufbau, Authentifizierung etc. protokolliert. Damit kann man die Fehlerursache eingrenzen. Könnte ich bei Bedarf zuschicken.

  13. Pingback: Heartbleed – Der Verschlüsselungs-GAU im Internet ← Pilzkuh

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


+ 2 = 10

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Mitteilen

Themenverwandte Artikel