Beiträge von WismutKumpel

Sorry, aber ich habe selten einen größeren Unsinn gelesen.

Der Nutzer, von dem du glaubst ihn erfolgreich ausgesperrt zu haben, lädt sich den portablen Fx herunter oder steckt einen USB-Speicherstick auf dem sich diese Anwendung befindet an diesen Rechner an. Als normaler Nutzer gestartet, hat er sofort seinen eigenen Firefox.
Und wenn er etwas pfiffig ist, kopiert oder verlinkt er sich dein (!) FX-Profil dorthin und hat damit alle deine gespeicherten PW, Links und sonstige Profildaten.

Deshalb: Der einzige sinnvolle Weg ist und bleibt das Anlegen von eingeschränkten Benutzerkonten!

MfG WK

Hallo Bougie,

NEIN, ich kann deine vielen berechtigten Fragen auch nicht alle beantworten. Zumal du wirklich schon sehr viel getan hast!
Und "sicher ist sicher" mag zwar stimmen, aber "allzuviel ist ungesund" auch. Und wenn ein bestimmtes "SIcherheits-"Programm als aggressiv bekannt ist, dann bedeutet das auch, dass hier ab und an mal mit Fehlalarmen zu rechnen ist.

Zitat

Kenne mich mit den Begriffen Host-Datei und Proxy-Einstellungen nicht aus.

Aber dafür liefert die Suchmaschine deines Vertrauens gute Ergebnisse. Zum Beispiel: Hosts -Datei – Wikipedia oder auch Proxy – Wikipedia.
Was du jederzeit tun kannst, ist die in dem Wikipediabeitrag gezeigte hosts-Datei mit der auf deinem Rechner zu vergleichen. Der Pfad dahin ist ja auch beschrieben. Einfach mit einem Editor öffnen. Sieht sie in etwa so aus, wie in dem Beispiel ist alles in Ordnung. Stehen dort aber viele dir völlig unbekannte Einträge drin, KANN das die Auswirkung von Schadcode sein. Ziel: jemand will dich auf bestimmte Seiten umlenken, und ein Schadprogramm hat diverse Einträge dafür verändert.
ACHTUNG: Es kann aber auch sein, dass das mal jemand bewusst gemacht hat, um bestimmte "böse" Seiten gegen localhost (127.0.0.1) zu verlinken. Damit sind diese nicht mehr aufrufbar.

Ähnlich ist das mit dem Proxy. Normalerweise hat ONU keinen Proxy eingetragen. Auch hier KANN ein Schadprogramm Umleitungen programmieren. Das kannst du irgendwo in den Systemeinstellungen überprüfen (ich habe hier keine WinDOSe, kann dir also aus dem Kopf keinen Pfad nennen).

=> Also: Es ist möglich, dass da Schadsoftware was verstellt hat!

Was weiter?
Abgesehen von dem vollig richtigen Einwurf von unserem Boersenfeger, welchen ich bei der Zwischenvorschau gerade entdeckt habe, gibt es für mich nur eine einzige sichere Methode, um einen Rechner auf Schadcode zu untersuchen: Das Booten des Rechners von einer "desinfec´t"-DVD! Bei dem dabei startenden Linux-System werden bei inaktivem (!) Windows vier tagesaktuelle AV-Scanner auf den Rechner angesetzt. Das dauert viele Stunden, hat aber den Vorteil, dass sich der Schadcode nicht vor dem laufenden Windows verstecken oder gar den AV-Scanner deaktivieren kann. Wenn dann alle vier keinen "Befall" gemeldet haben, kannst du sicher sein, alles getan zu haben, was einem privaten Nutzer möglich und zumutbar ist.
Also frage mal einen deiner Kollegen und Freunde, ob er zufällig Leser der c´t ist.

Viel Erfolg!

MfG Peter

OK, das bedeutet also, dass der Firefox dieses "Sicherheitsfeature" lediglich von einer positiven OCSP-Antwort abhängig macht? Na ja ... .

Bei mir war (zur Erinnerung: immer nur "graues Schloss") Security.OCSP.enabled = 0 und das bedeutet: Status = vom Benutzer geändert.
Ich kann mich nur nicht erinnern, diese Einstellung jemals geändert zu haben. Zum einen wüsste ich das, und zum anderen habe ich mir schon vor Jahren angewöhnt, jede Änderung an irgend einer Konfigurationsdatei zu dokumentieren.

