Beiträge von Oliver222

boardraider erklärte Folgendes:

Zitat

[...]kann man auch nicht zweifelsfrei davon ausgehen, dass die Banking-Software oder die an den Kartenleser gesendeten Daten manipulationsfrei sind.

In smartcard-basierten Authentifizierungssystemen wird inzwischen die PIN i.d.R. separat über die Tastatur des dazugehörigen Lesegerätes eingegeben, um somit eine sichere Übertragung der Zugangsdaten - und zwar auf Basis eines Sicherheitssubsystems - zu gewährleisten. Ein Trojaner wäre daher – nach meinen bisherigen Informationen - nur im Besitz der übertragenden Inhaltsdaten (also der Transaktionen) – könnte jedoch nicht auf die notwendigen Zugangsdaten selber zurückgreifen.

Für die von Dir angesprochenen mögliche Kompromittierungen zwischen Kartenlesegeräten und Zielsystemen (z.B. über Sniffing, Spoofing, etc.) gilt – meiner Ansicht nach - immer noch die „alte Schule“ durch: Verschlüsselung, MAC-Berechnung, gegenseitige Authentifikation, etc.

Eine SmartCard (sofern dem Besitzer entwendet), könnte über eingehende Kryptoanalyseverfahren dennoch „geknackt“ werden, da der zur Verfügung stehende Adressraum und Speicherplatz auf dem Mikrochip der Karte bisher nur Platz für symmetrische Verschlüsselungsverfahren zulässt.

Dennoch ist – meiner Meinung nach - die besitzbasierende Authentifikation vertraulicher Systemzugänge über die Verbindung:

Biometrischer Zugang > SmartCard > Reader / Input-Output Controller > System > Zielsystem,

nach dem heutigen Stand der Technik, als relativ sicher zu betrachten.

Oliver

WinMark fragte Folgendes:

Zitat

[...]Ich verwende ein eigenes Benutzerkonto unter Windows XP für onlinebanking und möchte den Browser für diesen Benutzer auf höchst-mögliche Sicherheit konfigurieren. (keine Cookies, etc.)[...]

Die Absicherung des Browsers - sowie auch die „eingeschränkten Zugriffsrechte“ des Betriebssystems stellen – in Bezug auf OB – leider nur „einen Teil“ der dafür notwendigen Sicherheits-Infrastruktur dar.

Vielmehr entscheidend ist, dass Du Dich als lokaler Kunde (also von Deinem Computer aus) dem Zielsystem (der Bank) gegenüber authentifizieren kannst – und umgekehrt. (z.B. Challenge-Response-Protokoll / SSL / „besitzbasierende“ Kartenkonzepte / etc.). Darüber hinaus gilt es aus einem unkompromittierten Endsystem heraus operieren zu können.

Sofern Sicherheit im elektronischen Geldverkehr von Relevanz sein sollte, könnte ein günstiges „Biometrie-Zugangsgerät“ (z.B. ein Fingerprint-Scanner) - und zwar in Verbindung mit einer „SmartCard“ für Dich bedeutungsvoll werden. Die Hardware dafür wäre in der Beschaffung nicht teuer und Du würdest durch dieses Verfahren obendrein potentielle Sicherheitsdefizite des lokalen Systems (Deines Computers) umgehen können.

Der Authentifizierungsvektor gegenüber dem Server des Finanzinstitutes würde nach diesem Verfahren dann „dreiteilig“ erfolgen:

Biometrischer Zugang > SmartCard < > Zielsystem (Bank)

Oliver

Nemesis fragte Folgendes:

Zitat

[...]Wechsle ich danach in den Account als eingeschränkter Benutzer und öffne FF wird mit die Erweiterung erst gar nicht angezeigt und ich kann sie daher nicht verwenden.[...]

Meinen bisherigen Informationen nach, benötigst Du dazu uneingeschränkte Schreibrechte in Bezug auf das Installationsverzeichnis, da das zugrundeliegende Komponentenmodell (also die Schnittstelle: XPCOM) der Erweiterung NoScript scheinbar eigenen Standards folgt.

Versuche daher NoScript zuerst als eingeschränkten Benutzerprozess im „nicht-privilegierten Anwendermodus“ zu installieren. Warte den Warnhinweis im Zuge des Installationsvorganges ab – unterbreche kurz den Einsprung – um dann die Applikation (Firefox) auf administrativer Ebene erneut zu starten und den Installationsprozess der Erweiterung fortzusetzen. Entziehe nach erfolgter Installation dem System daraufhin wieder die Zugriffsrechte.

