Beiträge von Thunderbyte

Zitat von Sören Hentzschel

Ich habe deinen Beitrag dementsprechend in den originalen Thread verschoben.

Danke. Das war nicht ersichtlich.

Zitat von Sören Hentzschel

Wenn du keinen Beweis erbringen kannst, dass die umgesetzte Maßnahme nicht wirkt (der verlinkte Artikel betrifft das Protkoll generell, nicht die konkrete Implementierung in Firefox!),

Eben. Das ist ja nicht so schwer zu verstehen. Es betrifft das Protokoll. Es betrifft nicht den Firefox. Hatte ich bereits deutlich erwähnt. Das Protokoll ermöglicht Replay-Angriffe.

Zitat von Sören Hentzschel

Dann hast du nichts vorzuweisen außer einer Theorie ohne Nachweis eines realen Angriffsszenarios für Firefox-Nutzer. Und genau darum geht es hier.

Habe ich doch. Den Beweis hat der angebliche Aluhutträger verlinkt. Übersetzen darf es gern jeder selbst. Ihr solltet es eher als Vorteil des Firefox sehen, dass man 0-RTT hier abschalten kann. Ich weiß nicht, ob das in anderen auch geht. Damit lässt sich dieser Angriff unterbinden. Das wurde hier dem Anschein nach nicht verstanden.

Da hier RE: Was ist 0-RTT, wann sollte man es deaktivieren? ganz schnell geschlossen wurde, hier meine Antwort. Soviel Fairness sollte es geben, dass man antworten darf.

Zitat von Sören Hentzschel

Wenn du anderes behaupten willst, verlinke eine Stelle, welche eine entsprechende - offene - Sicherheitslücke in Firefox dokumentiert.

Mit Sicherheitslücken im Firefox hat das gar nichts zu tun. Lies den vollständigen Beitrag auf Golem, den du selbst genannt hast. Wenn der Server TLS 1.3 und 0-RTT nicht richtig implementiert hat, gibt es ein Problem. Das lässt sich nicht im Firefox lösen, weil es eben serverseitig ist.

Ansonsten bleibe ich dabei. Du machst dich mit dem Begriff "Aluhutträger" lustig über den Autor, dejavu macht es in anderen Worten in Beitrag #5. Ich kritisiere nicht, dass er nicht weiß, was 0-RTT ist. Ich kritisiere #5.

Zitat von Sören Hentzschel

Ich empfehle, auch den im verlinkten Artikel referenzierten IETF-Link zu lesen und zu schauen, wie dort der Begriff Applikation verwendet wird. Immerhin bezieht sich die zitierte Aussage darauf.

Habe ich gelesen. Der Artikel bestätigt, was ich geschrieben haben. Ein Browser kann einen Replay-Angriff nicht verhindern, wenn der Server der Schwachpunkt ist. Auch Mozilla nicht. Will man ihn definitiv verhindern, geht das, indem man 0-RTT deaktiviert. Nenne den Autor weiterhin Aluhutträger, in diesem Punkt liegt er absolut richtig.

Zitat von Sören Hentzschel

Und das möchtest du jetzt ernsthaft als Kritikpunkt anführen? Das ist billig.

Ja, das möchte ich. Weil der Autor hier als Aluhutträger bezeichnet und darüber hinaus in #5 weiter diskreditiert wird. Das nenne ich billig.

Zitat von Sören Hentzschel

DeJaVu das Thema sogar explizit mit der Frage eröffnet, was 0-RTT ist.

Dagegen ist nichts zu einzuwenden. Gegen Beitrag #5 sehr wohl. Der Typ, über den ihr euch lustig macht, weiß, was 0-RTT ist.

Zitat von Sören Hentzschel

Zum anderen: Man sollte dann darauf verzichten, wenn die enge Verzahnung von TLS und Applikationslogik nicht gewährleistet werden kann. In Firefox ist das standardmäßig aktiviert. Daraus folgt: Mozilla kann das gewährleisten. Sonst hätten sie es nicht aktiviert.