Flugs auf "1" geändert, und schon wird das Schloss bei https://mozilla.org grün. Damit der Beweis, dass man das nicht etwa an der Policy festmacht, sondern lediglich am OCSP-Responder.

BTW:
Netter Nebeneffekt: Ich betreibe für meine gar nicht mehr so kleine "Privat-CA" einen eigenen OCSP-Responder. Und dieser ist selbstverständlich auch in allen meinen Zertifikaten eingetragen. Und nun zeigen mir die TLS-Verbindungen zu meinen beiden RasPi und zu meiner Synology-NAS, dass ich hier eigene "EV-Zertifikate" produziere. Schööööön!
Da muss ich doch gleich mal eines der Zertifikate sperren und mal sehen, ob das dann wenigstens richtig im Browser angezeigt wird.

Meinen Dank für die Lösung des "Problems" an den Nachdenklichen!

MfG WK

Hallo,

das Forum hat zwar ggw. andere Probleme, mit denen es sich "mit Freude" befasst ... , aber ich habe versprochen, mir die Zertifikate mal genauer anzusehen und das will ich jetzt abschließen.

Egal mit welchem meiner drei installierten Browser (Firefox, Konqueror und Opera) ich die Seite https://www.mozilla.org aufrufe, es wird wie zu erwarten, immer das gleiche Zertifikat angezeigt und es ist als solches auch herunterzuladen.
Die Zertifikatsseriennummer (08:e4:ee:f2:d2:a0:92:ae:d3:1e:40:b9:95:70:fe:29), die Gültigkeitsdauer, der SHA-1-Hash und der angezeigte MD-5-Hash sind überall gleich und entsprechen den Werten, welche in den Screenshots meiner beiden Vorposter ebenfalls zu sehen sind. Zum SHA-256 komme ich noch.

Ich habe mir auch die Signatur durch den Herausgeber (DigiCert Inc.) angesehen, und deren Herausgeberzertifikat mit einem frisch von denen importierten verglichen => das verwendete Zertifikat von http://www.mozilla.org ist korrekt signiert und somit "sauber". Wenn wir also dem Herausgeber vertrauen, können wir auch dem Z. von mozilla vertrauen.

Zu dem in der Anzeige fehlenden SHA-256-Hash:
Der in der Anzeige zu sehende Hashwert ist jener, der bei der Hashwertprüfung eines im Binärformat (also .der) heruntergeladenen Zertifikates angezeigt werden sollte. Dabei ist es fast uninteressant, ob es sich um einen SHA-1, SHA-256 oder MD5-Hash handelt. Auch wenn MD5 heutzutage als gebrochen gilt und SHA-1 baldmöglich außer Dienst gestellt werden sollte (das empfiehlt das BSI schon mindestens 8 Jahre), so bedeutet das doch lediglich, dass ein "Angreifer" mit viel Zeit und Rechenleistung künstlich eine Datei generieren könnte, welche einen bestimmten, gewünschten Haswert aufweist. Also meinetwegen den eines Zertifikates. Aber diese Datei ist dann lediglich eine größere Ansammlung binären Mülls, welche eben den gewünschten Hashwert hat. Ein verwendungsfähiges Zertifikat ist es garantiert nicht! Intern wurde für die Signatur "unseres" Zertifikates so wie so SHA-256 verwendet.
Die im Zertifikat angezeigten Haswerte sind also lediglich ein Hilfsmittel für "misstrauische" (nein, besser: "sicherheitsbewusste"!) User, welche sich ein Zertifikat mal ganz genau ansehen wollen.

Unabhängig davon kann ich jede mir in die Finger kommende Datei mit der Vielzahl der uns zur Verfügung stehenden "Haswertgeneratoren" (besser: Prüfsummenwerkzeuge) in ihren Haswert zerlegen. Und wie ihr gleich seht, stimmt auch der SHA-256-Hash des mozilla-Zertifikates mit dem im Screenshot von .Hermes angezeigten überein:

peter@sonne:~/Dokumente> sha1sum www.mozilla.der 
6a5ab45927d1165d5d22e47a09d078979f36823d  www.mozilla.der
peter@sonne:~/Dokumente> 
peter@sonne:~/Dokumente> sha256sum www.mozilla.der 
d475eedbffe1eef8191e3e4b88f37311ff6667c502bd9778ec8710e872f91eb9  www.mozilla.der
peter@sonne:~/Dokumente> 
peter@sonne:~/Dokumente> md5sum www.mozilla.der 
8f917e81269067d7d65397a694d05843  www.mozilla.der
peter@sonne:~/Dokumente>