Wie Cosmo im Vorfeld bereits erläuterte, „greifen“ sog. Objektdeskriptoren unter Windows (NTFS) nur auf der Datei-/Ordnerebene.

Thema wurde hier bereits hingebungsvoll ausdiskutiert...

Oliver

Boersenfeger stellte Folgendes dar:

Zitat

Wenn wir uns die Frage des TO anschauen, wurde diese beantwortet.[...]

Meinst Du das beurteilen zu können?

Boersenfeger erklärte darüberhinaus:

Zitat

[...]Links werden hier immer wieder gegeben und es gibt auch noch Google oder andere Suchmaschinen.

Warum dann dieses Forum? Aus Deinem Kommentar spricht – meiner Ansicht nach – sehr viel Dummheit und Überheblichkeit.

Oliver

ffFan erklärte Folgendes:

Zitat

[...]Ich verwende eine portable Version Firefox V3.5.3 und möchte eigentlich aus Sicherheitsgründen nur mit
den add-ons noscript und adblock surfen. Dies funktioniert auch sehr gut im normalen Betrieb.[...]

Wo und wann genau findet bei Dir im Zuge der "portablen Firefox-Version" ein „normaler Betrieb“ statt?

a. Befindet sich Deine „portable“ Firefox-Version auf einem separaten Datenträger (z.B. einem USB-Stick / oder einer SmartCard)?

b. Setzt Du diese „portable“ Firefox-Version darüberhinaus auf unterschiedlich konfigurierten Systemen ein, auf denen sich bereits schon eine weitere Firefox-Version befindet?

c. Ist der Firefox u.U. auf solchen von Dir genutzten Systemen bereits schon als Standard-Browser vorkonfiguriert so dass die lokale und nicht die portable Konfiguration Deines Browsers dabei zum Einsatz käme?

Oliver

Boersenfeger erklärte nebenbei Folgendes.

Zitat

[...]Im übrigen zitiere mich bitte richtig. Ich nutze auch ständig AntVir.[...]

Entschuldige bitte...

Heuristische Erkennungsmuster - also in sich mutierende Codesequenzen - vs. bereits bekannter Viren-Datenbanken. Das könnte u.U. ein verdammt interessanter Thread werden...

Die "Wissenden" haben innerhalb dieser Commune - meiner Ansicht nach - gegenüber den (noch) „Unwissenden“ dennoch eine Verantwortung. Koste es dabei was es wolle...

Oliver

Börsenfeger erklärte Folgendes:

Zitat

[...]Ich nutze auch nur die Windowsfirewall[...]

Mit einer „Augenklappe“ durch das Internet? Das war hoffentlich wieder einer Deiner „ironisch“ gemeinten Beiträge...

privee stellte Folgendes dar:

Zitat

[...]Meine Bedenken sind allerdings, dass dann (etwas) nicht in Ordnung ist. Ich also irgendeinen "Infekt" auf dem Rechner habe.

Du hast - meiner Ansicht nach - nicht ganz Unrecht. Trojaner können den Umweg über den Browser gehen.

Die meisten Firewalls arbeiten - meines Wissens nach - „zustandslos“. Deine ZA-Firewall - wie andere Firewalls auch – operieren somit bloss auf der universalen Netzwerkschicht (OSI-Level 3), von wo sie aus als Paketfilter nicht in der Lage sind zu erkennen, welche Ports und Dienste verschiedener Programme auf Deinem Computer als sicher einzustufen sind. Ein Dienst (Programm) kann dabei vielfältige Ports beanspruchen. Paketfilter können wiederum leider nur nach Ports selektieren ohne die dahinter stehenden Dienste zu erkennen. Filterregeln (Lerneffekte) einer solchen paketorientierten Firewall sollten sich daher aus Sicherheitsgründen nur an wenige vertrauenswürdige Dienste (also Programme) auf Deinem System knüpfen lassen.

Obendrein bündelt das Windows-Betriebssystem einige Systemdienste derart, so dass in Konsequenz eine Erkennung und Differenzierung der Kopplungen: externer Zugriff > lokaler Dienst im Detail noch erschwert wird.

