Sehe ich das richtig, dass ich nun meine hochwertige Polyamidscheibe auf einen der wenigen Müllhaufen dieser Erde werfen kann, wenn dort OpenSSL mit Bug verwendet wird? Ich nutze LiveCD meistens für Homebanking.
Nein, das siehst Du falsch. Denn an deinen Rechner hinter dem Modem/Router kommt ja von ausen so leicht keiner ran.
Du solltest deine achsotollen LiveCDs sowieso regelmäßig wegwerfen. Denn die bekommen sonst überhaupt keine Updates. Auch nicht für den Browser. Und das ist viel wichtiger, als "Heartbleed".
Da Dieter schrieb: > achsotollen Recht hast Du. Aber wir nehmen sie deshalb, um vor den W-kompatiblen Keyloggern und anderem permanenten Gewürm sicher zu sein. Das scheint die realistischere Bedrohung zu sein.
(edit) Wenn Du das Paßwort wechselst, dürfte es ok sein. Die konkreten Verluste sollten durch das mTAN Verfahren geschützt sein. Und die NSA kennt sich sowieso auf Deinem Konto aus. Dabei möchte ich die Frage stellen, ob das https// Geheimdienst-sicher sei. Wenn sich Zertifizierungsstellen in USA befinden, müssen sie doch Einblick in ihre Daten gewähren? Da sind dann zuerst die Private Keys betroffen? Also, https hilft nur gegen Kleinkriminelle, die Offiziellen haben Nachschlüssel.
Daniel schrieb: > Sehe ich das richtig, dass ich nun meine hochwertige > Polyamidscheibe > auf einen der wenigen Müllhaufen dieser Erde werfen kann, wenn dort > OpenSSL mit Bug verwendet wird? ja > Ich nutze LiveCD meistens für Homebanking. Eine LiveCD ist veraltet, sobald sie beim Nutzer ankommt :( Einen Teil der Sicherheitslücken kann man prinzipbedingt weder von einer LiveCD noch von einem festinstallierten Betriebssystem fernhalten, nämlich die sog. Zero Day Exploits. Mit denen muss man leben, manchmal jahrelang. Ein Beispiel ist die kürzlich bekannt gewordenen Sicherheislücke von Openssl, die vor rund 2 Jahre entstanden ist. Vermeiden lassen sich nur Sicherheitslücken, welchen den betroffenen Entwicklern bereits bekannt geworden und bereits beseitigt und bereits in die betreffende Linux-Distribution eingearbeitet und bereits in die angebotene LiveCD übertragen worden sind. Zwischen der Entdeckung einer Sicherheitslücke und deren Behebung in einer LiveCD liegt eine Zeitspanne, deren Länge sich schlecht vorhersagen läßt. Manche Linux-Distributionen lassen sich mit der Überarbeitung ihrer LiveCDs mehr Zeit, als mit dem Einspielen korrigierter Programmpakete in die Betriesbssystemversionen, die fest installiert werden. Bei manchen Distributionen kommen allein in diesem Punkt etliche Monate zusammen. Deshalb hinken LiveCDs sicherheitstechnisch festinstallierten Betriebssystemen, solange jene vom Nutzer laufend aktuell gehalten werden. Gegenüber LiveCDs zeigen festinstallierte Betriebssysteme den Nachteil, dauerhaft manipuliert werden zu können. Bei einer LiveCD ist man sich wenigstens sicher, immer wieder denselben Softwarestand ohne zwischenzeitliche Manipulationen durch böswilliger Hacker einzusetzen. Fast alle LiveCDs können die Platte als Zwischenspeicher nutzen. Diese Möglichkeiten sollte man genau kennen und unterbinden können, will man auf Nummer sicher gehen. Gefährlich sind in diesem Zusammenhang LiveCDs die automatisch auf der Platte nach angelegten Zwischenspeichern suchen. Verfügt der Rechner über keinen veränderlichen Speicher (Platte, eingesteckter USB-Stick oder Speicherkarte), braucht man sich darüber keine Gedanken machen. Man kann allerdings die Vorteile der LiveCD (unveränderlich) mit den Vorteilen eines laufend aktuell gehaltenen festinstallierten Betriebssystemes (aktueller) verbinden, indem - man die LiveCD nach jedem Sicherheitsupdate der Distribution selber erzeugt, - das aktuell gehaltende Betriebssystem mit geeigneten Vorkehrungen anstelle der LiveCD übers Netzwerk bootet, ohne dass der Rechner, der das Boot-Image zur Verfügung stellt, nach dem Booten noch gebraucht wird. Beide Alternativen lassen sich automatisieren. Der Aufwand für Erst-Installation und laufende Aktualisierung fällt natürlich höher aus, als der schlichte Einsatz einer LiveCD, die ab und zu herunter geladen wird. Manche Linux-Distributionen bieten etliche Hilfsmittel an. Noch ein Hinweis: Die LiveCD bzw. das Betriebssytem auf dem Rechner, der zum Surfen verwendet wird, repräsentiert nur eine der vielen technischen Komponenten, die beim Homebanking verwendet werden. Wurde das Bios auf dem Mainboard, das BIOS auf der Netzwerkkarte, der eigene Router, der Router des Providers oder die gar die Webseite der beteileigten Bank manipuliert, können alle Bemühungen, das eigene Betriebssystem sicher zu halten, ins Leere laufen. Noch ein zweiter Hinweis: LiveCDs lassen sich meistens auf einen USB-Stick übertragen. So kann Müll verringert werden. Vom USB-Sticks laufen LiveCDs deutlich schneller, als von CD-ROMs. pv
abc.def schrieb: > Dabei möchte ich die Frage stellen, ob das https// Geheimdienst-sicher > sei. Wenn sich Zertifizierungsstellen in USA befinden, müssen sie doch > Einblick in ihre Daten gewähren? Da sind dann zuerst die Private Keys > betroffen? Also, https hilft nur gegen Kleinkriminelle, die Offiziellen > haben Nachschlüssel. Es ist völlig egal ob "der Geheimdienst" den privaten Schlüssel der Zertifizierungsstelle kennt oder nicht, da DEIN privater Schlüssel nie bei der Zertifizierungsstelle landet. Und auch jede Sitzung hat eine neuen "privaten" Schlüssel. Siehe http://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Ansonsten eröffne doch bitte für neue Fragen auch einen eigenen Thread, mit LiveCDs hat das nun wirklich nix zu tun.
Heartbleed eröffnet dem Kommunikationspartner einige Möglichkeiten, etwas über den Speicherinhalt vom SSL der anderen Seite zu erfahren. Wie kritisch ist das aber im konkreten Fall? Setzt mal die defekte Version auf einem Server ein, dann kann ein Client z.B. den privaten Schlüssel des Servers ermitteln und sich damit als dieser Server ausgeben. Oder ggf. Teile der Kommunikation anderer Sitzungen mitkriegen. Setzt man sie auf einem Client ein, dann kann der Server nicht viel mehr vom Client erfahren, als er sowieso schon weiss, vorausgesetzt es liefen davor keine anderen geschützten Sitzungen im Browser. Die Empfehlung zu sicherheitskritischen Webseiten war schon bisher: Browser davor und danach schliessen. Ausnahme: Der Client besitzt ein offizielles Client-Zertifikat. Das ist aber ausgesprochen selten der Fall. Den Browser zu schliessen kann aber je nach Plattform umständlich sein. Mindestens auf Mobilplattformen wie Android kriegt man die z.T. nur über Task-Killer wirklich geschlossen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.