Zurück zur "grünen Adressleiste":
Das was man neuerdings gerne als "EV-Zertifikat" bezeichnet ist genau das, was bei uns als "Zertifikat für die qualifizierte elektronische Signatur" für Personenzertifikate durchgeht. Und eine der Voraussetzungen für ein QES-fähiges (Personen-)Zertifikat ist (§5 SigG) die "Sichere Identitätsprüfung der antragstellenden Person". Und deshalb muss der Antragsteller für ein Serverzertifikat bei uns mit einem notariel bestätigten Handesregisterauszug nachweisen, dass seine Firma diesen Server betreibt und er selbst bestellberechtigt ist. Das bestätigt dann der Herausgeber in dem von ihm signierten Zertifikat, Servername und Eigentümer. Eigentlich sollte das ja auch die Hauptaufgabe eines seriösen TrustCenters sein!
Leider überfluten "Billigheimer" und "Kostnix-Zertifikate" den Markt und leider werden zunehmend auch derartige Herausgeber mit ihren Herausgeberzertifikaten in die Browser usw. bereits vom Hersteller aus installiert. Das bedeutet, kein (Normal-)Nutzer kann mehr sicher davon ausgehen, dass der eingetragene Eigentümer des Servers authentisch ist.
In den kryptischen Zahlenkolonnen unter "Erweitert" im Zertifikat verbergen sich die zwar öffentlich dokumentierten aber nur Fachleuten bekannten Richtlinien und Zertifikatsklassen (Policy). Und ich vermute mal, dass diese Einträge der Firefox auswertet und damit die Kennzeichnung in der Adresszeile gestaltet. Ich wüsste sonst nicht, wo dieses in einem Zertifikat sonst noch untergebracht werden kann.
Und ich weiß auch nicht, warum mein eigener Firefox ein so genanntes "EV-Zertifikat" nicht erkennt und immer nur ein graues Schloss anzeigt - und der Firefox von .Hermes dieses drauf hat. Aber ich muss ja auch nicht alles wissen

MfG WK

.Hermes:
Lass dir bitte mal das Zertifikat anzeigen und poste bitte die Ansicht hier. Will nur mal vergleichen.
BTW: Bei mir ist die Anzeige auch blau/schwarz und ohne Anzeige des Seitenbetreibers. Dem will ich mal mit dem Vergleich auf den Grund gehen.

Hallo allerseits ...

ich nutze hier die v.31.0 unter Linux (openSUSE 13.1) und ich kann mich nicht erinnern, hier jemals eine grüne Adessleiste gehabt zu haben. Ich habe allerdings damit auch keinelei Problem. Ich sorge schon dafür, dass unsichere Kandidaten unter den Herausgebern rechtzeitig aus dem Zertifikatsstore rausfliegen. (Ich guttenborge dazu dienstliches Wissen und wende es privat an. Tage oder Wochen später zieht dann ein Update zumindest teilweise nach.)

[Vermutung!]
Könnte es evtl. sein, dass du auf einem der anderen synchronisierten Geräte irgend ein Add-on oder Thema oder eine dir nicht bewusste Einstellung hast, welche sich dann per Sync auf dem bewussten Client auswirkt?
[/Vermutung]
edit: Ich sehe gerade, dass etwas derartiges/ähnliches Börsenfeger auch im Beitrag #4 vermutet.

MfG WK

Technisch gesehen ist es ein- und dasselbe, ob du die "Lokalen Ordner" oder ein "kastriertes POP3-Konto" benutzt. In beiden Fällen werden die E-Mails in mbox-Dateien gespeichert. Bei den "Lokalen Ordnern" fehlt lediglich die Verwaltung der Server- usw. Daten.
Da hast du beim Versuch, die "Lokalen Ordner" zu nutzen wohl irgend etwas falsch gemacht. Aber wichtig ist ja, dass du eine funktionierende Lösung gefunden hast.

Meine übliche Frage zum Schluss: Machst du jetzt eine regelmäßige Sicherung deines TB-Userprofils?
Schau dir auch mal dazu den folgenden Beitrag aus dem TB-Forum an: Re: [imap+lokal] Suche ideales System für Archivierung