Im übertragenen Sinne, könntest Du Dir die oben dargestellte Situation ungefähr so vorstellen wie ein Bunker, der durch eine Stahlschutztür abgesichert wurde, die offiziell nur eine sehr begrenzte Anzahl an Schlüsselkombinationen zulässt. Nun kommt ein Einbrecher mit einem Dietrich, mit Hilfe dessen er durch Ausprobieren wesentlich mehrere Zugangs-Kombinationen ausprobieren könnte, um sich Zutritt zu dem Schutzraum zu verschaffen. Zur Zugangssicherung würde somit keine „individuelle Kombination“ mehr gelten, sondern eher eine „Kombination aus individuellen“ Zugängen entstehen.

Der eine oder andere Anwender sollte sich - meiner Ansicht nach - mit so einer paketorientierten (Desktop) Firewall nicht unbedingt auf der „sicheren Seite“ wähnen.

Oliver

http://de.wikipedia.org/wiki/OSI-Model…ittlungsschicht
http://www.tcp-ip-info.de/security/firewalls.htm#paket

URLZone ist - meines bisherigen Wissens nach - als Trojaner bloss ein Derivat (Abkömmling) des bereits bekannten Zbot Trojan und somit bekannt. Eine Systemkompromittierung durch so eine Schadsoftware erfolgt daher auch nicht durch den jeweiligen Browser, sondern bloss durch die unzulängliche Beschränkung von Schreibberechtigungen des zugrundeliegenden Betriebssystems selber. Die Infektionsvektoren solcher Trojaner sind dabei immer gleich.

Es gilt - meiner Ansicht nach - als Gegenmassnahme:

a. Schreibrechte auf dem System einschränken / Freigaben nur auf temporär anzulegende Daten (z.B. TEMP-Verzeichnisse) begrenzen.

b. Verschlüsselung von Daten / gespeicherten Programmen.

c. Sensible Daten (z.B. PIN´s, TAN´s, Passworte) vom System getrennt halten (z.B. auf einer SmartCard oder einem verschlüsselten USB-Stick).

URLZone (Kosename: Zeus) besitzt darüberhinaus keine „Rootkit-Eigenschaften“ und ist somit - oberhalb der Windows-API - mittels eines Scanners auch problemlos entfernbar.

Interessant wäre bei dieser Thematik noch die Tatsache, dass erst die Finanzinstitute durch eine vorübergehende Kontensperrung den „unbedarften“ Vertrags-Kunden sensibilisieren mussten...

Oliver

Cosmo erklärte Folgendes:

Zitat

[...]"Alle" bezog sich hier auf die Java-EXEn, nicht auf Firewalls.[...]

Easy mein Freund. Ich glaube ich habe Dich schon richtig verstanden.

a. Eine oder mehrere „*.EXEn“ existieren als Suffix - meines bisherigen Wissens nach - ohnehin nicht.

b. Die von Dir angesprochenen Updatedienste der Java.Engine werden bei dem Antragsteller letztendlich durch den Paketfilter (ZA) geleitet, denn das entsprach seiner Anfrage, wie auch dem Topic dieses Threads. Nur darum geht es.

c. Unter Deiner Verwendung des Terms: „Zulassen nur für ausgehende Verbindungen“, werden von Dir somit einhergehend: „zustandsbehaftete Filterausdrücke“ einer FW impliziert. Wie sonst könntest Du einen Dienst nur für eingehende Verbindungen sperren? Du könntest so einen Dienst allenfalls über das System komplett sperren.

d. Rechtevergaben unter Java orientieren sich darüberhinaus nicht an Subjekten (Anwender) selber, sondern bloss an Java-Klassen (über URL / Class-Loader). Wie sperrst Du da einzelne Update-Dienste eingehender Verbindungen?

Obiges sei Dir hier als OT angediehen, damit Du dazulernst und Dich - meiner Beurteilung nach - nicht „um Kopf und Kragen“ reden musst.

Oliver

Cosmo stellte Folgendes dar:

Zitat

[...]Aber: Für alle [Firewalls] gilt: Zulassen für ausgehende Verbindungen, niemals für eingehende!

Wie soll so ein System - Deiner Ansicht nach - funktionieren? Wie differenzierst Du den eingehenden Traffic jener Applikationen, die fortwährend Daten austauschen müssen?

