Beiträge von WismutKumpel

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

Ist doch interessant, wie lange sich so ein IMHO sinnfreier Thread hält und welche Ressourcen er bindet.
(BTW: Beim Warten im Auto getippt, Also "ressourcenfrei".)

Wobei ich sogar bezweifele, dass ohne Verwendung eines Master-PW überhaupt eine Verschlüsselung stattfindet.
Als vor einigen Jahren in den Mozilla-Produkten noch keine sqlite-Datenbanken genutzt wurden, sondern die PW-Datei noch "signons.txt" hieß, da konnte man mit einem schnöden Texteditor ganz einfach sehen: Ohne Master-PW => Passwort im Klartext, mit Master-PW => PW verschlüsselt.

Welchen Sinn sollte es machen, irgendwelche Daten ohne PW zu verschlüsseln? Mit dem Hashwert von NULL? Oder mit dem vielleicht eingebauten Standard-Passwort "mozilla"? Aber möglich ist das schon, um eine Verschlüsselung für ONU zu erreichen, auch wenn diese Verschlüsselung eigentlich völlig sinnfrei ist. Die Masse der hier mitlesenden Nutzer wird wohl eine Standardcodierung mit meinetwegen Base64 auch als "Verschlüsselung" akzeptieren weil es kein lesbarer Klartext ist.

Ich habe auf diesem Rechner keinen sqlite-Browser, kann mir den Inhalt der sqlite-Datenbanken ggw. leider nicht ansehen.
Aber warum sollte sich ein "Angreifer" unbedingt in das Thema "sqlite" einarbeiten, wenn der Thunderbird mit dem PW-Manager eine genau darauf abgestimmte GUI liefert?

Die Datei "key3.db" ist meines Wissens die "Schlüsseldatei für Zertifikate", also die Datei, in welcher die privaten Schlüssel der eigenen X.509-Zertifikate gespeichert werden. Und die installierten (fremden root- oder Server- oder Nutzer-) Zertifikate (also ohne private Schlüssel) werden in der "cert8.db" gespeichert. Dürfte also nur für User relevant sein, die eigene X.505 Schlüsseldateien (.p12, .pfx) importiert haben, und vor allem beim Fx auf die allerwenigsten zutreffen. Beim TB betrifft das die Nutzer, die wie ich auf S/MIME setzen.

Zitat von Sören Hentzschel

Darum ist die Verschlüsselungsmethode der einzelnen Passwörter unwesentlich. Die Sicherheit steht und fällt mit dem Master-Passwort. Wenn das so gewählt wird, dass es leicht zu erraten ist, oder gar nicht verwendet wird, dann nützt auch die Verschlüsselung der Passwörter nichts.

Absolute Zustimmung!
Ich schrieb ja schon andeutungsweise, dass die "Dienste" seit dem 01.07.2013 unsere PW ohne größere juristischen Hürden bei den Providern anfordern können, und die Provider diese auf dem Silbertablett liefern müssen. Aus "gutem Grund" wurden als juristisches Hemmnis lediglich Ordnungswirdrigkeiten (!!) angegeben. Damit dürfte also bei jedem von uns die Genehmigung für das Liefern lassen der PW vorliegen. Also haben diejenigen, welche (eventuell!) über die nötige Hardware für das "Brechen" der Verschlüsselung verfügen, gar keinen Anlass, diese dazu zu nutzen.
Und was den "Rest" der Neugierigen betrifft, dann sollen die mir erst einmal beweisen, "wie schnell" sie eine mit 3DES und einem wörterbuchresistenten langen Zufallspasswort mit großem Zeichenumfang als PW verschlüsselte Datei entschlüsselt haben. Freiwillige vor!

Also noch einmal: Ich sehe es nicht als problematisch an, ob nun die Passwortdatei mit 3DES oder mit AES verschlüsselt ist! Beides ist für den "normalen Neugierigen" mit eingeschränkten materiellen und finanziellen Ressorcen jenseits von "gut und Böse".