So, und jetzt schnell weg ...

MfG WK

Hallo SueS,

und willkommen im Forum!

Zitat von SueS

Mein Admin hat meinen imap-User auf dem Mailserver gelöscht, d.h. dort sind alle Daten weg (keine Serversicherung).

Mal unabhängig von deinem Problem: Dieser "Admin", der keine Sicherung macht, gehört geteert, gefiedert und aus dem Job gejagt - wenn das o.g. wirklich zutrifft.

Da bis soeben von deinem Problem im TB-Forum noch nichts zu sehen ist, erlaube ich mir mal, hier das Risiko einzugehen, für diesen [OT]-Beitrag von den hiesigen "Powerusern" Dresche zu beziehen und dir gleich hier zu helfen.

Der Thunderbird bietet das (sonst bei IMAP-Clients unübliche!) Feature, in einem dynamischen lokalen Cache ("Nachrichten dieses Kontos auf diesem Rechner bereithalten") alle auf dem IMAP-Server befindlichen E-Mails noch einmal temporär und dynamisch in einer mbox-Datei auf dem Client zu speichern. Temporär und dynamisch bedeutet, dass dies keine lokale Sicherung ist, sondern immer mit dem Server synchronisiert wird! Also was auf dem bestehenden IMAP-Konto gelöscht wird, wird auch in diesem Cache gelöscht! Dieses Feature ist eine, per default aktive Option. Alles weitere geht natürlich nur, wenn diese Option weiterhin aktiv war.

Deshalb: Rechner vom Netz trennen und nicht mehr mit dem Server verbinden!

Lösung für dein Problem:

• Unsere Anleitung lesen und verstehen, Begriffe wie "mbox" und "Profil" müssen bekannt sein! => 12 Profile
• Dann machst du erst einmal eine Sicherheitskopie deines vollständigen (!) TB-Userprofils, denn man weiß ja nie ... . (Verantwortungsbewuste User machen das regelmäßig oder gar täglich!)
• Du beendest den TB und gehst mit dem Dateimanager in dein TB-Userprofil > \ImapMail\<das bewusste Konto>
  Dort suchst du die endungslosen mbox-Dateien ("INBOX" oder auch die mit dem Namen deiner Unterordner) und kopierst diese nach .../Mail/Local Folders. Pass auf, dass du dort keine evtl. vorhandene gleichnamige Dateien überschreibst (sonst eine davon vorher umbenennen). Die Indexdateien (.msf) kopierst du nicht. Nimm alles mit, was du an mbox-Dateien in deinem (ehemaligen) IMAP-Konto findest. Löschen und sortieren kannst du immer noch.
• Beim nächsten Start des TB werden in den "Lokalen Ordnern die kopierten mbox-Dateien als "Mailordner" angezeigt, indiziert und in diesen alle noch vorhandenen E-Mails. Diese kannst du einfach dort liegen lassen, oder du kannst dir auch dort oder auch in einem anderen Mailkonto eine Ordnerhirarchie aufbauen und die Mails nach dorthin kopieren/verschieben.
• Sollten Mails nicht mehr angezeigt werden, hast du die Chance - falls du nicht vorher die Funktion "Komprimieren" genutzt hast - diese bislang nur als gelöscht markierten Mails mit dem Add-on "Recover deleted Mails" wieder herzustellen.

Ich wünsche dir viel Erfolg!

MfG WK

Hallo BS2000,

[OT], denn das gehört eigentlich nicht zu diesem Thread!
w
Wieso irgendwann? (Ja, es gibt Bürger, die noch den "alten" PA haben)
Auf jedem nPA ist bereits ein private key und das dazugehörige Zertifikat enthalten. Dieses Zertifikat ist von seinen Möglichkeiten so beschränkt (bewusst beschränkt worden!), dass es ein reines Authentifizierungs-Zertifikat ist. Das bedeutet, es könnte, wenn alle mitspielen würden, sofort zur Authentisierung seines Besitzers bei der sicheren Anmeldung an diversen IT-Systemen, Foren, bei Banken, Behörden usw. verwendet werden. Der private key welcher zur Authentisierung genutzt wird ist mit einem nur dem Inhaber bekannten Passwort (PIN) gesichert, welches in Verbindung mit dem Mikroprozessor des RFID-Chips nach wenigen (3 ?) Fehlversuchen zur Sperrung dieses Schlüssels führt.
IMHO ist das die ggw. sicherste für die Breitenanwendung geeignete Methode zur Authentisierung. Und von der Sicherheit her stellt diese Anmeldung jede Benutzung von Benutzername/Passwort locker in den Schatten.
Nur leider ist dieses Thema noch nicht in den Köpfen der Nutzer angekommen. Und leider sind die bürokratischen Hürden für die Nutzung noch sehr hoch und leider geistern in den Köpfen noch viele von Unwissenden verbreitete Märchen hinsichtlich der "Unsicherheit" des Verfahrens herum. Und wer will schon Geld für einen Kartenleser ausgeben ... .
[/OT]