Die Filterungsentscheidung frei verfügbarer Paketfilterdienste basiert - meines Wissens nach - zuguterletzt stets auch auf Angaben zur sog. „Subjektidentifikation“ - also IP-Adressen, die jedoch nicht über die FW selber authentifiziert werden können. Diese IP-Informationen geben leider keine Auskunft darüber, ob die entsprechende Adresse authentisch auch zum Absender des Paketes gehört. (Stichwort: MITM-Angriff). Analoges gilt für die Filterung von Diensten anhand von Portadressen. Der Eintrag eines Absender-Ports in einem Paket ist definitiv nicht vertrauenswürdig.

Paketfilterdienste (z.B. ZA) operieren bloss auf der Netzwerk - und Transportebene, welche per Design für eine vertrauenswürdige Selektion des Traffics zu „grobgranular“ differenziert sind.

Platt ausgedrückt: Sofern ein einmalig freigegebenes Programm - auf Basis eines Paketfilters - Daten in das Internet schicken oder erhalten möchte, dann kann es das auch. Die einzige letztendlich reale Möglichkeit so ein Programm daran zu hindern Daten auszutauschen, wäre den Netzwerkstecker zu ziehen. Es existiert - meiner Ansicht nach - somit keine absolute, paketfiltergestützte Kontrolle über den bidirektionalen Traffic.

Ein dedizierter Filter-Proxy auf der Anwendungsschicht käme dagegen Deinem oben genannten Vorhaben schon etwas näher.

Oliver

PvW erwiederte Folgendes:

Zitat

[...]Ganz davon abgesehen, daß es wesentlich einfacher ist, systemweit persönliche Einstellungen vorzunehmen und ggf.
sinnvolle Standards durchzusetzen.[...]

Nein!

Wie wäre es dagegen, solche von Dir „gehuldigten“ und sinnvollen OS-Systemstandards nicht gleich von vornherein in die entsprechenden Browserumgebungen zu portieren?

Sofern eine solche neue Browser-Spezifikation mit den Standards einzelner Webseiten - und zwar auf Basis von HTML 5 (Draft Standard / 09/2009) ohne Flash - korrelieren kann, wäre ein von Dir angeführter zugrunde liegender OS-Systemstandard - meiner Ansicht nach – irrelevant.

Zitat

<video>
This is the descrption of movie...
</video>

wäre als Tag bereits schon ein Ansatz, den der FF "aufzugreifen" vermag.

PvW erklärte darüberhinaus Folgendes:

Zitat

[...]Der Ausdruck "Skins" triffst m.E. ziemlich genau - er bedeutet eine individuelle gewollte Einstellung der Darstellung.[...]

Ein „Skin“ ist etwas völlig anderes. Du hast – meiner Ansicht nach – die Diskussion nicht verstanden!

Wie bereits dargestellt - Opera und FF arbeiten - nach meinen Informationen - diesbezüglich bereits (hoffentlich sinnvoll) zusammen.

Oliver

https://developer.mozilla.org/en/nsIDOMHTMLMediaElement

.Ulli fragte Folgendes:

Zitat

Mozilla soll also die Hausaufgaben der Hersteller des OS nachholen?

Nein.

Der Firefox wurde plattformunabhängig konzipiert, was auf die Praxis bezogen in etwa soviel bedeutet, dass die selbe Software unter Windows, Linux, MacOS, sowie zahlreichen Unix-Derivaten unter gleicher Qualität - bezogen auf das Internet - ausführbar ist. Damit erkläre ich Dir nichts Neues.

Denke einmal an die möglichen Vorteile der Portierbarkeit so einer speziellen Konfigurationen, auf unterschiedliche Systeme.

„Audioelemente“ und sog. „Screenreader“, als Benutzerschnittstelle zur Darstellung von Webseiten für körperlich eingeschränkte Menschen sollten – meiner Ansicht nach – in der heutigen Zeit kein Bestandteil des OS mehr sein sondern - ungeachtet der MSAA-Schnittstelle Microsofts - bereits schon in den entsprechenden Browsern selber implementiert werden. Die Technik zur Umsetzung solcher Verfahren wäre bereits vorhanden.

Oliver

koss_bremen fragte u.A. Folgendes:

Zitat

[...]Nur die Email-Zugriffsdaten für Freenet sind hier nicht erfasst. Sie müssen noch irgendwo anders sitzen.[...]

Deiner Anfrage sei vorweggenommen: (Stichwort: Zugriffsdaten).