MfG WK

Hallo. Jusar,

du hast ja völlig Recht, und was deine letzten Satze betrifft, da gehen wir auch völlig konform.
Das Problem mit den Passwörtern ist IMHO aber ein anderes. Für die Masse derjenigen, die kein Passwort setzen, ist es nämlich "absolut unzumutbar" dieses zu tun. Das bedeutet im Klartext, dass, wenn wir sie dazu zwingen würden, uns diese Leute in Scharen davonlaufen würden zu Browsern, die dieses nicht verlangen. Es würden also "Marktanteile" verloren gehen. Und das will ja keiner.

Zur symmetrischen Verschlüsselung:
3DES ist zwar ein sehr alter Algorithmus, aber er ist bis heute nicht kryptologisch (!) gebrochen worden. Und ein brute-force-Angriff darauf ist auch heute noch nicht so ohne weiteres "nebenbei" durchführbar. Diejenigen, die diese Ressourcen haben, brauchen Sie nicht mal zu nutzen, denn sie bekommen bei "Bedarf" unsere PW ja frei Haus von den Providern geliefert. Und der neugierige Sohn/Nachbar/Kollege, der sich deine signons.sqlite gezogen hat, soll das erst mal machen.

Ich sehe also, was die Passwortspeicherung in Fx und TB betrifft gegenwärtig noch keine Probleme.

Völlig anders sehe ich das bei der s/mime-Verschlüsselung im Thunderbird.
Es ist unumstritten, dass man sich mit der Einführung von s/mime auf einen Algorithmus einigen musste, den alle MUA beherrschen. Und damals gab es eben nur 3DES. Und das war auch noch der damals beste und sicherste Algorithmus.
Nur heute kann fast jeder MUA auch AES. Selbstverständlich auch der TB! Zumindest kann er damit verschlüsselte Mails lesen. Warum er diesen Algorithmus nicht selbst zum Senden nutzt, ist mir unverständlich. Manchmal frage ich mich schon, ob es daran liegen könnte, dass Mozilla.org gewisse US-Gesetze beachten muss.

MfG WK
Getippselt per Tapatalk 2 auf meinem SGS III

"Ihn", nicht "mich".

MfG WK

Und du verstehst jetzt auch, warum (Zitat deiner Überschrift) "Sicherheitswarnung nicht mehr anzeigen" niemals die Lösung sein kann?

Ich versuche bei unverständigen Nutzern Sicherheitswarnungen in beliebiger Software immer mit dem kleinen roten "Lämpchen" im Auto zu vergleichen, welches ungenügenden Öldruck anzeigt.
Das rote Birnchen nervt doch nur!
Also rausdrehen und Ruhe ist!

MfG Peter

Zitat von Zitronella

Wat für ne schreckliche Hoster Seite,...

=> DANKE, Sören, dass du dir die Mühe gemacht hast...

Bitte poste mal die Zertifikatsdaten, welche auf den Rechnern gespeichert sind, welche keine Fehlermeldung hinsichtlich des Ablaufs der Gültigkeit bringen. Vergleiche auch mal mit den Daten des Z. auf dem Rechner mit der Fehlermeldung.
Ziel: herausfinden, ob das Zertifikat nun wirklich abgelaufen ist (wegen: wie ich oben gepostet habe), oder ob genau dieses Z. auf einem anderen Rechner als gültig angezeigt wird. Mich interessiert also die exakte Gültigkeit.
Weiterhin interessiert mich die Zertifikats-Seriennummer => für den nachfolgenden Test.

Was passiert, wenn du, so wie ich auch beschrieben habe, zumindest einmal die Fernwartung deaktivierst (Haken raus!), die Fritte neu startest und danach die Fernwartung erneut aktivierst? Dauert keine zwei Minuten ... .
Ziel: herausfinden, ob die Box bereits dadurch angeregt wird, ein neues Schlüsselpaar zu generieren. NEU bedeutet hier, ein anderes Gültigkeitsdatum (beginnend von heute) und eine andere Seriennummer.