Zurück zum Thema!
Mit dem o.g. Zertifikat (*) auf dem nPA authensisiert sich der Nutzer mit seiner eigenen "elektronischen Identität" gegenüber dem Server. Macht also nur dort Sinn, wo eine derartige Auth. gewünscht bzw. erforderlich ist.
Mit dem Zertifikat eines Servers ist es genau umgekehrt.
Der Server zeigt dem Client bei der Verbindungsaufnahme sein von einem vertrauenswürdigen TrustCenter herausgegebenes Zertifikat vor. Damit beweist der Server, dass es sich um exakt den vom Nutzer bewusst angesteuerten Server handelt. Und als "Nebenprodukt" wird die Verbindung auch gleich mit verschlüsselt.
Drängelt sich ein Angreifer mit Hilfe eines "Man-in-the-Middle-Angriffes" in die Verbindung rein, erkennt dies der Client und warnt den Nutzer (so lange es der Angreifer nicht geschafft hat, sich ein gültiges, also von dem ausstellenden und im Client bekannten TrustCenter signiertes, Zertifikat zu beschaffen).

Um ein derartiges Zertifikat vom Client als gültig anzuerkennen, ist es erforderlich, dass diesem für die Gültigkeitsprüfung auch die Herausgeberzertifikate des ausstellenden TrustCenters zur Verfügung stehen. Wir nennen dieses gültige Herausgeberzertifikat auch gern den "Vertrauensanker".
Vertrauen heißt hier, dass wir davon ausgehen können, dass dieses TrustCenter einem Antragsteller nur dann ein auf seinen persönlichen Namen (bei Nutzerzeritifikaten, wie z.Bsp. dem auf dem nPA) oder Servernamen ausstellen, wenn dieser durch Vorlage bestimmter amtlicher Dokumente seine Identität beweist. Bei Servern muss da z.Bsp. ein notariel beglaubigter Handelsregisterauszug gebracht werden, aus dem hervorgeht, dass diese Firma den Server <example.com> betreibt und der Antragsteller von dieser Firma zur Antragstellung befugt ist. Es bedeutet aber auch, dass dieses TrustCenter bestimmten technischen usw. Ansprüchen genügt.
Ob ein TrustCenter diese hohen Anforderungen auch durchsetzt, auf welcher Technik die Zertifikate hergestellt werden, welche personellen, baulichen und verfahrenstechnischen Vorschriften angewandt, welche Prüfungen wann und durch wen durchgeführt werden, uvam. steht in der "Zertifizierungsrichtline" (der "Policy") eines jeden TrustCenters öffentlich beschrieben.
Das kann und will natürlich kein Nutzer lesen und schon gar nicht bewerten! Deshalb übernehmen es die Herausgeber der Browser, Mailclients oder Betriebssysteme "nach bestem Wissen und Gewissen und hoher Sachkunde" (sollte man zumindest annehmen, es gibt leider auch Gegenbeispiele!) diese Überprüfung vorzunehmen und nur den Kriterien entsprechende TrustCenter in ihren Produkten vorzuinstallieren. => Das sind die vielen Einträge, welche bereits im Firefox, Thunderbird oder direkt auf der WinDOSe zu sehen sind.
Und damit werden die Serverzertifikate, aber auch S/MIME-Zertifikate für die Mailverschlüsselung die von diesen TC herausgegeben wurden, auch automatisch als gültig erkannt. (Wenn sie noch innerhalb des Gültigkeitszeitraumes sind, wenn der in ihnen eingetragene "common name" die E-Mailadresse und andere Angaben "passen" und die Signatur valide ist.)

