Signierung mail mit PGP bzw. S/MIME

Am 24.09.2018, werden in der Zeit zwischen 21:00 Uhr und 09:00 Uhr des folgenden Tages Wartungsarbeiten am Server durchgeführt. Daher wird die Webseite in dieser Zeit nur eingeschränkt erreichbar sein.
  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version: 31.3
    * Betriebssystem + Version: WIN 7 64
    * Kontenart (POP / IMAP): IMAP
    * Postfachanbieter (z.B. GMX): Posteo.de
    * S/MIME oder PGP: PGP


    Hallo hilfreiches Forum,
    habe nun also erfolgreich Enigmail aktiviert und mit adele getestet.
    Der Empfänger/die Empfängerin einer signierten mail kann die Signatur aber nur mit meinem öffentlichen Schlüssel prüfen. In 99,9 % aller Fälle nutzt das nichts, da er/sie kein PGP hat. Oder könnte der angehängte öffentliche Schlüssel direkt (also ohne ihn zu importieren) zum Entschlüsseln der Signatur benutzt werden?
    Würde gerne allen Adressaten versichern, dass ich es selbst bin, der ihnen da schreibt. (Bei gmail wurde 2mal mein Konto gehackt und dann unter meinem Namen emails mit Virus versandt! U. a. bin ich deshalb von gmail weg zu posteo gegangen.)


    Kann es sein, dass beim Einsatz von S/MIME die Identität automatisch in Klarschrift angezeigt wird, da ein Zertifikat vorliegt?
    Wenn dem so ist, steige ich doch noch auf S/MIME um oder installiere es zusätzlich.


    Wenn ich die Informationen zu S/MIME im Netz richtig verstanden habe, wird mit der Signierung immer auch mein öffentlicher Schlüssel mitgeliefert und muss (oder kann) nicht zusätzlich an die mail gehangen werden.
    Bei PGP scheint dem nicht so zu sein, man muss also beides machen (?).


    Entschuldigt meine vielleicht dämlichen Fragen, aber nur wenn ich alle Implikationen zur Verschlüsselung voll kapiert habe, kann ich es meinem Freundeskreis erklären und vermitteln, dass es einfach sei und so wenigstens Einige verführen, es mir nachzutun.
    Ich bin da der Einäugige unter den Blinden.
    Also vielen Dank schon mal.

  • Hallo PGP-Thunder,


    und dann unter meinem Namen emails mit Virus versandt!


    Ja, dann ist eine digitale Signatur der richtige Schritt. Deine Mailpartner können dann von Dir stammende E-Mails auch als solche erkennen.


    In 99,9 % aller Fälle nutzt das nichts, da er/sie kein PGP hat.


    Ich dachte mir schon (siehe Nachtrag zu Deinem vorherigen Faden Public Key im Test mit adele), dass Du bei Deinen Mailpartnern auf Hindernisse stoßen würdest. Damit stehst Du nicht allein da.


    Kann es sein, dass beim Einsatz von S/MIME die Identität automatisch in Klarschrift angezeigt wird, da ein Zertifikat vorliegt?


    Du vermutest schon insofern richtig, dass Empfänger ohne GPG + Einigmail nichts mit Deinen Schlüsseln anfangen können. Bei S/MIME ist das etwas anders. Die Installation einer zusätzlichen Software ist hier nicht nötig, weil der zugehörige Code bereits im TB oder auch im Outlook integriert ist.


    Ganz ohne Mitwirkung der Mailpartner geht es aber auch bei S/MIME nicht. So wie bei GPG Dein öffentlicher Schlüssel importiert werden muss, benötigen die Empfänger im Falle von S/MIME Dein Zertifikat und ggf. das des Herausgebers (der Zertifizierungsstelle, CA). Beiden müssen sie das Vertrauen aussprechen.
    Wenn der Herausgeber dem TB nicht bereits bekannt ist, muss dessen Zertifikat einmalig von Hand importiert werden. Deines bekommen sie, wie Du schon vermutest hast, "automatisch" über Deine digitale Signatur. Das klingt jetzt vielleicht etwas kompliziert, ist aber erfahrungsgemäß für viele deutlich einfacher als GPG und Enigmail zu installieren, sich selbst Schlüssel zu erzeugen usw. .


    Wenn Du E-Mails nicht nur signieren sondern auch verschlüsseln möchtest, benötigen Deine Mailpartner auch ein eigenes Zertifikat.
    Solche Zertifikate gibt es von offiziellen Herausgebern in verschiedenen Klassen, kosten aber meistens etwas Geld. Ob es noch kostenlose Zertifikate gibt, weiß ich nicht. Dazu können vielleicht andere mehr sagen. Vielleicht kannst Du sogar eines von Posteo bekommen, als Teil Deines Kontos dort? Würde mich nicht wundern.


    Wenn es nur um einen kleinen Kreis von Dir bekannten Empfängern geht, kannst Du auch selbst als Herausgeber tätig werden und entsprechende Zertifikate für Dich und Deine Partner erzeugen. Das geht z.B. mit dem Programm xca, erfordert aber etwas Einlesen in die Thematik. Ich würde es mal so sagen: Für Deine Mailpartner wird es dann deutlich einfacher, für Dich allerdings etwas aufwendiger - aber nur beim ersten mal.


    Schau mal im TB unter Einstellungen -> Erweitert -> Tab Zertifikate -> Button Zertifikate. Dort kannst Du neben eigene und bereits importierten Zertifikaten unter Zertifizierungsstellen auch sehen, welche Herausgeber dem TB von Haus bekannt sind. Dort würde dann bei Deinen Mailpartnern auch Deine CA erscheinen.


    Peter Lehmann betreibt schon länger so eine Privat-CA und kann sicher mit Links zu Anleitungen oder mit Templates weiterhelfen. Aber Du kannst gern etwas mit xca experimentieren. So schlimm ist es nicht. Ich habe das vor ein paar Monaten ebenfalls gemacht und eine handvoll Zertifikate für den Familien- und Freundeskreis erstellt. Die Resonanz war die, dass es einfacher zu handhaben ist als GPG/Enigmail. (Und trotzdem versenden sie die meisten E-Mails nach wie vor unverschlüsselt.)


    Du solltest ebenfalls berücksichtigen, dass Deine Partner einen Mailclient wir den TB oder Outlook benötigen. Webclients können weder mit S/MIME noch mit GPG etwas anfangen. Für Smartphones gibt es entsprechende Apps.


    Bedenke auch, dass, im Gegensatz zu GPG, S/MIME verschlüsselte E-Mails nicht aus dem TB heraus unverschlüsselt gespeichert werden können. Das sehen manche als Vorteil andere als Nachteil an.


    Gruß


    Susanne

  • Hallo Susanne,

    Zitat

    Ob es noch kostenlose Zertifikate gibt, weiß ich nicht.


    Doch gibt es. Zu mindestens kenne ich eins.
    https://www.startssl.com/
    Ist ein Jahr gültig.
    Gruß

    Konversationen ohne vorherige Anforderung werden ignoriert..
    Windows 10, 64-bit, immer die aktuelle Thunderbird-Version und ältere Testversionen. Testprofile vorhanden.
    Testkonten bei den meisten größeren Mailanbietern wie GMX, Web.de usw

  • Hallo,
    mrb : man sollte sich gut informieren, welcher Firma man vertrauen möchte. Bei Wikipedia findet man etwas zu der israelischen Firma StartSSL.
    Bei Comodo (erwähnt in dem bei dir (graba) verlinkten Artikel , gab es ja bekanntlich ein größeres Sicherheitsproblem, womit die Firma für mich erledigt ist. Weitere Beispiele finden sich leicht...
    Ich hoffe eher auf Mozilla und die EFF.
    Grüße, muzel

  • Hallo muzel,


    Mozilla und die EFF zielen doch in erster Linie auf Serverzertifikate. Hast Du Informationen, ob die auch S/MIME-taugliche Zertifikate planen? Ich habe nicht den Eindruck, dass sie an E-Mail noch sonderlich interessiert seien.
    Solange sich die Anzahl der Mailpartner, die bereit sind E-Mails zu verschlüsseln, weiterhin in einem so kleinen Rahmen bewegt, ist mir persönlich der Weg über selbst erstellte Zertifikate bzw. Schlüssel der liebste.


    Gruß


    Susanne

  • Hallo Susanne! (Ich bin zwar nicht muzel ...)

    Ich habe in diesem neuen Projekt (wenn es denn mal produktiv sein wird ...) auch nichts von S/MIME gefunden.
    Überhaupt habe ich das Gefühl (und auch in meinem Beruf ist "Bauchgefühl" manchmal gar nicht so übel als Ratgeber!), dass sich "bei Mozilla" überhaupt niemand so richtig um die Sicherheit unserer E-Mails kümmern will. Weder die ehemals bezahlten Entwickler noch die der "Community" die sich nach Aussage diverser "Insider" wohl heute um die Weiterentwicklung kümmern sollen.
    Noch immer (wir schreiben bald 2015!) werden bei S/MIME SHA-1 und 3DES angewandt. Ich kann mich an Besprechungen im BSI (von vor 10 Jahren!) erinnern, wo vor SHA-1 gewarnt wurde. Und der TB ist ja wohl mittlerweise der letzte MUA, welcher noch mit 3DES verschlüsselt.
    Ob Mozilla vielleicht auch schon einen "Security Letter" bekommen hat? Wer weiß ... . Fakt ist aber, sie wollen es mit den zeitgemäßenAlgorithmen einfach nicht angehen.


    Ich habe seit dem offiziellen Sterbebeginn unseres geliebten (ja, so ist es!) Thunderbird seitens Mozilla das Programm KMail parallel mitzulaufen. Und bestimmte Mails, die ich nicht in der B***-******g lesen möchte, versende ich dann eben per KMail. Selbst mein "veraltetes" Schlau-Fernsprechgerät aus dem Jahre 2012 beherrscht SHA-512 und AES256.


    Zitat

    Solange sich die Anzahl der Mailpartner, die bereit sind E-Mails zu verschlüsseln, ...


    Es hat doch niemand etwas zu verbergen (oder vlt. doch?). Fazebook hat gute Arbeit geleistet.
    Ich weiß nur, dass die Anfragen an meine "Privat-CA" immer mehr werden. Und obwohl ich schon lange die Zertifizierung von durch die User selbst generierten Requests (.p10) anbiete, will das kaum jemand. Volles Vertrauen oder weils eben mit der "Vollversorgung" viel einfacher ist? Ich weiß es nicht.


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • OK, ich habe die Kritik von Muzel verstanden (startssl.com).
    Wäre es folglich sinnvoller tatsächlich sich die Zertifikate selbst zu machen etwa- wie von Susanne vorgeschlagen - mit xca?
    Irgendwo müsste eigentlich dort auch ein Haken sein.


    Gruß

    Konversationen ohne vorherige Anforderung werden ignoriert..
    Windows 10, 64-bit, immer die aktuelle Thunderbird-Version und ältere Testversionen. Testprofile vorhanden.
    Testkonten bei den meisten größeren Mailanbietern wie GMX, Web.de usw

  • Hi mrb,


    ich produziere schon seit fast 15 Jahren jährlich einige Hundert Zertifikate mit den bekannten Tools. Zuerst (nur für mich, meine Familie und wenige gute Freunde) auf der Konsole per openSSL. Dann habe ich TinyCA "entdeckt" - und ein Weilchen damit gearbeitet. Aber seit ich XCA kenne, gibt es für mich nichts anderes mehr!
    Der Vorteil bei XCA ist (für Leute, die das semiprofessionell betreiben, für "Einzelstücke" lohnt sich das kaum) die Möglichkeit, Vorlagen für die einzelnen Anwendungsbereiche (CA, diverse Servertypen, S/MIME, IPsec usw.) zu erarbeiten und dann durch Auswahl des entsprechenden Templates immer die richtigen Einstellungen zu haben. Und XCA ist natürlich auch gleichzeitig ein Archivsystem für die erzeugten Zertifikate.


    Was das alles betrifft, so gibt es kaum noch einen großen Unterschied zum Ablauf in einem richtigen TrustCenter.


    Aber eben nur fast:
    Der Unterschied zwischen "auf einem normalen PC" erzeugten Schlüsseln und denen, die ein zertifiziertes (akkreditiertes) TrustCenter herstellt, ist der verwendete Zufallszahlengenerator! Kein PC ist in der Lage, echte Zufallszahlen herzustellen. Es sind immer nur Pseudo-Zufallszahlen. Auf einem Rechner gibt es keine Zufälle. Egal, ob eine WinDOSe oder Linux mit dem aktuellen 3.18er Kernel (obwohl dort große Verbesserungen drin sind!), egal ob Schlüssel für S/MIME, GnuPG oder SSH - es wird immer der gleiche Pseudo-Zufall produziert. Und das lässt schon die Herzen der Fachleute bestimmter Organisationen höher schlagen ... .
    In einem akkreditierten TrustCenter werden (wenn der Antragsteller nicht gerade mit selbst erzeugten Requests ankommt, er also den Schlüssel auf seiner WinDOSe selbst generiert hat ...) so genannte Hardware-Sicherheitsmodule (HSM) verwendet. Extrem teuer und auch sehr empfindlich (gegenüber jeder Art von Manipulation von Stromausfall über Licht bis hin zu Druckunterschieden). Aber dort werden die Zufälle durch Hardwarekomponenten wie "Rauschdioden" (abhängig von der Dotierung des Kristalls, Temperatur, natürlicher radioaktiver Strahlung usw.) und einiges anderes mehr und noch verschlimmbessert durch verschiedene schlaue Verfahren hergestellt. DAS sind schon richtig gute Zufälle und nicht mehr vorauszusagen, wie die vom PC.
    Ich behelfe mir, indem ich eine der besseren Kryptochipkarten welche mit einem richtigen Microprozessor ausgerüstet sind, im Dauerbetrieb laufen lasse und gegen /dev/urandom verlinke. Auch dort kommt eine echte Harwarekomponente als Rauschquelle zum Einsatz. Selbstverständlich nicht ganz so "wertig" wie in einem HSM - aber wesentlich besser als auf einem PC mit "amerikanischen" oder "chinesischen" Komponenten.



    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Hallo Peter,
    ganz pessimistisch gesehen, könnte man es also eigentlich aufgeben, wirklich sicher verschlüsselte Nachrichten auszutauschen, außer mittels Geheimtinte und Brieftauben
    Der Normal-User hat chinesische Hardware, die verwanzt sein kann, ein Windows oder Apple-OS, das es vermutlich ist, oder auch ein Linux, bei dem die Sicherheitslücken theoretisch schnell gefunden werden, praktisch aber jahrelang vor sich hin gammeln.
    Man bräuchte Open Hardware und Open Source, auch für offensichtlich nötige Krypto-Hardware.
    Damit sind alle Normalanwender aus dem Rennen, und auch Pseudoexperten wie du und ich werden den Aufwand nicht betreiben. Der Trend geht ja auch eher zu den allgegenwärtigen Mobiltelefonen und Tablets, wo jede Eingabe vermutlich in Echtzeit bei G00gle & Co. und parallel dazu bei den "Diensten" landet, und wo sowohl die Installation von Verschlüsselungs-Software als auch die Eingabe von sicheren Passwörtern extrem unkomfortabel sind.
    Susanne : ich hab den Artikel wohl zu schnell überflogen, von S/Mime war nicht die Rede... Ich war einfach der Meinung, ein Trustcenter könnte alle Sorten von Zertifikaten ausstellen.
    Gruß, muzel

  • Hallo,


    Noch immer (wir schreiben bald 2015!) werden bei S/MIME SHA-1 und 3DES angewandt.


    Zu diesem Punkt scheint sich etwas zu tun. David Cooper hat in bug 1018259 "Thunderbird should stop using SHA-1 when signing email messages" einen Fix gebaut. Ziel ist TB 36. Ironischerweise gibt es noch Diskussionen, weil Outlook unter xp nicht mit SHA-2 klarkommt.


    Irgendwo müsste eigentlich dort auch ein Haken sein.


    Ich sehe darin für mich keinen Haken. Natürlich ist ein solches Modell nicht für den großen Maßstab gedacht. Man würde sonst wie bei GPG wohl zu einer Art web of trust übergehen müssen. Für mich überwiegen die Vorteile: keine Kosten und völlige Kontrolle über die eigenen Zertifikate, wie bei GPG.

    Die nicht wirklichen zufälligen Zufallszahlen stören mich auch weniger. GPG ist diesbezüglich etwas besser aufgestellt, denn es verlangt beim Generieren der Schlüssel einen menschlichen Zufallsgenerator (Mausbewegungen). Das erschwert einen mathematischen Angriff, schützt aber natürlich nicht, wenn Hard- oder Softwareware bereits ab Werk eine Backdoor haben sollten.


    Soweit es mein Privatleben betrifft, geht es mir vor allem um den Schutz vor Betrügern und kommerziellen Datenschnüfflern, weniger um die fast allmächtigen staatlichen Dienste.
    Diese "Marktforscher" verdienen viele Milliarden und können bereits Metadaten über uns auswerten, dass einem ganz übel wird. Die müssen nicht auch noch die Inhalte zum Lesen bekommen.

    Wie viele regelmäßige Mailpartner mag der durchschnittliche Deutsche privat haben? Vielleicht so um die 20? Wenn von denen wiederum jeder nur 10 zusätzliche Mailpartner hat wächst die Zahl der insgesamt nötigen Zertifikate zwar exponentiell an. Für den einzelnen würde es aber lediglich bedeuten, dass er im Schnitt mit etwa 20 importierten Zertifikaten aus seinem Freundeskreis klar käme. Das wäre für den Benutzer ein Aufwand von wenigen Minuten und auch für den Betreiber der privaten CA gut zu handhaben. Nur leider schert es kaum jemanden.

    Also ihr lieben Mitleser dort draußen, ihr kennt ja das Sprichwort: Steter Tropfen ... .


    Wenn jeder von euch, der sich zutraut für seinen Freundeskreis Zertifikate zu erstellen, nur ein paar Mitspieler gewinnt, wäre schon viel gewonnen. Selbst, wenn die Zertifikate am Ende nur zum Signieren benutzt werden, so wäre zumindest ein weiterer Schritt im Kampf gegen Viren und Co. getan.
    Für die Benutzer ist die Installation eurer Zertifikates sehr einfach. Und da ja angeblich jeder ein jeden über nur ein paar Ecken kennt, würden am Ende auch meine lieben Leut plötzlich nicht nur von mir auf dieses Thema angesprochen werden und die euren nicht nur euch.


    Gruß


    Susanne

  • Hi muzel,


    nun, jede Flüssigkeit, die nicht aus reinstem Wasser besteht, zeigt bestimmte Effekte unter UV-Licht (vielleicht sogar Spuren reinstes Wasser selbst). Und selbst das temporäre Aufquellen des Papiers ist heutzutage mikroskopisch an den Strukturveränderungen feststellbar. Fällt also aus. Und da auch bei uns schnöde Briefe in den Verteilzentren automatisch gescannt und sowohl der Absender als auch der Adressat gespeichert werden (angeblich aus "innerbetrieblichen Gründen", aber gibt es eine Verfolgung oder gar Zustellgarantie für Briefe? Also ist das für mich eine reine Vorratsdatenspeicherung!) fällt wohl auch der Brief als Mittel für vertrauliche Kommunikation aus. Ich gehe sogar davon aus, dass "man" mittlerweile in der Lage sein dürfte nach der Art eines CT ein "Schichtröntgen" der Snailmail durchzuführen. Dass die einzelnen Ämter, zumindest bis auf Landesebene, moderne Geräte zum kaum nachweisbaren Öffnen unserer Briefe besitzen, wurde schon vorlanger Zeit bestätigt (irgend eine Anfrage im Bundestag).
    Auch was die Verschlüsselung unserer (unwichtigen!) E-Mails betrifft, gebe ich dir vollkommen Recht. Selbstverständlich gilt immer noch die uralte Regel, dass (außer beim Onetimepad) jede Verschlüsselung zumindest durch BrutForce gebrochen werden kann. Ist halt alles eine Frage der Zeit. Und des Aufwandes, und damit des Geldes. Nun letzteres scheint es ja bei den Diensten (außer natürlich den "unsrigen" ...) ohne Ende zu geben.


    Trotzdem: wer aufgibt, hat schon verloren!
    Ich gehe mal davon aus, dass auch die weltweit tätige Gemeinschaft der "Berufsneugierigen" immer noch Prioritäten setzen muss. Es ist einfach (noch) nicht möglich, sämtliche verschlüsselte Kommunikation gleichzeitig zu entschlüsseln. Selbstverständlich, indem "man" der Welt korrumpierte Technik wie beispielsweise die Router einer bekannten Firma unterjubelt oder "hochsichere Verschlüsselungstools" mit - kleinen unaufflligen Hintertürchen usw., kann man dieses Ziel schon irgendwann erreichen.
    Unsere einzige Chance zum einigermaßen zuverlässigen Schutz unserer Privatsphäre besteht darin, eben so viel kryptologischen Müll zu erzeugen (damit meine ich wirklich unsere verschlüsselten privaten E-Mails mit dem typischen uninteressanten Inhalt!), dass dieses System der Massenüberwachung einfach an sich selbst erstickt.
    (BTW: Ich habe von 1970 bis 1990 in einer "Firma" gearbeitet, in der es Vorschrift war, 80% aller Fernschreiben über die - in DD hergestellten - Kryptogeräte zu verschicken. Damit war schon klar, dass es auch sämtliche Wettermeldungen, und sonstiger unwichtiger Kram war. Und in der "Kryptologischen Dunstglocke" gingen dann die wenigen eingestuften Meldungen unter. (Heutzutage darf ich ja darüber schreiben. "Damals" hätte mich zwar wegen dieser Informationen nicht gehängt, aber bestimmt einige Monate an einen Ort gebracht, von welchem aus ich einen prima Blick zum Petrolchemischen Kombinat gehabt hätte.)
    Genau so sollten wir jetzt auch verfahren! Also keinesfalls aufgeben.
    Allerdings lese ich aus vielen aktuellen politischen "Bemerkungen" heraus, dass "man" daran arbeitet, Gesetze auszudenken, welche uns das private Verschlüsseln verbieten. Es sieht so aus, dass "das Wahlvolk" in dieser Hinsicht weichgeklopft werden soll. Oder Verschlüsseln ja - aber nur mit Schlüsseln vom Staat. (Das sind ja die guten ... .)


    Zitat

    Ich war einfach der Meinung, ein Trustcenter könnte alle Sorten von Zertifikaten ausstellen.


    Selbstverständlich ist das so! KÖNNEN schon ... .
    Ein ganz normales X.509-Zertifikat kann einfach alles. Es kann selbst andere Zertifikate signieren (also CA sein!), und es kann für jeden Verwendungszweck eingesetzt werden, so lange der Servername oder eben die Mailadresse in den Zertifikatsdaten eingetragen sind. ABER:
    Die in einem TrustCenter erzeugten Zertifikate werden ganz bewusst mit Einschränkungen versehen. Da wird eben festgelegt, dass es sich "nur" um ein Endnutzerzertifikat und nicht um ein CA-Z. handelt. Es wird festgelegt, dass es sich zum Signieren und/oder zum Ver-/Entschlüsseln usw. eignen soll. Und das ist auch gut so!


    So, genug geschwätzt!


    Ich möchte mich an dieser Stelle noch "in aller Form" bei PGP-Thunder entschuldigen, weil wir hier seinen Thread einfach so gekapert haben! Das macht man doch nicht - noch dazu als jemand, der als Mod das eigentlich wissen müsste. Ich hoffe mal, PGP-Thunder, dass die Informationen vielleicht sogar für dich etwas interessant waren und du uns deswegen verzeihst.



    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Hallo und schönes neues Jahr!
    Als absoluter Neuling in diesem Forum und in diesem Thema sauge ich alles auf, was meiner Ahnungslosigkeit abhilft und wenn mein ursprünglicher thread mal "gekapert" wird, tut mir das nicht weh.


    Habe nun also ein email-Zertifikat beim Sparkassenverlag (S-Trust) für rund 35 EURO (2 Jahre) gekauft, für viel Geld also, aber mir ist es nicht egal, wer es ausstellt.
    Warum sollte ein Unternehmen so etwas kostenlos abgeben? Macht mich gleich misstrauisch. Die Geiz-ist-geil-Mentalität, wie sie insbesondere im Netz waltet, ist mir zuwider.
    Für Qualität und Sicherheit bin ich bereit zu zahlen, und zwar mit Euro und nicht mit meinen Daten.
    Natürlich gibt es auch viel Altruismus im Netz, z.B. Wikipedia, und das ist gut so. Die kriegen auch jedes Jahr eine Spende von mir.


    Bin nun unsicher bei der Installation des Zertifikats.
    Mein browser (Firefox) hat bei der Übernahme des Zertifikats verhindert, dass cross site scripting zum Zuge kommt (ist bei mir so eingestellt). Das Zertifikat ist allerdings trotzdem da, habe es auch gesichert und dabei ein Backup-Passwort vergeben.
    Wenn ich mir es im Zertifikate-Manager ansehe, kommt der Warnhinweis: "Dieses Zertifikat konnte nicht verifiziert werden, da der Aussteller unbekannt ist".
    Unter dem Reiter "Zertifizierungsstelle" ist der Sparkassenverlag aber aufgeführt und der button "importieren" hervorgehoben. War mir aber unsicher, ob ich etwas importieren soll, was schon da ist.
    Kann es sein, dass dieses Verifizieren über cross site scripting passiert wäre und nun nicht ist. Kann ich das nachholen?


    Danke für Eure Hilfe
    PGP-Thunder

  • Hallo PGP-Thunder,


    hast Du dem Herausgegeberzertifikat das Vertrauen ausgesprochen? Falls noch nicht, hole das zunächst nach und teste nochmals.


    Mein browser (Firefox) hat bei der Übernahme des Zertifikats verhindert, dass cross site scripting zum Zuge kommt (ist bei mir so eingestellt).


    Die Fehlermeldung kommt mir etwas merkwürdig vor. Ich kann jetzt aber nicht sagen, ob dieses Blockieren möglicherweise dazu haben könnte, dass das Zertifikat nicht ordentlich erstellt wurde. Ich habe das Sicherheitsmodul des Firefox schon seit Jahren nicht mehr zur Erzeugung von Zertifikaten benutzt. Damals hatte ich ein kostenloses Zertifikate von Thawte. Später habe ich GPG benutzt und inzwischen erstelle ich mir die Zertifikate mit xca selbst. Das geht dann komplett ohne Firefox.


    Wo und wie hast Du Einstellungen zum Verhindern von XSS vorgenommen? Im Firefox selbst kenne ich dazu keine Einstellung, die über in der Bedienoberfläche zu erreichen wäre. Verwendest Du eine Erweiterung wie NoScript?
    Meines Wissens hat der FF standardmäßig eine Funktion integriert, die das Ausführen von Code verhindert, der von einer anderen als der aufgerufenen Domain kommt. Das kann XSS zwar nicht komplett verhindern (XSS betrifft zunächst eh den Webserver und nicht den Client), aber es schützt den Client, falls der Webserver von XSS betroffen ist und die bösen Scripte von einer anderen Domain nachgeladen werden sollen. Diese Sicherheitsfunktion lässt sich aber soweit ich weiß nicht so ohne weiteres abschalten. Ich nehme daher an, Du meinst etwas anderes?


    Gruß


    Susanne