Beiträge von Oliver222

Börsenfeger erwiderte Folgendes:

Zitat

[...]das ich Norton 360 nicht empfohlen habe, würde ich nie tun, sondern das das Teil vom TO benutzt wird....

Mir fehlt manchmal die Zeit.

Du hattest diesbezüglich Recht.

Oliver

Boersenfeger erklärte u.A. Folgendes:

Zitat

In Deinem System fehlen einige System-Dateien.

Welche genau?

Vermagst Du diese fehlenden Systemdateien genau zu benennen – Oder klugscheisst Du nach alter Manier fortschreitend voran?

Boersenfeger stellte darüberhinaus Folgendes dar:

Zitat

Konfiguriere Norton 360

Warum Norton?

Ist Dir eigentlich klar, was eine Norton-Verfügung auf einem bereits lokal installierten System – gegenüber unbedarfter Nutzer - verursachen kann? Die Thematik lässt sich historisch recherchieren (z.B. nicht löschbare Prozesse / rootkitfunktionen der Norton-Firewallfunktion, etc.).

Die Relevanz „persönlicher Systemerkenntnisse“ (jedes einzelnen Nutzers) sollte – meiner Meinung nach - definitiv Deinen hier unterbreiteten Ratschlägen voranstehen.

Unterlasse von daher bitte die Empfehlung kostenpflichtiger Anti-Viren Programme, von denen Du scheinbar selber nichts verstehst.

Oliver

Steph erklärte u.A. Folgendes:

Zitat