Und was sind nun die Zertifikate, für die wir eine Ausnahmegenehmigung erteilen sollen?
Das sind alle Zertifikate, bei denen "etwas nicht stimmt"!
Kein Herausgeberzertifikat im Client/BS vorhanden, abgelaufene oder gesperrte Herausgeberzertifikate, nicht stimmende Servernamen, üble Tricks der Hersteller von AV-Scannen, die mit Hilfe eines MitM-Angriffs die verschlüsselte Verbindung überwachen möchten usw. Damit kann also der Nutzer alles, was ein X.509-Zertifikat an Sicherheit bringt/bringen soll, aushebeln!

Ich bezeichne diese Ausnahmegenehmigung als die schlechteste Krückenlösung die es gibt! Zumindest sollte diese nur nach sehr gründlichem Nachdenken erteilt werden!

Bei einem bekannten Herausgeber von Zertifikaten kann der User selber etwas nach einem Herausgeberzertifikat suchen. Bei einem Router- oder Drucker- usw. Hersteller findet man fast immer dessen Herausgeberzertifkat - und man kann dieses auch nach entsprechendem Nachdenken bewusst als solches importieren und ihm das Vertrauen aussprechen.
Gleiches trifft zu bei einem von uns selbst hergestellten Zertifikat. Ist es eine Eigenproduktion habe ich auch mein eigenes Herausgeberzertifikat und es spricht absolut nichts dageben, dieses in den Browser usw. zu importieren. Wem sollten wir vertrauen, wenn nicht uns selber?
Ich stelle z.Bsp. mit meiner "Privat-CA" jedes Jahr mehrere Hundert Zertifikate für Familie, Freunde ... und diverse Forennutzer (auch hier ...) her. Und diese Nutzer (die immer wieder nachfragen ...) haben alle mein Herausgeberzertifikat importiert. Vor allem natürlich im Thunderbird. Aber auch so mancher private Webserver, manche ownCloud auf dem RasPi usw. läuft damit.

Fazit: fast immer kann man diese "Ausnahmegenehmigung" vermeiden, indem man bewusst (!) einem nicht gelisteten TrustCenter nach genügend eigenem Nachdenken das Vertrauen ausspricht.

(*) Ich vereinfache hier mal, indem ich nur "Zertifikat" schreibe, und bewusst keine Unterscheidung zw. private key und Zertifikat herausstelle. Zertifikat ist immer öffentlich! Ich versuche überhaupt so verständlich und mit Vereinfachungen zu schreiben, wie ich es noch verantworten kann. Ich will auch bewusst nicht darauf eingehen, dass verbrecherische (und auch staatliche ...) Organisationen gerne mal hier einiges aushebeln indem sie einen Einbruch machen oder TrustCenter zur Kooperation zwingen.

MfG WK

Hallo Fritz,

bei Linux ist alles ein klein wenig anders ... .
Die zu installierenden Programme werden alle in den so genannten "Repositories" (=> "Programmsammlungen") bereitgestellt. Da gibt es zum einen die offiziellen, von openSUSE bereitgestellten Repos mit den stabilen und getesteten Versionen. Diese kannst du bedenkenlos ins System einbinden, und von dort die gewünschten Programme und Betriebssystem-Bestandteile installieren bzw. aktualisieren. Dann hast du ein stabiles und problemlos laufendes System.