Applikationslogik meint hier auch die des Servers. Darauf hat Mozilla gar keinen Einfluss. Folgerichtig kommt auch Golem zu dem Schluss:

Zitat

Mit dem Zero-Round-Trip-Verfahren kommt zudem eine Konstruktion hinzu, die neue Sicherheitsrisiken mit sich bringt.

Der angebliche Aluhutträger hat sich seine Punkte zu 0-RTT nicht ausgedacht. Er gibt einen Link auf einen Entwurf der IETF an. Dort steht glasklar: die Replay-Angriffe sind keine Fantasie.

Zitat

The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety, by implementing one of the methods described in this section or by equivalent means.

und

Zitat

The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application. Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense.

Zitat von .DeJaVu

Bei sowas lass ich die machen, sind eh alle schlauer als du und ich. Dieser Satz beinhaltet Sarkasmus und Ironie.

Der Kollege aus dem anderen Forum weiß immerhin was 0-RTT ist und hat mit der IETF auch eine gute Quelle angegeben.

Bei der Frequenz würde ich einfach für eine Weile einen anderen Browser verwenden. Schmiert der nicht mit einem OOM ab, wäre das ein starkes Indiz für einen Bug im Firefox. Umgekehrt ebenso.

Zitat von Sören Hentzschel

Das ist ja das Schöne am Fußball:

Das Schöne am Fußball ist auch, dass jeder dazu eine Meinung haben darf. Es gibt oft kein der hat Recht und der nicht. Etwas Beweisbares, so wie in der Technik, gibt es hier meistens nicht. Meistens. Kommen wir zum Videobeweis.

Zitat von Sören Hentzschel

Aber nein, dass die Ausfälle ein "größeres Problem" gewesen seien, wurde während des Spiels so nicht gesagt

Die Aussage, so wie ich sie oben extra mit dem Vermerk sinngemäß zitiert habe, wurde mehrfach getroffen. Dafür gibt es alle Fernsehzuschauer als Zeugen und zur Not bestimmt eine Aufzeichnung. Das ist beweisbar!

Zitat von Sören Hentzschel

aber das Spiel hat super unterstrichen, was ich im Vorfeld geschrieben habe: Die Ausfälle waren für die Bayern nicht einmal ansatzweise ein so großes Problem, wie es hier dargestellt wurde. Im Gegenteil, von so vielen Ausfällen war den Bayern überhaupt nichts anzumerken.

Da du unbedingt nachlegen musst. Die Bayern haben nicht schlecht gespielt, hatten hier und da Pech und hätten das Ding auch gewinnen können. Ebenso haben die Gladbacher ein paar gute Möglichkeiten liegenlassen.

Dass die Ausfälle kein größeres Problem waren, das sah sogar der Kommentator, Wolf Fuß, anders. Er sagte mehrfach sinngemäß, die Gladbacher würden das Handicap der Bayern sichtbar machen. Auch, dass die Bayern kaum Wechseloptionen hatten, weil auf der Bank nur Spieler waren, die noch kein einziges Bundesligaspiel bestritten haben. Deutlich zu erkennen war, dass diese Notmannschaft nicht eingespielt war. Auch das Fehlen der schnellen Leute über die Flügel war sehr auffällig. Da wurde kaum Druck aufgebaut. Das war nicht der FCB, wie man ihn aus den Spielen zuvor kennt. Das typische, schon fast handballartige Spiel in des Gegners Hälfte fand nicht statt.

Zitat von Sören Hentzschel

Am Ende meinte es heute einfach nur Fortuna nicht gut mit den Bayern und es hat die Mannschaft mit den deutlich weniger Torchancen gewonnen. Das ist ja das Schöne am Fußball: Dass man es nicht berechnen kann und man selbst mit weniger Chancen ein Spiel gewinnen kann