Bei solchen Fehlern ist es immer notwendig die Ursache des Fehlers zu finden!
Und dafür kommen IMHO nur zwei in Betracht: Wirklich ein abgelaufenes Zertifikat (=> das würde bedeuten, dass bis auf den Rechner mit der Fehlermeldung die anderen Rechner die Gültigkeit des Zertifikates schlampig prüfen!) oder wirklich ein Problem bei dem Rechner mit der Fehlermeldung.
Andererseits zeigt diese Fehlermeldung ein zwar sinnloses, aber trotzdem deutlich zu sehendes Datum an.

Da ich (wegen besserer Möglichkeiten - ausschließlich Nutzung von VPN für den Fernzugriff!) diese einfache Fernwartungsfunktion nicht nutze, kann ich da leider bei mir nicht mitprüfen.

MfG WK

Hallo,

Die Fritz-Box generiert bei der ersten Freischaltung für den Fernzugang selbstständig ein Schlüsselpaar, welches auch selbst signiert wird. Klar, daher die Fehlermeldung betreffs Vertrauenswürdigkeit.

Vermutlich (!!) war zu genau dem Zeitpunkt des Signierens die Zeit der Box noch nicht synchronisiert und deshalb ist im Zertifikat ein Ablaufzeitpunkt wenige Jahre nach Beginn der Unix-Zeitrechnung eingetragen.
(korr: sogar eine absolut sinnlose Zeit!)

Ein Browser mit korrekt funktionierender Gültigkeitsprufung der Zertifikate bemerkt das, einer der schlampig prüft, merkt das nicht.

Ob du dieses abgelaufene Zertifikat bereits durch Deaktivierung des Fernzugangs (und Restart der Box sowie Neueinrichtung des Fernzugangs) los wirst, oder die ganze Box resetten musst, kann ich dir nicht sagen.

MfG WK
Getippselt per Tapatalk 2 auf meinem SGS III.

Zitat von sidre