Dann gibt es noch eine Reihe als "Community-Repos" bezeichnete Repositories. (Zum Bsp.: http://download.opensuse.org/repositories/m…/openSUSE_13.1/ ) Auch diese kannst du (meistens) als stabil betrachten, und von dort kannst du aber auch neuere Versionen installieren, die es noch nicht in den offiziellen stabilen Zweig gebracht haben. Sie heißen beim Firefox ggw. alle 29.0.1 - gefolgt mit sich fast täglich geänderten weiterfolgenden Versionsnummern. Bei wichtigen Programmen kommen fast täglich neue Versionen! Aber alles zum Bsp. unter Firefox 29.0.1 .
=> Das bedeutet, dass du im stabilen Zweig ggw. "nur" diese Version findest.

Und dann gibt es noch die "unstable"-Zweige. Hier tummeln sich Entwicklerversionen aller Art. Vieles auch schon compiliert und zum .rpm paketiert. Und natürlich kannst du dir auch die offiziellen Quellcode-Pakete herunterladen und selber compilieren.

Du musst dich jetzt entscheiden, ob du ein stabil laufendes System haben möchtest - oder ob du durch die Einbindung von unstable-Repos bestimmte Risiken eingehen möchtest.
Was relativ unproblematisch ist, ist aus den Quellen aktuelle von Mozilla freigegebene (aber eben nicht von openSUSE getestete) Versionen selbst zu kompilieren. Wenn du darauf achtest, dass diese Programme dann in gesonderte Verzeichnisse kopiert werden, kannst du diese unabhängig von den offiziellen Programmen aus den Repos mit deren vollständigem Pfad aufrufen und nutzen.

HTH!

MfG WK

edit: Gegenwärtig kam dein "Nachschlag".
Was hast du denn jetzt für eine Version? Ich habe soeben aktualisiert, bei mir ist es immer noch die Version. 29.0.1-24.1

Ich könnte mir vorstellen, dass damit dieses Problem gemeint ist: Sicherheit: Schadsoftware in Computermäusen

MfG WK

Dann sind WIR uns ja wieder einig.

Zitat von WismutKumpel

... Oder eher doch nicht?

Kannst du das als Mod. nicht sehen? :-???

Die Aktion "Fake-Daten an Webseiten senden mit Firefox" macht genau so viel "Sinn", wie SPAM an die angezeigten Absender zurück zu schicken.
Nämlich gar keinen.

BTW: Ich nutze gerade den Internet-Explorer 6 und als Betriebssystem Windows 95. Oder eher doch nicht?

MfG WK

Wenn ich mich recht erinnere, ging es dem TE um die Funktion seiner Tastatur, oder?

qrg?

Ich will das noch deutlicher sagen: er wird sich exakt genau so verhalten.
Mögliche Lösung : der TB bietet die Möglichkeit, mehrere smtp - Einträge anzulegen und einen davon dem jeweiligen Konto zuzuordnen. Du hast doch einen lokalen Provider. Richte dessen smtp-Server ein und ordne diesen dem Mailkonto zu. Auch Gmail soll da sehr kulant sein. Einfach testen. Du kannst dann beliebig umschalten.

OK?

MfG WK

BTW Feuervogel:
Ich bin mir nicht sicher, ob wirklich der Provider des Gastlandes den "grenzüberschreitenden gehenden smtp-Traffic" blockiert. Ich denke eher, dass der dt. Provider wegen SPAM - Schutz keinen smtp-Traffic von ausländischen IP - Bereichen annimmt.

Falls du mich meinen solltest:

Meine "Besonderheiten":
1.) Da ich so gut wie alle meine Mails mit S/MIME verschlüsselt sende und empfange, habe ich in meinem Thunderbird (und nur dort) mehrere eigene X.509-Zertifikate mit privaten Schlüsseln gespeichert. Deshalb nutze ich im Thunderbird den eingebauten Passwort-Manager, mit dessen Masterpasswort auch die privaten Schlüssel wie beschrieben geschützt werden.
Wer wie ich seine Mails mit S/MIME verschlüsselt und signiert, sollte auf diesen Schutz nicht verzichten! (Und das trotz der umfangreichen Sicherheitsmaßnahmen, mit welchen ich meine Linux-Rechner härte bzw. zu härten versuche.)
Würde ich in meinem PW-Manager lediglich meine Kontenpasswörter speichern, würde ich hier auf das Master-PW verzichten. (Aus gewissen Gründen kann man diese seit dem 01.07.2013 leider nicht mehr als "Geheimnis" bezeichnen.)

2.) Für den Firefox nutze ich nicht den integrierten PW-Manager, sondern den zentralen PW-Manager meines Betriebssystems mit Namen "KWallet". Dieser speichert systemweit sämtliche Passwörter und Zugangsdaten, und das mit einer für unsere kleinen privaten "Geheimnisse" sehr guten kryptologischen Härte. Leider speichert er noch nicht die S/MIME-Schlüssel. Und selbstverständlich nutze ich hier ein Masterpasswort.
KWallet spielt in einer Liga mit anderen guten Passwortmanagern, wie KeePass u.a.
Der für mich einzige Grund, nicht den PW-Manager des Firefox zu verwenden ist nicht etwa, dass ich diesem nicht vertraue, sondern einzig und allein, dass die anderen PW-Manager systemweit speichern können, und nicht nur die PW eines einzigen Programms. Den Kryptocontainer meines KWallet hoste ich in meiner Owncloud (so was wie Dropbox, aber eben nicht im Amiland, sondern bei mir zu Hause), und somit nutze ich auf allen meinen Rechnern die gleiche Datei. Meine Linksammlung synchronisiere ich mit der eingebauten Funktion des Fx - und bin damit voll zufrieden.