[...]Weiß es nicht, aber zumindest network.http.accept.default müsste/sollte wohl auch geändert werden in */*, da z. B. Opera und IE wohl eine andere HTTP_ACCEPT-Zeichenkette verwenden.

Firefox arbeitet mit eigenen „Header-Berwertungsvariablen“. Opera auch. Der IE ist dagegen separat zu betrachten.
Das Setzen eines Jokers (Platzhalters) / (*/*) innerhalb so eines ausgesandten Headers würde – meiner Ansicht nach – keinen Sinn machen, da ein wie auch immer gearteter Browser – im Zuge seiner Anfrage an einen Server – (über die HTTP-Spec.) wiederum auf eine korrekte und detailgetreue Wiedergabe der angefragten Daten selber angewiesen ist. Innerhalb des Header-Abfragevektors wäre Dein Verfahren – bei gleicher Wertstellung (*/*) - somit nicht sinnvoll umsetzbar, da nicht definierbar – bzw. durch die Firefox-Spezifikation sogar qualitativ herabgesetzt – was nicht das schlechteste ist.

Stichwort: „Browserkriege“.

XML > HTML. Gerade die Aushandlungen der verschiedenen Inhalte und Darstellungsmöglichkeiten (engl. content negotiation) zwischen lokalem und remote Systemen (Client / Server) führt – meiner Ansicht nach – im Zuge des fortschreitenden Webkits / JavaScript zu einer fortführenden Verletzung der ursprünglichen HTTP-Spezifikation.

Was den IE angeht, so ist dieser darüberhinaus i.d.L. lokale MS-Applikationen als Referenzen wiederum in seinen variabel gestaltbaren HTTP-Accept-Header einzuspeisen – um somit u.A. auch Informationen über lokal installierte MS-Produkte übertragen zu können.

Jeder Browser unterliegt – meiner Ansicht nach – immer auch einem „Geschäftsmodell“.

Dezentrale Installationsverteilungen können heutzutage bequem anonym über unverschlüsselte Verkehrsdaten abgerufen werden.

Oliver

Black Disk erfragte Folgendes:

Zitat

[...]würde gerne wissen, wie ich im Browser abschalten kann, das Internetseiten wissen, welchen Browser ich verwende und welches Betriebssystem ich habe.

Metadaten (also die Headerdaten (Verwaltungsdaten) einzelner IP-Pakete) lassen sich nicht „abschalten“. Diese Option ist innerhalb der HTTP-Protokoll-Spezifikation nicht vorgesehen.

Allenfalls vermagst Du durch diverse lokal eingebundene Proxies - innerhalb eines wie auch immer gearteten Browsers - die Metadaten solcher IP-Pakete sinnvoll zu „verändern“ (bzw. zu Deinem Nachteil zu „verfälschen“).

- Proxomitron
- Privoxy
- Squid

Der Grund liegt darin, dass solche „Metadaten“ (also die zusätzlichen „Verwaltungsinformationen“ solcher IP-Pakete) einen wesentlichen Bestandteil des HTTP-Protokolls selber darstellen und somit keine Tilgungen der Headerinformationen selber zulassen können, da sonst eine Kommunikation zweier digitaler Endpunkte (z.B. zwischen Deinem Rechner und dem Internet) nicht aufgebaut - bzw. nicht sinnvoll geroutet werden kann.

O.T.
Die sog. „Fragment-Offset-Information“ - als Komponente der Header-Information so eines IP-Datenpaketes - liefert z.B. wesentliche Informationen darüber ob - und wie genau so ein IP-Paket im Zuge seiner Wegwahl fragmentiert werden darf.

bugcatcher erklärte u.A. Folgendes:

Zitat

Ich würde einfach die Finger von dem Unsinn lassen.

Welchen Unsinn? Geschäftsmodell - Oder take back the Web?

Oliver

Shinzon erklärte u.A. Folgendes:

Zitat

[...]Nur kommt mein manuell gestartetes Vidalia nicht an's Tornetzwerk ran.[...]

a. Welches Betriebssystem benutzt Du?

b. Unterliegen innerhalb dieses OS (z.B. Windows 7) individuelle Rechtevergaben einer lesenden Zugriffsbeschränkung?

c. Synchronisierst Du den „Portable-Firefox" mit sog. lokalen „Host-Terminal-Systemen“ (z.B. mit Firmenrechnern)?

- Verschaffe Dir zur Installation des „TOR-Browser-Pakets“ kurzfristige System-Privilegien.
- Passe darüberhinaus den Pfad für „Polipo“ - als lokales Proxy-Argument - an das Vidalia-Bundle an.
- (C:\Program Files (x86)\Vidalia Bundle\Polipo\((polipo).exe/*.conf))).

Oliver

O.T.
Eine Anpassung des allgemeinen TCP/IP-Stacks (also der Protokollschichten einzelner Datenpakete / over OS) wäre erforderlich, um Vermittlungen über einen lokal-anonymisierenden „Socks-Proxy“ führen zu können. Kritische Informationen liessen sich somit zwar vor ihrer Weiterleitung aus den Header-Feldern der einzelnen Datenpakete heraus weitgehendst entfernen oder verfälschen (engl. cloaking) – jedoch ist meiner Meinung nach - somit noch keine wirkliche Anonymität erreicht, da diese Header-Daten allenfalls „gekapselt“ - dagegen jedoch nicht „verschlüsselt“ werden.

hal77 fragte Folgendes:

Zitat

a.) Daß Webseiten, die zwar eine gesicherte https://-Verbindung dem Besucher auf ihrer Webseite zusagen, dies jedoch nicht im Internet Browser mit https:// sowie optisch in der Adresszeile (grün, blau, gelb) rückmelden, für eine sichere Datenübertragung als unsicher einzustufen sind?

Nein.

Webseiten können gleichzeitig aus gesicherten, sowie aus ungesicherten Elementen bestehen. Webseiten, welche sich in ihrer Gesamtheit mosaikartig einerseits aus ungesicherten Elementen (über http) – sowie andererseits aus gesicherten Bestandteilen (http(s)) zusammensetzen, können zwar vordergründig in der Browser-Anwahl (also als erstmaligen Abruf in Deiner URL-Leiste) als unsicher dargestellt werden. Das vertrauliche Log-In solcher passwortgeschützten Zugangskontrollen würde sich dann einem relativ gesicherten SSL-Protokoll beugen müssen, welches jedoch keine Verbindlichkeiten der E2E-Verbindungen ermöglicht. Darüberhinaus werden unter solcher SSL geschützten Vermittlung nur die Nutzerdaten der IP-Pakete verschlüsselt, was wiederum Verkehrsflussanalysen über die unverschlüsselt verbleibenden Header ermöglicht.

a. Automatische Umstellung der Anfrage auf das allgemeine (Handshake / Server-Client) SSl-Verfahren zweier Kommunikationsendpunkte. (Sichtbar in URL-Leiste).

b. Verschlüsselung der vertraulichen Zugangsinformationen über ein serverseitiges „PHP-Script“. (Vermutlich das, was Dein Support erwähnte).

Zitat

b.) Selbst dann, wenn im Quellcode der Webseite eine Verschlüsselung per Link eingebettet ist, welcher auf einen sicheren Verbindungsaufbau hinweisen könnte?[...]

Lässt sich der von Dir genannte Webauftritt mit einem vorangestellten „http(s)“ in der Browser-Zeile von vornherein unter vertraulichen Voraussetzungen erneut starten? (z.B. wie bei GMX?). Du gibst diesbezüglich bedauerlicherweise sehr wenige Informationen preis.

Zitat

c.) Dass aufgrund des vorgenannten Links sich kein gesicherter Verbindungsaufbau für den Besucher herleiten lässt, auch wenn der Support folgende Aussage macht: "Die Verschlüsselung geschieht über ein Script und wird daher nicht in der Adresszeile in Form von https:// angezeigt.

Siehe oben...

Vertrauliche Datenübertragungen liessen sich darüberhinaus mit Hilfe des Kommandozeilenprogramms (cmd) unter Windows (netstat -ano) - in Verbindung mit dem Task-Manager - auf ihre Sicherheit über „port 433“ hin überprüfen.

Oliver

hal77 erwiderte u.A. Folgendes:

Zitat

[...]Vielen Dank für Deine Erläuterungen, welche ich mit großem Interesse las!

Zögere nicht explizit nachzufragen. Dafür sind wir alle hier.

Hauptrache Du kannst eine (technische) Erkenntnis gewinnen...

Wissen = Dienen.

Oliver

hal77 erklärte u.A. Folgendes:

Zitat

[...]Nun, kürzlich unterbreitete mir ein Support eine neue "Sicherheitsvariante“: Verschlüsselung per Skript.[...]

Eine durch individuelle Scripte geführte lokale Verschlüsselung setzt – meinen bisherigen Erkenntnissen nach – stets voraus, das die kommunikative Gegenstelle (also Dein Kommunikationspartner) zur Dekodierung solcher vertraulichen Daten im Besitz des gleichen Scripts ist. Das „gemeinsame Geheimnis“ muss somit im Vorfeld bereits zwischen den einzelnen Kommunikationspartnern abgesprochen - bzw. ausgetauscht worden sein, um von daher eine Informationsvertraulichkeit (Information nicht einlesbar) und darüberhinaus auch einen Bezug zum Datenursprung (Identität nicht abstreitbar) gewährleisten zu können.

Unabhängig davon, existieren öffentlich zugängliche ASCII-Zeichen Kodierungsverfahren z.B. Base64, die jedoch in Bezug auf eine vertrauliche Fernkommunikation nicht als sicher zu betrachten sind.

hal77 fragte darüberhinaus Folgendes:

Zitat

[...]Und da habe ich mich eben gefragt, ob es angehen kann, dass es ein Skript gibt, welches eine gleichwertig verschlüsselte Datenübertragung gewährleistet wie per https://??[...]

Das lässt sich nicht vergleichen.
Eine Ende zu Ende Verschlüsselung des allgemeinen SSL-Protokolls (HTTPS) auf der „Transportebene“ (also Schicht 4 des OSI-Modells) ist in Bezug der „kryptografischen Stärke“ zwar als relativ sicher zu betrachten. Da die übertragenen Daten im Zuge so eines HTTPS-Verfahrens jedoch nicht signiert werden, ist somit leider die „Verbindlichkeit“ der Übertragungen nicht gesichert.

Fazit: Verschlüssele Deine vertraulichen E-Mail Texte separat. Im Zuge von z.B. Passwort-Umstellungen über gesicherte HTTPS-Webseiten, bist Du jedoch auf die „Sicherheit“ des allgemeinen SSL-Protokolls angewiesen.

Gruss nach Mexico – Lange war es her.

Oliver

http://www.multi-online.com/netzwerk/osi.php

aborix erwiderte Folgendes:

Zitat

[...]Vielleicht Malware, die keine Admin-Rechte hat?

Ist Malware nicht gerade auf „Admin-Rechte“ angewiesen?

wull

Benutzt Du Windows?

Du vermittelst im Vorfeld leider wenig Informationen - jedoch vermag kein Browser Deine Cookie-Einstellungen selbständig zu verändern.

a. Sofern Du Windows benutzt und darüberhinaus eine Kompromittierung Deines Systems (also Viren) als ausgeschlossen gilt/gelten, so lösche Deinen aktuellen Firefox (als bisherige Anwendung aus der Windows-Registry / also aus der bisherigen Windows-Anwendungsumgebung heraus) und installiere im Anschluss daran den Firefox-Browser erneut über eine dedizierte und vertrauenswürdige Bezugs-Adresse. Entscheidend ist dabei jedoch, das auf die „alten“ Anwendungsdaten (des bisherigen Firefox-Browsers) nicht mehr zurückgegriffen werden kann. Achte dabei auf veraltete Einträge in der Windows-Registry. Diese müssten gelöscht werden.

b. Sofern Dein OS (also Dein Betriebssystem) jedoch (durch Viren) kompromittiert (beeinflusst) sein sollte, so stelle es von Grund auf erneut her. Vermeide dabei die Windows-Wiederherstellungskonsole, da u.U. diese Form der systembedingten Behebung in der Lage wäre, nur sog. „Snapshots“ (Schnappschüsse) aus der bereits schon infizierten Arbeitsumgebung (Windows) selber erstellen zu können.

Oliver

O.T.
Cookies sind passive und harmlose Textdateien.

Mittels solcher abgelegten Cookie-Daten wird – meinen Informationen nach - jedoch versucht, serverseitig das bisher (anonyme) und zustandlose HTTP-Protokoll lokal auf den Computern der einzelnen Nutzer verbindlich (also als relativ sichere „Ende-zu-Ende-Verbindung“) zu gestalten. (Cookies als sog. Vermittlungs-Anker).

Das sog. „Austauschkonzept“ der Cookie-Daten erfolgt darüberhinaus – zwischen Server und lokalem System – im Hintergrund ohne Einflussnahme des jeweiligen Nutzers, was durchaus datenschutzrechtlich in Frage gestellt werden könnte. (ePrivacy / GB). Weiterführender Link untenstehend.

Vielleicht wäre ein allgemeines „Cookie-Konzept“ denkbar, welches als lokal abgelegte Datenstruktur einem fristgerechtem Verfallsdatum unterläge und sich somit "von selbst löschen" könnte.

http://www.unwatched.org/node/2035

eike42 erfragte u.A. Folgendes:

Zitat

[...]suche einen Link oder eine Aussage, auf welche Weise die gespeicherten Passwörter im Firefox abgelegt sind, also ob das Masterpasswort eine Rolle bei der Verschlüsselung spielt und welches Verfahren angewandt wird.

a. Der Algorithmus des Masterpasswortes (Firefox 2/3) folgt – meinen bisherigen Informationen nach – einem veralteten, symmetrischen 3DES-Verschlüsselungsverfahren, welches in der heutigen Zeit nicht mehr als sicher betrachtet werden kann, da der zugrundeliegende „Schlüsselraum“ dieser Hashfunktion nur 2^112 verschiedene Kombinationen gewährt (!), was zukünftig jedoch als unzureichend gilt. Eine sichere Verwahrung der individuellen digitalen Schlüssel ist von daher für die Masterpasswort-Sicherheit vordringlicher, als die kryptographische Stärke der einzelnen Passworte selber.

b. Firefox lässt darüberhinaus ein Zurücksetzen der vertraulichen PW-Daten zu, sofern ein Anwender einen erfolgreichen Zugriff auf die Betriebssystemkonten erwirkt. Damit ist der Firefox-PW-Manager für sensible Authentifikations-Massnahmen indiskutabel.

c. Neben der kryptographischen Stärke der Hashfunktion selber, sollte obendrein eine separate Zugriffs – und Rechtebeschränkung des zugrundeliegenden Betriebssystems gelten. Dies gilt – meinen Kenntnissen nach – vorrangig für lesende Zugriffe, welche u.U. i.d.L. sind, die „temporären Ablagen“ solcher vertraulichen Passwörter im Klartext auslesen zu können.

Oliver

http://luxsci.com/blog/master-pa…hunderbird.html
http://en.wikipedia.org/wiki/3DES
http://en.wikipedia.org/wiki/Template_talk:Crypto_block

eike42 erklärte u.A. Folgendes:

Zitat

Ich dachte auch immer […] dass die Passwörter MIT DEM MASTERPASSWORT verschlüsselt werden, so dass niemand ohne das Masterpasswort an die gespeicherten PW drankommt.

Das ist richtig, solange Dein Masterpasswort innerhalb der Firefox-Arbeitsumgebung (also im Browser selber), durch eine relativ gesicherte Authentifikation - z.B. durch willkürlich gemischte ASCII-Zeichen – definiert wird.

Eine vertrauliche Passwortverwaltung innerhalb des Firefoxes ist – meinen bisherigen Erkenntnissen nach - dennoch als rudimentär und somit auch als unsicher zu bezeichnen, da die „Ablageorte“ dieser vertraulichen digitalen Passwortdateien, innerhalb des zugrunde liegenden Betriebssystems (z.B. Windows), kompromittierbar sind.

eike42 erklärte darüberhinaus Folgendes:

Zitat

[...]Das ist wichtig für mich, mein gesamtes Sicherheitskonzept basiert darauf, dass die Leute, die sich als Admin an meinem Rechner einloggen können, zumindest nicht meine Passwörter auslesen können.[...]

Von welchem Sicherheitskonzept sprichst Du? Hast Du überhaupt eins?

eike42 erklärte schlussendlich Folgendes:

Zitat

[...]ist natürlich Schwachsinn, sobald ich den Rechner von CD starte und mir das FF-Profil kopiere, habe ich alle Logins.[...]

Voraussetzung ist dabei jedoch, dass entweder ein direkter Zugriff auf das Benutzerverzeichnis des OS (z.B. Windows) selber besteht oder jemand darüberhinaus in den Besitz der vertraulichen Passwort-Dateien: (key3.db / cert8.db / signon.sqlite / *3.txt / *2.txt) gelangt.

Passwortbasierte Zugriffskontrollen stellen auf Systemebene (z.B. Windows) die Gesamtheit Deines Sicherheitskonzeptes dar. Der Browser ist dagegen bloss ein Bestandteil dieses sicherheitskritischen Zugriffs-Verfahrens.

Eine Schwierigkeit entsteht obendrein noch dadurch, dass heutige Systeme (Betriebssysteme oder einzelne Prozesse so eines Betriebssystems) sich nicht gegenüber ihren Nutzern authentifizieren können.

Im übertragenen Sinne ausgedrückt, möchtest Du auch nicht in einem „Sportwagen“ Platz nehmen wollen, der mit Dir zusammen zwar alle Rennen gewinnen würde, dessen Bremsen jedoch nicht funktionieren, obwohl Du angeschnallt bist.

Oliver

Börsenfeger stellte Folgendes dar:

Zitat

Verwende in Zukunft Optimize Google und stelle es entsprechend ein.

@Börsenfeger:
Bei allem Respekt, aber eine dümmere Antwort hättest Du hier – meiner Ansicht nach – in Bezug der vorangestellten Thematik nicht verlautbaren lassen können. Was hat die lokal (im Browser) wirkende Erweiterung „Optimize Google“ mit der Tatsache zu tun, dass Google die über den Browser angeforderten Verlaufsdaten dennoch kontinuierlich indexiert und auswertet?

Dir ist darüberhinaus schon klar, dass es einen relevanten Unterschied ausmacht, ob im Zuge eines unfreiwilligen Informationsflusses angeforderte anonyme Verlaufs-Daten innerhalb des Google-Systems selber hinterlegt werden - oder ob Teilnehmer in der Vergangenheit bereits persönliche Daten offenbarten, welche einen individuellen Informationsgehalt darstellen, der normalerweise aus den Google-Server System sofort zu tilgen wäre.

Oliver

allure erklärte u.A. Folgendes:

Zitat

[...]Aber statt hier so großspurig den Wert der Daten zu preisen (,) würde ich sagen: Einfach mal machen[...]

[...]wurde von einigen Teilnehmern – gemäss der Datenschutzbestimmung Googles in Bezug auf die Liquidierung personenbezogene Daten - bereits erfolglos versucht.

Obendrein werden solche, von Google „anonym“ (z.B. über den Firefox) gesammelten Daten – meinen Kenntnissen nach – gebündelt und darüberhinaus erwerbsmässig in Form von diversen gesammelten Zugriffsprofilen weiterveräussert. Der Firefox stellt innerhalb dieses Prozesses bloss ein Bestandteil eines überregionalen Geschäftsmodells dar. Der „Kunst“ Googles verbleibt es somit letztendlich vorbehalten, aus dem bereits angelaufenen und anonymen Datenpool (Puzzle), die fehlenden Lücken über mathematische Algorithmen zu einem (anonymen) und dennoch realen digitalen Gesamtbild zu vervollständigen.

allure stellte darüberhinaus u.A. Folgendes dar:

Zitat

[...]Google ist sehr um die Zufriedenheit seiner User besorgt[...]

Deine Werbung ist hier (ironisch) anzuerkennen. Wir profitieren darüberhinaus alle von den (kostenlosen) Errungenschaften (F+E) Googles. Die Kosten, welche jedoch eine schnelle und unwiederbringliche dedizierte Löschung individuell-persönlicher, bzw. bereichsrelevanter Daten aus dem Google-System erfordern würden, sind scheinbar mit den Aufwänden solcher Löschungsverfahren aus diesem Informations-Intranet nicht zu vereinbaren – sofern keine direkten Zahlungen für solche Liquidierungen vorliegen. Google Datenschutzbestimmungen unterliegen zuguterletzt dem Britischen und US-Amerikanischen Rechtssystem, welches i.d.R. eine etwas weiter gefasste liberalere Handhabung solcher bereitwillig veröffentlichen Daten vorsieht.

allure erklärte zuguterletzt Folgendes:

Zitat

[...]oder Freemail anschreiben.[...]

Freemail < > Freenet.

Weisst Du überhaupt, wovon Du hier sprichst?

Oliver

http://www.google.com/intl/de/privacypolicy.html

Brummelchen erklärte Folgendes:

Zitat

Heute ist mein Glückstag - zwei Komiker an einem Tag, herrlich[...]

Zustimmung.

Unabhängig vom Thema und darüberhinaus umgangssprachlich etwas weiter gefasst, stellt das Mozilla-Modell - meiner Ansicht nach - die „Hure“ Googles dar.

a. Mozilla Foundation > Mozilla Corp..

b. Mozilla Foundation ≠ Mozilla Corp.. Die erste Instanz darf offiziell kein Geld verdienen. Die zweite darf es.

c. Gewinne der Mozilla Foundation können somit an das Tochterunternehmen Mozilla Corp. abgeführt werden.

d. Innerhalb der einzelnen Leistungsbereiche der Mozilla-Foundation kann von daher über eine sog. „Indexkostenrechnug“ dem erwerbswirtschaftlichen Prinzip (Konzern / Unternehmen) gefolgt werden, welches wiederum Gewinne „abführen“ und auch „abschreiben“ darf. Genaue Zahlen werden durch die Mozilla-Foundation jedoch nicht veröffentlicht. Vermutlich aus gutem Grund, um die „vertrauensselige Gemeinde“ nicht ganz zu erzürnen.

Fazit: Ein Ansatz für zukünftige Firefox-Installationen liesse sich – meiner Meinung nach - vielleicht über ein allgemein geführtes und formales Opt-In als Sicherheitsmodell realisieren. Das würde bedeuten, dass der Firefox ab Installation ohne zusätzliche Einwirkungen (z.B. JS, Java, Flash, Cookies, etc.) installiert werden würde, um dann erst über einzelne benutzerbestimmbare Zugriffsrechte nach individuellen Bedarf angepasst werden zu können. Werbefirmen (sowie Datenkollektoren) wie [x+1] (die sich einer sog. „digital cross reference targeting technology“ bedienen), könnte durch diese Massnahme - im Ansatz - erfolgreich entgegengewirkt werden.

Roadrunner:
an Deinen (gutgemeinten) Beitrag glaubst Du selber nicht?

Wie viele digitale Entfernungs-Anträge wurden bereits über „Formal-Fehler“ erfolgreich durch Google abgelehnt?

Was „kostet“ darüberhinaus das erfolgreiche „Zurücksetzen“ bereits eingespeisster digitaler Informationen? (Gemessen am "Wert" der Informationen vs. den Kosten eines digitalen Liquidierungsverfahren aus den Server-Caches so eines Unternehmens)?

Oliver

Fox-Laie stellte u.A. Folgendes dar:

Zitat

[...]Irgend etwas scheint [im Zuge des Firefoxes] so verändert worden zu sein ( ich vermute i.d. Sicherheitseinstellungen ), dass ich keinen Zugang mehr zu meinen Banking-Account [Deutsche Bank] herstellen kann.[...]

Mit dem Browser hat das von Dir vorgestellte Verfahren nichts zu tun. Das HTTP(s)-Protokoll selber wäre für solche vertraulichen Online-Zahlungssysteme in der heutigen Zeit zu „trivial“. Es bedarf darüberhinaus weiterer unabhängiger Zusatzprogramme (z.B. Java), um die verbindliche Fernkommunikation (also Schnittstelle: Home / Bank) - in Bezug auf solche vertraulichen Transaktionen - weitgehendst juristisch absichern zu können.

a. Benutzt Du für Deine vertraulichen Zugänge vielleicht eine sog. smartcardbasierende Authentifikation (z.B. über einen zur Verfügung gestellten proprietäre Kartenleser / incl. JavaChipkarte)?

b. Lässt Du darüberhinaus XML als gesichertes Kommunikationsprotokoll (i.d.F. SEPA) zu?

In Deinem Fall sollte es u.U. erforderlich sein, neben einem wie auch immer gearteten Browser obendrein auch die Java-Version auf einem aktuellen Stand zu halten.

Oliver

O.T.
Biometrische Zugänge > Java-Smartcards.

Bezüglich der transportablen Lesegeräte – der Sicherheit der individuellen Authentifikationen – sowie auch der gesicherten Übertragungen und serverseitigen Ablagen solcher vertraulichen Informationen – stossen wir scheinbar an einen „Zielkonflikt“. Wie wären z.B. eventuelle Datenverluste „kostentechnisch“ (über Versicherungen) langfristig in Bezug zu den höheren Aufwendungen sicherer Neuanschaffungen zu setzen?

angelheart erklärte u.A. Folgendes:

Zitat

[...]Das Turnier hat Afrika weiter gebracht.

Bist Du Dir diesbezüglich so sicher?

So naiv wie Du kann eigentlich kein Deutscher / Europäer / bzw. Weltbürger sprechen.

Was stellt Afrika – im Zuge Deiner Weltanschauung - für Dich überhaupt dar? Afrikanisch gesprochen?

Besteht Afrika nicht eher aus einem Kontingent (und Kontinent) unterschiedlicher Nationen, Regierungen, Kolonien, Sprachen und darüberhinaus noch unterschiedlicher Dialekte innerhalb der einzelnen Sprachen selber?

Sind es darüberhinaus nicht doch eher die überregionalen Investoren, welche sich wiederum im Anschluss aus dem „Ereignis“ (der WM 2010) unmittelbar zurückziehen werden?

Was zurückbleiben wird, sind Neubau-Ruinen (Stadien / Unterkünfte / vorfinanzierte Infrastrukturprojekte etc.) – gefolgt von einer Schuldenlast in zweistelliger Mrd. Höhe - welche langfristig über lokale Schuldverschreibungen an die sog. creditors Kreditgeber (in diesem Falle: GB / Germany / France, etc.) zurückgeführt werden müssen.

Der aktuelle Wechselkurs (Rand / Euro) kann darüberhinaus für keine Amortisation (termingerechte Rückzahlung) der bereits getätigten Investitionen sorgen, da der Aufbau solcher Stadien, Verkehrswege, etc. u.A. weitgehendst durch europäische Firmen getätigt wurde.

Profitiert – im Zuge so einer WM - Afrika oder doch eher Siemens?

Die WM stellt in erster Linie ein Geschäftsmodell dar. Der Sport selber tritt dabei erst an zweiter Stelle auf.

Setze Dich („angelheart“) bitte noch einmal auf den Hosenboden und fange langsam an zu lernen und verschone uns darüberhinaus von Deinen hier dargestellten, eindimensionalen Ansichtsweisen.

Oliver

Tante Tarantel erfragte Folgendes:

Zitat

Schön wäre natürlich, wenn der Verkehr ab Modem/Router generell verschlüsselt wäre. Ist so etwas realisierbar?

Ja – Jedoch ist diese Vorgehensweise weder konsequent - noch qualitativ in Bezug auf die gewünschte Verschlüsselung sinnvoll.

Platt ausgedrückt ist so ein Router nicht i.d.L. als allgemeine Vermittlungskomponente eine Kommunikationssicherheit auf der Transportebene (des OSI-Modells) selber zu garantieren, da dieser (Router) logischerweise auf der untersten Netzwerk-Schicht moderieren muss, um als "kleinster gemeinsamer Nenner" überhaupt einen im Ansatz verschlüsselten Datenfluss zwischen heterogenen Systemen / Netzwerken gewährleisten zu können.

Unterscheide darüberhinaus zwischen der privaten Verschlüsselung (Deines persönlichen Netzwerkes / Intranets) - und dem öffentlich zur Verfügung stehenden Verschlüsselungsprotokolls des Internets.

So ein Router grenzt Dein lokales Netzwerk bloss vom I-Net ab und folgt obendrein einem qualitativ schlechtergestellten kryptographischen Verfahren, da innerhalb dieser Vermittlungsschnittstelle (also dem Router) die zu übertragenen, verschlüsselte Datenpakete vorübergehend im Klartext zwischengespeichert werden können.

In der Regel gilt somit: Verbindungsverschlüsselung (Router) < als E2E-Verschlüsselung (Anwendungen / Prozesse).

Um daher eine weitgehendst sichere E2E- (Ende-zu-Ende) Verschlüsselung auf Deinem System zu realisieren wärst Du – meiner Ansicht nach - gut beraten, lokale Anwendungen und Prozesse darüberhinaus an individuelle Benutzer-Konten des OS zu knüpfen.

Oliver

bugcatcher erklärte u.A. bisher Folgendes:

Zitat

[...]Das heißt, jeder Server weiß nur soviel über dich, wie Du an Anfragen an ihn gestellt hast.[...]

Meiner Einschätzung nach gut erklärt. Server unterschiedlicher Domains (Intranetze) können dennoch untereinander i.d.L. versetzt werden, miteinander vertraulich zu „tuscheln“. (siehe: Quervernetzungen von Informationen).

Zur „weitgehendsten Anonymität“ im Internet bedarf es zur Vermeidung von nachträglichen Verkehrsflussanalysen - meiner Ansicht nach – sowohl:

a. den Einsatz eines lokalen Proxyservers (z.B. Squid / Proxomitron) zur Verschleierung der lokalen TCP/IP Header-Daten, welche in Folge nicht verschlüsselbar, bzw. aus den Daten-Paketen heraus auch nicht zu löschen sind,

b. sowie auch die Zuhilfenahme einer vertraulichen Serie von externen Proxykaskaden,

um somit den paketvermittelnden Anfrage-Vektor zum Zielrechner hin unwiderruflich (engl. „irrevocable“) „versetzen“ zu können. Wahre Anonymität im Internet gibt es jedoch nicht – auch nicht unter Ausnutzung von P2P.

Oliver

O.T.
Das alte bundespostgestützte BTX (Bildschirmtextverfahren von 1983) - bzw. der britische Vorgänger - bekannt als „Viewdata Timesharing Common Carrier over TV“ (aus dem Jahre 1977) - hatten in Bezug auf das heutige Internet vielleicht auch Vorteile, da eine eindeutige Zugangsidentifikation über die jeweilige Haus-Anschlusskennung erfolgte – darüberhinaus seinerzeit keine lokalen Programme (auf dem Fernseher) ausführbar waren – und obendrein die abrufbaren Daten zentral auf einem einzigen dedizierten Server-System vorgehalten wurden.

bubu_24 stellte u.A. Folgendes dar:

Zitat

Bei Einsatz einer Smartcard als Zertifikats- und Schlüsselträger wird jede Aushandlung eines Sitzungsschlüssels manifest (PIN-Eingabe). Soweit OK.[...]

Wird der digitale Schlüssel im EPROM der SmartCard gehalten, ist zur unwiderruflichen Schlüsselvernichtung wiederum die physikalische Zerstörung des Mikrochips selber erforderlich. Der Einsatz solcher SC´s (besonders unter RSA 2048 Bit Verschlüsselung) ist somit gegenüber volatiler Hintergrundspeicher (z.B. Festplatten, Flash-Speicher, etc.) zu favorisieren.

bubu_24 erklärte u.A. Folgendes:

Zitat

[...]Dennoch bleibt die Paarung URL zu Sitzungsschlüssel scheinbar erhalten - das ist nicht so gut.[...]

Das ist richtig. Ein gültiger Sitzungsstatus könnte somit in einem weiteren vereinfachten „SSL-Handshake-Verfahren“ (Server-Client) erneut wieder aufgenommen werden, sofern im Zuge der zugrundeliegenden SSL-Spezifikation serverseitig das Flag auf: „is resumable“ (SSLv.3) gesetzt wurde.

bubu_24 fragte obendrein:

Zitat

[...]Gibt es eine Möglichkeit, auf dem Client den Cache (vorzugsweise nur für die gewählte URL) zu entfernen, wenn die Verbindung nicht zustandekommt, sodass ein Reload auf der URL wieder zur Zertifikatsauswahl führt?

Soweit ich hier richtig informiert bin, offeriert Firefox nur die Möglichkeit des Löschens einzelner URL´s aus der Chronik heraus - jedoch werden somit die Daten (zur Schlüsselvernichtung) nicht aus dem Cache selber entfernt. Vielleicht gibt es eine Erweiterung, die so etwas besorgen kann.

Oliver

Dr.Evil fragte u.A. Folgendes:

Zitat

[...]Was hat JavaScript mit HTML5 zu tun? Das ist eine völlig andere Baustelle.[...]

Nein. JavaScript stellte bisher nur eine Ergänzung zum HTML-Kontext dar und konnte somit zur Laufzeit der Verarbeitung i.d.R. auch nur durch die einzelnen Web-Browser selber interpretiert werden. Damit erkläre ich Dir ganz bestimmt nichts Neues.

Die Konsolidierung (also Gleichstellung) der unterschiedlichen Interpretationsmöglichkeiten verschiedener Clients (Browser) würde jedoch durch die zentrale HTML5-Eigenschaft - z.B. durch die Definition eines einheitlichen und abwärtskompatiblen HTML-Parsers (im Zuge eines einheitlichen Sprachkonzeptes) – somit auch zu einer einheitlichen Richtlinienkompetenz führen können. (Ausschluss einer: „clientseitigen Interpretations-Fragmentierung“).

Dr.Evil stellte u.A. Folgendes dar:

Zitat

JavaScript hat eine Prototyp-basierte Vererbung statt einer Klassen-basierten.[...]

Nützt leider nichts, sofern die Terminologie der Sprache nicht eingeschränkt gehandhabt werden kann.
Klassen > Objekte. (Java / eingeschränkte Polymorphie).
Objekte = Objekte. (JavaScript / liberale Ausgestaltung).

Objekte sind – unter JavaScript – somit generell an keine Richtlinien gebunden. Objekte geben unter JS somit nur Initialwerte vor.

Dr.Evil stellte darüberhinaus u.A. Folgendes dar:

Zitat

[...]Böses Foul! Es gibt in JS keine Integer (nur „64bit“???-Floats) und die können auch nicht überlaufen, weil das bei jeder Rechenoperation extra geprüft wird.[...]

Du hast leider Recht. Ich verwechselte JS mit C. Ich hatte mich diesbezüglich geirrt.

Oliver