Das ist eine schöne Komponente beim Fußball. Das Ergebnis macht die Liga vorerst interessanter. Das finde ich als neutraler Fußballfreund durchaus gut. Eines der Teams musste auf 9 Spieler verzichten. Das war nicht fair und deshalb auch nicht schön.

Zitat von Duckdon

Ich habe im Taskmanager gesehen, das Ein Teil des Ramspeicher komprimiert ist.

Das ist völlig normal. Windows kann das seit Version 10. Linux und macOS schon etwas länger. Das Betriebssystem versucht einerseits RAM so gut es geht auch zu verwenden, andererseits zu sparen, wo es geht. Zum Sparen kann es RAM auslagern. Weil das langsam ist, wird es zunächst versuchen, im RAM zu komprimieren. Wie beim Zippen. Gleichzeitig versucht das Betriebssystem Inhalte im Speicher zu belassen, die im Moment nicht gebraucht werden, aber vielleicht gleich wieder. Das ist der Cache.

Beispiel: Du spielst ein Spiel und schließt es dann irgendwann, um was im Internet zu surfen. Windows wird den Speicher des Spiels zunächst noch im Cache halten, wenn genug RAM frei ist. Für den Fall, dass du es gleich wieder startest. Das geht dann schneller. Benötigt der Firefox aber mehr RAM als frei ist, hat Windows jetzt mehrere Möglichkeiten. Es kann Speicher vom Cache freigeben, es kann RAM komprimieren oder RAM auslagern. Was davon es macht, hängt davon ab, was Windows meint, was in der speziellen Situation besser ist.

Dieses Hin und Her findet ständig statt. Alles ändert sich laufend. Windows versucht immer, die Balance zu finden zwischen soll ich den Cache freigeben? Oder besser komprimieren? Oder ganz auslagern? Die Programme wissen von all dem nichts. Sie fordern Speicher an, Windows stellt ihn zur Verfügung. Ob dazu der Cache geräumt werden muss oder anderer Speicher ausgelagert, das ist allein Sache von Windows.
Bei dir ist ausreichend RAM da. Das heißt, der Crash entsteht durch einen Fehler.

Ich halte es mit Boersenfeger und füge gedanklich ein s hinzu.

Zitat von Boersenfeger

Ich akzeptiere, das wir beide unterschiedlicher Meinung sind und belasse es dabei.

Zitat von Sören Hentzschel

Das, was an Personal zur Verfügung steht, ist immer noch besser als die erste Elf der meisten Bundesligisten.

Mag sein. Ist aber irrelevant. Sie können nicht mal halbwegs mit der Mannschaft antreten, mit der sie antreten würden. Es geht hier nicht um 2 oder 3 verletzte Spieler. Es geht um 9.

Fair ist das aus meiner Sicht mehr. Ich bin kein Fan irgendeines Vereins. Doch geht es für den FCB am Ende um die Meisterschaft, die sie vielleicht wegen so einer Nummer knapp verpassen. Man weiß ja nicht, was noch kommt. Möchte nicht wissen, was du hier schreiben würdest, müsste die Hertha auf 9 Spieler verzichten, das Spiel verlieren und am Ende deshalb knapp absteigen.

Zitat von Sören Hentzschel

Da Software-WebRender aktiv ist, ist die Grafikkarte überhaupt nicht involviert, damit auch kein Grafikspeicher und kein Grafikkarten-Treiber.

Das gilt für Beschleunigung, die jetzt in Software durchgeführt wird. Nicht involviert kann aber nicht sein. Denn dann hätte man ja keine Anzeige.

Zitat von Sören Hentzschel

Dass für Grafik-Operationen ein eigener Prozess genutzt wird.

Das ist etwas unkonkret. Ist das nur eine allgemeine Info? Oder bedeutet es, der abstürzende Prozess ist ein Prozess der Grafikoperationen durchführt? Das wäre meine Lesart.