Mein System ist nicht mit Viren oder Trojanern befallen (ich hatte in 25 Jahren noch keinen einzigen Befall....

Wo haben die Leute nur diese Sicherheit her? :-??

Wenn schon, dann bitte so:
Mein System ist höchstwahrscheinlich nicht mit Viren oder Trojanern befallen (die von mir eingesetzten AV-Scanner konnten in 25 Jahren noch keinen einzigen Befall feststellen .... ).

MfG WK

Guten Morgen!

Irgendwie erinnert mich diese Diskussion an das, was ich gerade bei androidpit.de gelesen habe:
CyanogenMod und der Daten-Wahnsinn: Gib mir alles, aber kostenlos 25

Noch mal zur Betonung: Gib mir alles, aber kostenlos

Oder wie Boersenfeger so richtig schrieb:

Zitat

wenn du die weitere Entwicklung von Firefox nicht unterstützen möchtest ...

Ich finde eine derartige Einstellung einfach nur traurig.

MfG
der WK

Vielleicht will er eine Runde honeypot spielen?

Hallo!

Gab es da nicht früher mal eine einfache Regel, welche das "Troll-Problem" auf die schnellste Art erledigt hat:
"Das Füttern von Trollen ist verboten!!"
Und schon sterben sie von ganz alleine aus.

Ich wünsche euch allen einen guten Jahreswechsel und ein von Gesundheit erfülltes, friedvolles und meinetwegen auch trollarmes Jahr 2013!
Meine besonderen Güße gehen an graubaer und den Freund mit dem dicken Kugelbauch - PlatschQuatsch!

MfG der Wismutkumpel

Nun, das warum war ja bislang nicht die Frage ... .
Deshalb bin ich auch nicht darauf eingegangen. Angeregt von Cosmo will ich doch noch was dazu schreiben.
(Sorry, wenn es etwas länger wird!)

Ich sehe persönlich keinen allzu großen Unterschied im Design der beiden Passwortmanager.
Beide speichern die Kombinationen an Auth.-Daten in einer verschlüsselten Datei und sichern diese mit einem Schlüssel, welcher aus einem Passwort hergeleitet wird. Dass der PW-Manager von Mozilla zur Verschlüsselung der sqlite-Datei das schon etwas betagte 3DES verwendet, und KP modernere Verfahren wie Twofish oder AES verwendet, sehe ich (für unsere private Pillepalle-Anwendungen!) als völlig uninteressant an. Selbst das "gute alte" einfache DES wurde noch nie kryptografisch gebrochen und bei 3DES dürfte auch heute noch der zeitliche und finanzielle Aufwand für einen brute-force-Angriff jenseits des Sinnvollen liegen.

Abgesehen von dem erweiterten Funktionsumfang moderner PW-Manager wie dem KP (eigener PW-Generator, dem "Vergessen" der im RAM gespeicherten Auth-Daten nach einer einstellbaren Zeit, dem frei wählbarten Speicherort der verschlüsselten Containerdatei, der Nutzung für mehrere Anwendung, der Möglichkeit an Stelle eines schnöden PW auch eine Schlüsseldatei zu verwenden, usw.) sehe ich den Hauptunterschied aber woanders:
Jeder der ggw. so viel Unruhe stiftenden Passwortdiebe sucht gezielt nach einer Datei mit Namen "signons.sqlite", welche sich an einer exakt definierten Stelle im Fx- (und TB-) Profil des angemeldeten Nutzers befindet. Diese Schadprogramme haben also ein fest verdrahtetes Ziel und die genau definierte Aufgabe, diese Datei übers Netz an einen bestimmten Ort zu kopieren.
Also einfache schnöde Programmierarbeit ... . Man muss nur dafür sorgen, dass <user> sich auch diesen Schadcode installiert. Dass "nebenbei" auch noch ein Keylogger das Master-PW mitplottet ist ja wohl auch keine Kunst. Wenn ein Rechner einmal erfolgreich infiziert wurde ... .

Bei der Verwendung eines alternativen PW-Managers wie dem KP oder dem von mir als Linuxnutzer favorisierten Add-on "KDE Wallet password Integration" breche ich aus dieser fest verdrahteten Aufgabe des PW-Diebes aus. Ich kann meine Containerdatei quasi beliebig benennen und auch an jedem beliebigen Ort platzieren. Und wenn ich dann auch noch zum Öffnen dieser kein schnödes Passwort, sondern eine auf einem ext. Datenträger befindliche Schlüsseldatei verwende, kann ich der Sache recht gelassen entgegensehen. Und wenn ich bei meinen 4 geöffneten Foren die PW habe senden lassen, wird nach 2 Minuten der Container automatisch wieder geschlossen und die PW aus dem RAM gekehrt.

Andererseits hat eine im Programm integrierte PW-Verwaltung wieder den Vorteil einer nahtlosen Integration. Auch das sollte man nicht vergessen.

Ich möchte euch noch mit meiner pers. Meinung zur generellen Nutzung von PW-Managern langweilen.
Etwas weiter oben habe ich gelesen, dass jemand grundsätzlich keinen PW-Manager nutzt, und das PW immer "life" einhackt.
Nun ja, warum nicht ... .
Im Rahmen von Sicherheitsaudits und Awarenes-Trainings befrage ich manchmal die Leute nach ihren Gewohnheiten. Und wenn sie merken, dass das ganze anonym und "schadlos" für sie abläuft, bekomme ich auch wahre Antworten geliefert.

Privat wird fast überall das gleiche primitive und "lebenslang geltende" Passwort verwendet. Das ist eben so!

Nun schätzt bitte selber ein, was besser ist:
Ein oder wenige dauerhaft geltende Primitivpasswörter - oder einen PW-Manager beliebiger Art, der dann auch noch regelmäßig zumindest mit einem neuen Masterpasswort versehen wird?
Es will mir doch niemand weiß machen, dass er für jeden einzelnen Zugang (und für jedes Mailkonto im TB) ein halbjährlich gewechseltes 12-16 stelliges "kryptisches" Passwort verwendet und dieses auch aus dem Kopf einhackt.

MfG WK

Hallo PoooMukkel,

wenn ich dein Problem in die große Suchmaschine eingebe, dann sehe ich ...
... dass die Zahl derer, die diesen Wunsch haben "sehr begrenzt" ist.
Warum wohl?

Wieviel Hundert Passörter hast du denn in Keepass gespeichert?
Und du hast dir keine (per TrueCrypt oder meinetwegen Locknote gesichert gespeicherte) Datei angelegt, in welcher du deine Kombinationen aus Servername, Benutzername und Passwort eingetragen hast? (Unabhängig von jedem Passwortmanager!)

Wo ist dein Problem, immer dann, wenn du erstmals wieder eine bestimmte Seite aufrufst, schnell mal diese Daten in die Zwischenablage zu übernehmen und den Fx damit zu füttern und diese Daten dann auch dort zu speichern? Das dauert doch keine 10 Sekunden pro neuer Speicherung. Und wenn du den Haken nicht vergisst, ist das ja auch nur einmalig.

Ich empfehle dir sogar, immer wenn du ein neues Passwort benutzt, dieses zuerst in diese Datei zu schreiben, und erst danach von dort per Zwischenablage in das entsprechende Eingabefeld zu kopieren. Ich denke an das Geheule von mehr als genug Usern, die ihr Passwort "vergessen" haben.

Nachdenklich ...

MfG der WismutKumpel

Zitat

Es gibt keine singuläre Kryptographie. Ein Partner verschlüsselt und der andere Partner entschlüsselt. Beide Partner müssen sich aber vorher über den zu benutzenden Schlüssel verständigt haben.

Ich bin mir jetzt nicht ganz sicher, ob ich, wenn ich darauf antworte, unseren TE völlig überfahre.
Also "keinePeilung" mach dir nix draus, das ist ein Thema, wo viele Leute so ihre Probleme haben. Du musst das auch nicht unbedingt gleich alles verstehen, und es geht auch über das, was dich eigentlich interessiert, hinaus. Mal davon "gehört zu haben" schadet aber keinesfalls. Ich bemühe mich auch um eine "volkstümliche Erklärung".

Selbstverständlich trifft das, was .Hermes da geschrieben hat, zu.
Nur es gibt eben große Unterschiede, ob es sich um eine für den Nutzer völlig transparent ablaufende "stinknormale" ssl-Verbindung handelt, oder wie bei einer verschlüsselten E-Mail oder auch beidseitigen Authentifizierung zw. Browser und Server um eine Verbindung, welche auch auf dem Client eine entsprechendes asymmetrisches Schlüsselpaar erfordert.

Bei einer normalen ssl-Verbindung stößt der Server von sich aus einen gesicherten Schlüsselaustausch an und mit dem ausgetauschten symmetrischen Zufallsschlüssel wird dann die gesamte Verbindung verschlüsselt. Wie oben schon bemerkt, für den Nutzer völlig transparent und "unbemerkt". Durch den Schlüsselaustausch sind auf beiden Seiten "Schloss und Schlüssel" vorhanden. Die einzige Bedingung ist, dass der Client mit Hilfe der bei ihm hinterlegten Herausgeberzertifikate die Echtheit des Serverzertifikates überprüfen kann. Die Parter (Client und Server) haben sich über den anzuwendenden Schlüssel verständig, und der Nutzer sieht nur an der Anzeige in der Adresszeile, dass die Verbindung verschlüsselt ist. Und darauf sollte er aber auch bei kritischen Anwendungen (Banking) ein Augenmerk haben!
Damit dürften wohl 99% aller kryptologischen Anwendungen am privaten Browser abgedeckt sein. Ohne allzu große Anforderungen an den Nutzer.

Etwas anderes bzw. etwas weitergehendes ist es, wenn eine sichere Authentifizierung des Clients am Server gefordert bzw. erwünscht ist. Dazu werden dem Client ein eigenes asymmetrisches Schlüsselpaar (Zertifikat und privater Schlüssel) installiert und der öffentliche Schlüssel aller berechtigter Clients (die Zertifikate) müssen vor der ersten Verbindungsaufnahme ebenfalls auf dem Server installiert werden. Der Client meldet sich unter Zuhilfenahme seines privaten Schlüssels am Server an und dieser prüft mit Hilfe des dort hinterlegten Zertifikates die Berechtigung des Clients. Und dann erfolgt die normale ssl-Verschlüsselung. Hier ist aktives Handeln aller Beteiligten durch die Beschaffung und Installation der benötigten Schlüssel und Zertifikate gefragt. "Schloss und Schlüssel" werden also beidseits bewusst verteilt. Als "Belohnung" gehören dann aber die Anwendung von Benutzername und Passwort der Vergangenheit an. Sicherer als mit der gegenseitigen Authentifizierung durch asymm. Kryptologie geht es (zumindest gegenwärtig) nicht.
Und aus diesem Grund trifft dieses ja auch fast ausschließlich für eng gefasste Nutzerkreise (Firmen, Organisationen und ambitionierte private Nutzer) zu. Der normale private Nutzer wird damit kaum in Berührung kommen - es sei denn, dass wirklich mal der nPA für so etwas zur Anwendung kommt. Eigentlich war das ja mal so gewollt ... .

Fazit:
Was die kryptologischen Anwendungen mit dem Browser betrifft, muss sich der normale private User eigentlich recht wenig Gedanken machen. Hauptsache er achtet auf die angezeigte ssl-Verschlüsselung in der Adresszeile des Browsers, auf die Korrektheit der angezeigten Adresse und er klickt vor allem nicht ohne Nachzudenken auf die Bestätigung von Ausnahmeregeln. Bei den Servern bzw. den Zertifikaten seriöser Einrichtungen (Banken usw.) dürfte es eigentlich nicht passieren, dass deren Serverzertifikate ohne rechtzeitigen Ersatz ablaufen oder aus anderen Gründen ungültig werden. Zumindest sollte der Nutzer dann sehr aufmerksam sein.

Bei allem anderen, was die Sicherheits des Systems usw. angeht, da kann ich mich nur dem sehr guten Beitrag vom Docc anschließen!

MfG WK

Hallo KeinePeilung,

und willkommen im Forum!

vielleicht noch als kleine Ergänzung, was "FIPS" überhaupt bedeutet:
Wenn ein Kommunikationsprogramm oder auch -Gerät für die Übertragung von Informationen mit staatlicher Einstufung ab einem bestimmten Vertraulichkeitsgrad benutzt werden soll, dann muss diese Soft- oder Hardware durch eine staatliche Einrichtung vor deren Nutzung gründlich überprüft (evaluiert und für diesen Vertraulichkeitsgrad zugelassen) werden.

Bei uns in Deutschland macht dieses das Bundesamt für Sicherheit in der Informationstechnik (BSI). Ein derartiges Gerät besitzt dann also eine "BSI-Zulassung" bis VS-NfD oder meinetwegen GEHEIM. (Das trifft für die Mozilla-Programme nicht zu, denn es gibt dafür zum einen genügend andere zugelassene Soft- und Hardware, und eine Evaluierung ist sehr aufwändig und somit teuer! Auch müsste diese bei jeder neuen Version wiederholt oder zumindest ergänzt werden ... .)

In den USA "kümmert" sich eine dortige Behörde um die Zulassung für die Nutzung im behördlichen Umfeld. Und die dazu erforderlichen Regeln werden eben in den Federal Information Processing Standard (FIPS) genannten Standards beschrieben.

Aber wie der Docc schon völlig richtig sagte, ist FIPS weder ein Kryptoschlüssel noch für dich/uns als private Nutzer irgendwie relevant. Das standardmäßig aktivierte Kryptomodul im Fx und im TB reicht völlig aus.

MfG WK