a. Zugriffsdaten = Verkehrsdaten.

b. Verkehrsdaten = Deine pers. Kundendaten, welche über einen E-Mail Provider. (z.B. Freenet) rechtlich extern erhoben (und gespeichert) werden dürfen.

c. Verkehrsdaten = Informationen über den Kunden / seines Standortes / seiner zeitliche Zugriffe / etc.. (Stichwort: Verkehrsdaten s.u.).

d. Verkehrsdaten werden providerseitig und nicht lokal auf Deinem Computer gespeichert. (Stichwort: Vorratsdatenspeicherung s.u.).

e. Verkehrsdaten < > Inhaltsdaten (also ungleich demgegeüber, was Du an "Textinhalten" (z.B. in einer Mail) verfasst hattest).

Verkehrsdaten - wie auch die Inhaltsdaten selber - unterliegen in Germany (noch) dem Fernmeldegeheimnis gemäss Artikel 10 des Grundgesetzes § 88TKG und werden offiziell (in Europa) nur zu Zwecken der Identifikation und Nachverfolgung unzulässiger Zugriffsversuche, sowie Zugriffe auf den Web-Server verwendet.

Zitat

Sie [die Benutzernamen und Passwörter] müssen noch irgendwo anders sitzen.[...]

Firefox > 3.5: signons.sqlite in Zusammenhang mit der key3.db. Diese Daten lassen sich lokal jedoch auf Deinem System terminieren und können im Anschluss daran erneut wieder angelegt werden.

Oliver

http://de.wikipedia.org/wiki/Vorratsdatenspeicherung
http://de.wikipedia.org/wiki/Verkehrsdaten

boardraider erklärte Folgendes:

Zitat

[...]Der Fx speichert die Passwörter auf eine recht sichere Art - wenn du ein Masterpasswort nutzt. Verwendest du es nicht, kann jeder, der Zugriff auf deinen Rechner bzw. dein OS-Nutzerkonto hat, an die gespeicherten Passwörter gelangen.[...]

Soweit ich das zu beurteilen vermag - Zustimmung!

Der sog. PasswortSitter (das Passwort-Management-System) des Firefoxes wird durch eine einfache clientseitige Java-Applikation realisiert. Diese vermag aus einem (hoffentlich gut) gewählten „Master-Passwort“ deterministisch - auf Grundlage des AES-Verfahrens - entsprechende „Service-Passwörter“ für den Zugriff auf einzelne Webseiten zu generieren.

Firefox verwendet dafür - nach meinem bisherigen Kenntnissen - die sog. Network Security Services (NSS) API, um kryptographische Operationen durchführen. Diese NSS besteht aus einer Sammlung von Bibliotheken sicherheitsgerichteter Client und Server-Anwendungen, welche zur Unterstützung von „Cross-Plattform-Entwicklungen“ zum Einsatz kommen. Diese API gilt jedoch als „kompromittierbar“. Die ungeschützte Password-Database des FF´s (ohne Master PW) könnte somit ausgelesen werden - was jedoch nicht für das „kollisionsresistente“ Verschlüsselungsverfahren selber gilt.

Ergänzend zu der Darstellung "boardraiders" wäre somit - meiner Ansicht nach - die Sicherheit des Browser-PW-Systems alleine abhängig von der:

a. „kryptographische Stärke“ des Master-Passwortes,

b. systemgestützten „Zugriffskontrolle“ (über ACL) der „key3.db-Datei“ (als sicherhetsstrategische Objektverwaltung).

Zitat

Zertifikate (Signed Public Keys) > certN.db (erzeugen den Hashcode für das ↓)

Master Password / (Salt) > keyN.db (verschlüsselt den ↓)

Master Key: > key3.db (generiert daraus die ↓)

UserNames / Passwords: > signons.txt

Oliver

Brummelchen erklärte:

Zitat

[...]nur eben "Addons" (XPI-Erweiterungen) um es korrekt auszudrücken sind irgendwie Mangelware - wobei Opera ja schon einiges mitbringt und Firefox nicht.

z.B.

- einen CSS „Feed-Reader“, der - meiner Ansicht nach - von vornherein in das (Sicherheits)-Konzept des FF´s integriert werden sollte.

- eine Integration von „Audioelementen“, um somit die Nutzung für Menschen mit körperlichen Einschränkungen möglich zu machen.