Noch ist das Spiel nicht abgesagt. Inzwischen fehlen dem FCB schon 9 Spieler aus dem ersten Kader, das sind fast 90%. Für meinen Geschmack ist das nicht mehr fair. Regel hin, Regel her.

Dort steht als Process Type gpu. Weiß jemand, was das im Detail bedeutet? Ich rate mal vor mich hin. Der OOM ereignet sich gar nicht im RAM der CPU. Vielmehr geht es um den Grafikspeicher. Dazu passen würden auch die im Verhältnis nur wenigen Bytes, die angefragt werden. Dann sind Avira und der Swap mal ganz weit außen vor. Im Fokus sind dann eher Grafiktreiber und der Firefox selbst.

Ist wie gesagt nur geraten, weil mir nicht bekannt ist, was die Entwickler genau mit Process Type meinen. Der crashing thread heißt was mit WR, was wahrscheinlich für Web Render steht. Würde auch in die Richtung gehen. Ebenso die Punkte von Sören. 1ct.

Zitat von milupo

Na ja, wenn du deinen Computer immer schön heiß laufen lässt, brauchst du nicht so viel zu heizen.

Neulich war hier von Schulphysik die Rede. Wärme ist noch gleich Wärme. Ein Teil lässt sich technisch nutzen, eine anderer nicht. Stichworte seien Anergie, Exergie, Entropie.

Das ist vielleicht nicht lustig, aber Physik.

Zitat von Sören Hentzschel

im zweiten Fall

Hätte ich vielleicht dazu schreiben sollen. Ich bezog mich nur auf den zweiten Fall. Der ersten scheint mit soweit klar.

Zitat von Sören Hentzschel

Das ist sehr spekulativ.

Das ist gar nicht spekulativ. Du selbst bestätigt es. Firefox gibt den Speicher für nicht aktive, benutze, whatever Tabs frei. Das sieht man auch deutlich. Darum auch nur die 3,5 Gig bei 600-800 Tabs. Den Rest hat Firefox längst wieder freigegeben. Was Windows von den anderen Tabs noch cached, weiß man nicht. Man sieht aber eindeutig, der Cache macht 6,6 weitere Gig aus. Das können die Tabs sein oder nicht mehr benötigter Speicher eines anderen Programms sein. Cache eben.

Wenn nun eine Anwendung weiteren Speicher anfordert, wird Windows zunächst Speicher aus dem Cache freigeben. Reicht auch der nicht mehr, kommt es zum Swap. Kommt es trotzdem zum OOM, ist das entweder ein Fehler in der Anwendung, eines benutzen Treibers etc oder im Speichermanagement von Windows. Ich würde einen Tipp wagen, wo hier der Fehler liegt, aber das wäre dann tatsächlich spekulativ.

Zitat von milupo

Könnte es sein, dass der Windows-Auslagerungsspeicher eine feste und zu niedrige Größe hat?

In diesem Fall ganz klar nein, weil noch fast 6 Gig RAM frei wären. Da muss noch gar nichts ausgelagert werden. Was man aber sieht, es wurden in Verlauf der Woche über ein Gig ausgelagert. Heißt, die 16 Gig RAM haben irgendwann mal nicht gereicht. Es zeigt auch, die Auslagerung funktioniert.

Im darstellten Zustand braucht der Firefox nur 3,5 Gig. Rund 7 weitere wären verfügbar, ohne auslagern zu müssen.

Zitat von .DeJaVu

Erinnert mich an side-by-side unter Windows, dass es seit XP gibt, dort werden auch diverse Ausgaben der VC-Runtimes gesichert.

Das ist schon was anderes. Flatpack und Snaps stellen für jedes Programm eigene Laufzeitumgebungen inklusive aller Abhängigkeiten zu Verfügung. Sie sind sowas wie Container, laufen abgeschottet und können Bibliotheken verwenden, die gar nicht Bestandteil der Distribution sind. Die gehören dann nur zu dem jeweiligen Flatpack und müllen das OS nicht zu. Nur die Festplatte.