MfG Peter

Palli:
Du musst genau zwischen den "Zertifikaten" (richtiger: "X.509-Zertifikaten") und den eventuell (aber sehr unwahrscheinlich!) auf deinem Rechner vorhandenen privaten Schlüsseln zu Zertifikaten unterscheiden.

Die Zertifikate sind die öffentlichen Schlüssel und ein paar weitere Zertifikatsdaten wie Gültigkeitsdauer, Servername usw. diverser SSL nutzender Server oder der Herausgeber von Zertifikaten, also der TrustCenter. => alles öffentlich, nicht verschlüsselungswürdig und auch jederzeit wiederherstellbar.
Private Schlüssel ("private key" oder auch "geheime Schlüssel" genannt) hast du auf deinem Rechner nur vorhanden, wenn du selbst deine Mails mit S/MIME verschlüsselst (dann aber eher im Zertifikatsspeicher des Thunderbird) oder wenn du dich mit dem Browser an entsprechend gesicherten Servern mit Hilfe der bewusst selbst beschafften eigenen Zertifikate (hier sprechen wir eher von "Schlüsseldateien" = Zertifikat + private key) anmelden oder verschlüsselt kommunizieren kannst. Aber das würdest du garantiert wissen, wenn das zutreffen würde.

Und, zum Thema zurück, diese privaten Schlüssel werden bei Fx und TB in der Datei "key3.db" gespeichert. Und diese wird ebenfalls mit einem aus dem Masterpasswort abgeleiteten Schlüssel geschützt.

OK?

MfG WK

Hallo Toxie62,

vielleicht helfen dir folgende Informationen:
Du musst zuerst einmal zwischen den "offiziellen" IP, welche du dynamisch von deinem Provider zugeordnet bekommst, und den so genannten "privaten IP" unterscheiden, welche dein Router intern vergibt.
Dein Provider hat einen größeren IP-Bereich gekauft, und aus diesem bekommst du bei jeder Einwahl (z. Bsp. nach der Zwangstrennung) eine IP zugeordnet. Dadurch resultiert dann auch, dass bei dieser dann in der Regel die ersten Zahlen gleich sein können. Mitunter passiert auch, dass du die gleiche IP wieder bekommst. Kann dir aber letzendlich egal sein.

Dein Router vergibt für dein eigenes Netz selbständig und automatisch jedem angemeldeten Gerät eine so genannte "private IP" aus einem in den Routereinstellungen festgelegten Bereich und für einen festgelegten Zeitraum. Dieser Bereich ist zum Beispiel bei der originalen Fritz-Box: 192.168.178.0. Privat bedeutet hier zum einen, dass IP aus diesem Bereich nicht über das Internet geroutet werden können, sie sind also nicht über das Internet direkt erreichbar. Und zum anderen bedeutet das, dass diese privaten IP-Bereiche mehrfach vergeben werden können.
Im Endeffekt kann es dir normalerweise auch völlig egal sein, welche IP deine internen Geräte bekommen. Und ja, diese IP kann sich auch mal ändern. Einen Grund hat dir ja Palli genannt. Aber auch wenn ein Gerät oder im Urlaub der ganze Router mal ein Weilchen ausgeschaltet war, kann dies vorkommen. Dann ist eben der Zeitraum (auch "Lease" genannt) abgelaufen, und der Router ordnet die IP neu zu.
Es gibt eine kleine Ausnahme, wo dich die IP deiner Geräte interessiert: wenn du nach außen bestimmte Dienste anbieten würdest (meinetwegen einen Serverdienst wie ssh oder ftp o.ä.). Dann ist es wichtig, dass die betreffenden Geräte immer die gleiche IP erhalten. Dann bietet dir die Fritz-Box (und auch andere Router) die Möglichkeit, auch mit DHCP (der dynamischen Adressvergabe) den Geräten dauerhafte IP zuzuweisen.

Fazit: Alles normal und identisch mit dem, was Palli in seinem letzen Satz geschrieben hat.

MfG WK