- eine weitgehend konforme Acid3 Rendering-Engine (analog zur Opera´s Presto 2.2).

Um eine „barrierefreie“ Browsernutzung zu ermöglichen, arbeiten die beiden "Konkurrenten" - soweit ich informiert bin - inzwischen sogar zusammen.

Oliver

http://de.wikipedia.org/wiki/Web_Accessibility_Initiative

bugcatcher erklärte Folgendes:

Zitat

Ich benutze gar keinen Virenscanner. Alles Humbug. Firewall ist im Router. Alles andere ist Humbug.[...]

Soweit ich das zu beurteilen vermag - Richtig!

Sofern auf einem (Einzel-Mehrbenutzer) System:

a. eine lokale Rechteverwaltung bereits im Vorfeld modelliert wurde. Subjekte (Anwender) somit nur eingeschränkte Rechte zum Zugriff auf Objekte (Anwendungen) besitzen,

b. eine „relative Risikoreduktion“ durch die systemrelevante Isolation unnötiger Dienste erfolgte,

uneingeschränkte Zustimmung!

Oliver

donhirto stellte Folgendes dar:

Zitat

[...]Mein Problem zeigt sich beim Online Banking.[...]Wenn ich nun meine Kontodaten [unter FF 3.5.3.] aufrufen will oder irgendeine Anwendung durchführen möchte, klappt dies meist erst nach mehreren Versuchen oder oft auch gar nicht.[...]

a. Benutzt Du separate FF-Erweiterungen / Toolbars (z.B. Norton oder NoScript)?

b. Lässt Du browserinterne Pop-Up´s für solche vertraulichen SSL-Sitzungen zu? (definierte Ausnahmeregelungen).

c. Gilt zur Vertrauensbildung zwischen Server (Bank) - Client (Anwender) u.U. die Vorlage eines individuellen Zertifikates?

d. Findet eine „Sitzungswiederaufnahme“ (alte Schlüsselübernahme) oder ein sog. „Rekeying“ (Schlüsselneuerzeugung) statt?

e. Nutzt Du eine Applikations-Filter-Firewall? (SSL-Verbindungsabbruch in Bezug auf vorgebliche MITM-Angriffe).

f. Welcher User-Agent (HTTP-Header) kommt bei Dir im Firefox zur Anwendung?

Beim Verbindungsaufbau handeln Browser und Server i.d.R. den SSL/TSL-Verschlüsselungsalgorithmus aus, wobei die meisten Banken heutzutage bereits das AES-Verfahren mit 256 Bit Schlüsseln benutzen. Nach meinem bisherigen Wissen, ist dieses Verschlüsselungsverfahren im Zuge browserintegrierter „Xramp 256-Bit-Zertifikate“ gegenüber „schwächeren Kommunikationspartnern“ obendrein abwärtskompatibel.

Es muss daher nicht am FF alleine liegen...

Melde Dich noch einmal zurück.

Oliver

privee fragte Folgendes:

Zitat

[...] seit dem ich die neue (aktuelle) Version von Firefox nutze, bekomme ich nach einer gewissen Zeit der Nutzung von meiner Firewall die Meldung, dass Firefox versucht als Server zu agieren.[...]

Erfolgt die Wegewahl Deiner Daten "routergeführt" (OSI-Level 3) oder ist die Firewall Bestandteil Deines "lokalen Systems"? Welche Protokollinformationen werden dabei übermittelt?

Sofern Du eine Firewall auf Basis einer TCP- / UDP - Portfilterung nutzen solltest (z.B. ZoneAlarm), stünden somit verbesserte Filterungsmechanismen zur Verfügung, welche bereits auf der Transportschicht (OSI Level 4) die entsprechenden Portadressen - in Bezug zu den jeweiligen Diensten - setzen können. (Stichpunkt: dienstbezogene Zugriffskontrollen). Dieses Verhalten kann jedoch auch zu Fehlalarmen führen, da einzelne Programme (wie auch der FF) sitzungsgebunden dennoch auf verschiedene System-Ports zuzugreifen vermögen, welche jedoch im Vorfeld durch die Firewall aus Sicherheitsgründen gesperrt wurden. (IP > Dienst > Port).