Zitat von .DeJaVu

Die Sandbox arbeitet nach deny-allow, Sandboxie für Windows arbeitet mit allow-deny, wobei das write-through durch Komptibilitätsregeln festgelegt werden kann, oder durch manuelle Änderungen.

Was willst du uns damit sagen?

Ich habe gelesen, Mozilla selbst erstellt, oder wird es künftig machen, die Snaps für Ubuntu. Das macht die Sache für die Jungs von Canonical einfacher, und sie werden die für Ubuntu kompilierten Versionen dann irgendwann einstellen. Außer die Anwender meutern. Für den Benutzer heißt es dann, entweder die angepassten Snap nehmen oder nicht die angepasste Version von Mozilla.

Zitat von .DeJaVu

Diese Speicheranzeige hat mMn nichts mit OOM zu tun

Die Speicheranzeige sagt klar, es wäre Speicher da. Wenn man den Cache berücksichtigt ist der zwar fast komplett belegt. Doch sollte Windows den Cache bei Bedarf sofort freigeben.

Es gibt eigentlich nur zwei mögliche Ursachen. Ein Bug im Fuchs oder in Windows.

Zitat von Duckdon

Ich boote einmal die Woche den PC und habe im Schnitt zwischen 600 und 800 Seiten, in 25 Fenstern, im FF auf.

Das dürfte Teil des Problems sein. Der aktiv benutze Speicher von 3,5 Gig dürfte dafür nicht reichen. Das spricht dafür, dass ein Großteil vom Firefox schon freigegeben wurde und Windows den noch im Cache von immerhin 6,6 Gig hält. Kann mir auch keiner erzählen, dass man 800 offenen Seiten braucht.

Zitat von .DeJaVu

BitWarden ein anderer (wobei Bitwarden auf MS Azure und deren Server setzt und damit die Sicherheit MS zuschustert ;))

Was soll denn das für ein Argument sein? MS-Bashing? Buh ...

Jeder dieser Anbieter nutzt irgendwas. Wenn es nicht MS Azure ist, dann vielleicht AWS. Oder sie haben sich sonstwo eingemietet. Es kann ja nicht jede kleine Firma eine eigenes RZ betrieben. Auch er Server für dieses Forum steht bestimmt nicht bei Sören im Keller. Wenn du sagen willst, du vertraust MS nicht, dann stellt sich die Frage, warum du dann Windows verwendest. Wenn MS böse wäre, könnten sie jedes deiner Passwörter direkt bei der Eingabe abfangen. Dazu brauchen sie Azure nicht.

Am Ende wird der persönliche Geschmack den Ausschlag geben. Mir geht es dabei so wie .DeJaVu. Ich finde, Firefox macht es endlich richtig. Mein Geschmack.

Zitat von Sören Hentzschel

dass helles Licht viel stärker reflektiert (was eh jeder weiß, der Grundlagen-Wissen in Physik hat)

Zitat von Sören Hentzschel

Es ist wie gesagt erstens Grundlagenwissen in Physik, dass helles Licht stärker reflektiert,

Achtung Stolperfalle. Licht reflektiert nicht. Es wird reflektiert. Du meinst bestimmt blendet stärker, strengt die Augen mehr an oder so etwas. Wenn man direkt in den Bildschirm sieht, spielt die Reflexion keine Rolle. Abgesehen von störenden Spiegelbildern anderer Lichtquellen auf dem Bildschirm.

Eine helle Farbe bedeutet auch nicht automatisch stärkeren Lichtstrom. Eine 500 W Quelle in einem dunklen Rot ist unangenehmer als 1 W strahlendes Weiß.

Jep, den zweiten Part habe ich nicht realisiert. Ändert nichts am technischen Ablauf, wie beschrieben.