Eine LoopBack-Adressierung des Firefoxes auf die lokale Systemadresse 127.0.0.1 stellt sich - trotz Nutzung unterschiedlicher Ports – als harmlos dar. Dieses „Fehlverhalten“ des Browsers wird jedoch von einigen lokalen FW´s als unautorisierter Zugriff auf das System selber in Frage gestellt. (s.o.).

Zu unterscheiden ist - meiner Ansicht nach - zuguterletzt zwischen den Zugriffen des FF´s selber, wie auch seinem integrierten Erweiterungskonzept, welches gleichermassen durch ein Firewall-System geleitet werden würde. (s.u.).

Zitat

Live Bookmarks Updating
Auto-Update Checking
Home Page Loading
Anti-phishing List Updating
Anti-malware List Updating
Add-On List Prefetching
Link Prefetching
Extension Blocklist Updating
Live Title Updating
Extensions
Downloads Restarted

Alles anzeigen

Vielleicht noch ein paar mehr Angaben von Dir.

Oliver

http://de.wikipedia.org/wiki/OSI-Model…ittlungsschicht
http://de.wikipedia.org/wiki/OSI-Model…ransportschicht

boardraider erklärte Folgendes:

Zitat

Bspw. Java im Rahmen von "Anonymität" und dem Stichwort Sockets.

Meiner Ansicht nach - Nicht schlecht!

Stichwort: „Maschinenunabhängiger Zwischencode“ (Java) vs. „sicherer Migration“ - innerhalb stetig wechselnder „Ausführungsumgebungen“ (Firefox).

Die JVM (Java Virtual Machine) unterliegt - meinen bisherigen Kenntnissen nach - als systemübergreifende „Anwendungsoberfläche“ - stets auch immer den „Unsicherheiten“ der sog. „Abstraktionsebenen“ selber. (z.B. dem Bytecode-Interpreter / also dem codeorientierten Umsetzungsverfahren zur Basis des FF´s).

Java „greift“ somit nicht direkt, sondern wird stets bloss interpretiert.

Interessant ist dabei auch, dass die fortgeschrittene Semantik des Java-Sprachkonzeptes nicht immer vollständig mit der Semantik des zugrundeliegenden Bytecodes übereinstimmen muss. Dies hätte dann u.U. zur Konsequenz, das z.B der Maschinenbefehl: „goto“ - ausserhalb der Java-Spezifikation - dennoch erfolgreich generierbar wäre. (Sprungbefehle / Schleifenkörper).

Liegt das Java-Problem nun an Java selber, oder doch eher an der zugrundeliegenden Laufzeitumgebung?

Oliver

nacktharfe fragte Folgendes:

Zitat

[...]Gibt es hier Unterschiede zu(m) "Privaten Modus" in Mozilla [im Gegensatz zu Google-Chrome]? Kann Chrome mehr als Firefox?

Nein. Bezogen auf Dein lokales System ist Deine Anfrage - meiner Ansicht nach - hier irrelevant.

a. Egal - ob im normalen oder im anonymen Modus - Chrome sendet dennoch Anfragen an Google.

b. „Inaktivität“ auf einem lokale System, führt darüberhinaus zu HTTP-Requests an „static.cache.l.google.com“ - bzw. auch zu regelmässigen Anfragen nach den eingesetzten lokalen Signaturen selber.

c. Der eigentliche "Chrome-Updater-Service", wird dabei zusätzlich noch lokal als "geplanter Task" (GoogleUpdateTaskUser) angelegt und somit „rückversichert“ - was meiner Meinung nach - "fragwürdig" erscheint.

Mache Dir daher datenschutzrechtlich eher Gedanken über externe Verkehrsflussdatenanalysen, welche u.A. durch Google´s UAN´s, (Unique Application Numbers über Cookies) - und zwar zur anonymen Profilerstellung genutzt werden können. Solche Cookies würden - nach meinem Wissen - zwar ein relativ geringes Gefährdungspotential für die Sicherheit von Endsystemen (Clients) selber darstellen, wären dabei dennoch Angriffen ausgesetzt, welche sich zum einen aus der Ausführung von aktiven Inhalten oder zum anderen durch unautorisierte Zugriffe in Folge von „Buffer-Overflows“ ergeben könnten.

O.T.
Google Chrome stellt keine Open-Source-Software im eigentlichen Sinne dar.
Chromium (Open Source) > Google Chrome (proprietär). Daher Chromium < > Google Chrome.

Oliver

http://www.google.com/chrome/intl/en/privacy.html