Posts by wurstsemmel

  • Thunderbird/Enigmail Nutzer zum Testen gesucht

    Hallo,


    ich suche jemanden mit einem korrekt konfiguriertem Thunderbird mit Enigmail um die gpg Interoperabilität zu Evolution zu testen. Meiner Erfahrung nach funktioniert das senden von signierten _und_ verschlüsselten eMails von Evolution zu Thunderbird bzw. andersherum nicht korrekt. Die Signatur wird nicht angezeigt, wobei die Verschlüsselung funktioniert.
    Einen Bugreport habe ich unter https://bugs.launchpad.net/bugs/319411 bereits geschrieben. Allerdings bräuchte ich dringend jemanden zum testen.


    Dazu müssten wir nur ein paar eMails austauschen, bitte frag per PM nach meiner eMail Adresse.


    Vielen Dank,


    wurstsemmel

  • [erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

    So nun ist wohl alles erledigt, ich zitiere kurz Nick aus der Newsgroup mozilla.dev.tech.crypto:


    Die Jungs aus der Newsgroup waren sehr hilfsbereit und schnell!


    Ich weiß nicht, wann dieser Bugfix in das nächste Tb Release eingeht. Das kann glaub ich dauern, aber ich kenn mich nicht aus.


    Viele Grüße,


    wurstsemmel

  • [erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

    So jetzt bin ich wieder da und bedanke mich für Eure wünsche. Hat geholfen, Studium ist in der Tasche!


    M_Hoeller und ich konnten bei einem wiederholten Test bestätigen, dass Tb wieder RC2 benutzt, wenn man auf eine eMail von KMail antwortet. Bei der ersten Mail mit manuell importiertem Z. wird von Tb 3DES verwendet.


    Daher liegt es nahe, dass Tb die Smimecapabilities ausliest und aktualisiert, wenn man auf Antworten drückt.


    Ich werden den Fall nun im englischen Forum fortführen, wer Lust hat kann ja mal vorbeischauen.


    Schönen Gruß,


    wurstsemmel

  • [erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

    Also,


    ich erzähl mal noch kurz die Geschichte von meinem Microsoft Outlook Express (MS OE) Test. Ich habe OE nur zum testen verwendet, da es standardmäßig installiert ist. Dies hat also nix mit dem vorher gesagten zu MS OE zu tun, OE beherrscht 3DES.


    OE zeigt unter "Einstellungen des Absenders | Empfohlener Verschlüsselungsalgorithmus" den empfohlenen Algorithmus an.


    Also die Ergebnisse:


    Tb -> OE: In OE wird 3DES als empfohlener Algorithmus angezeigt.
    OE -> Tb: Tb kann die Mail lesen, OE warnt nicht, dass die Verschlüsselungsstärke zu gering ist. Daher tippe ich auf 3DES.
    KMail -> OE: In OE wird *0.1.101.3.4.1.2 als empfohlener Algorithmus angezeigt. Da das Feld zu klein ist, kann ich die Zahl nicht komplett lesen, daher auch das *. M_hoeller könnte überprüfen, was diese Nummer bedeutet, in dem er sich selbst eine verschlüsselte email schickt und asn1dump ausführt. Ich denke, dass es sich um AES handelt.
    OE -> KMail: Die Nachricht wird mit RC2 verschlüsselt. Dies konnte M_hoeller bestätigen, außerdem zeigt OE eine Warnung wegen zu geringer Schlüsselstärke an.


    Meine Vorschläge wären also:


    a) in Tb sollte RC2 ausgeschaltet werden, wenn dies nicht zu Kompatibilitätsproblemen führt.
    b) Tb sollte einen Fallback auf 3DES machen, wenn es den Algo nicht kennt. In diesem Fall erkennt Tb den Algo (AES) nicht und fällt auf RC2 zurück
    c) KMail sollte eine Präferenzliste mitschicken, falls so etwas möglich ist. Nach dem Motto: Nimm AES, wenn du es nicht kannst, nimm 3DES!
    d) zur Not könnte man KMail auf 3DES umstellen, weiß allerdings nicht wie das geht. Außerdem wäre dann der Vorteil von AES Verschlüsselung zwischen KMail Usern weg.


    Wegen a) und b) werde ich am Mittwoch in die News-Group von Mozilla posten. Wenn dies jemand anders tun will oder schon getan hat, möge er sich doch bitte kurz melden.


    @ Peter_Lehmann: Soweit ich weiß benutzt, KMail gpgsm für die Verschlüsselung.


    Meine Aussagen decken sich mit denen von M_hoeller und Peter_Lehmann. Allerdings widerspricht Werner aus der gpgsm-devel-list:


    Quote from "Werner"


    > ==> Is it possible that KMAIL/gpgsm sends or stores some information
    > in the mail which leads to the fact that Thunderbird sends RC2 ????


    Definitely not.


    Achso, ich habe mal FIPS aktiviert in Tb, dadurch konnte ich Tb aber auch nicht dazu bewegen, AES zu benutzen.


    Ich wünsche Euch einen wunderschönen Tag,


    wurstsemmel



    P.S.: Danke an Peter_Lehmann für das aufwändige Testen.

  • [erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

    Guten Tag,


    leider schaffe ich es immer noch nicht, die envelopedData auszulesen. Bei der Methode von Peter_Lehmann erhalte ich die Meldung "offset too large", bei der von mhoeller kommt ein "invalid data at position xx". Leider kenne ich mich dazu unter Linux zu schlecht aus. Aber Peter_Lehmann hat ja schon klargestellt, dass Tb nicht immer RC2 verwendet.


    Vielleicht kann ja jemand das Problem und die Vermutung von mhoeller in der Newsgroup von Mozilla (siehe http://www.mozilla.org/projects/security/pki/nss/smime/) schildern. Newsserver news.mozilla.org.
    Ich habe leider im Moment zu wenig Zeit und nicht das nötige Wissen... Mit Peter_Lehmann testen wir noch, ob das Problem mit seinem Tb, der ja normalerweise mit 3DES verschlüsselt, auch auftritt.


    Viele Grüße,


    wurstsemmel

  • [erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

    Hallo zusammen,


    das gleiche Problem tritt bei uns auch auf.


    Folgende Dinge habe ich herausgefunden:

    • TB benutzt 3DES und RC2/40, siehe http://www.mozilla.org/projects/security/pki/nss/smime/ (Feature List Punkt 11). Danke an Peter_Lehmann.
    • S/MIME (allgemein) benutzt für die symmetrische Verschlüsselung 3DES, AES oder RC2/40; der Sender liefert eine Präferenz-Liste der Algorithmen mit, sonst wir 3DES verwendet (?) siehe pdf von Jeschke, Seite 17
    • KMail bzw. gpgsm sollte in der Signatur den symmetrischen Schlüssel auf 3DES festlegen, eventuell geschieht dies nicht, wie in diesem Thread bei Eudora festgestellt.
    • Das Problem tritt mit gpgsm und _einigen_ (nicht allen?) Thunderbird und Outlook 11 MUAs auf (Claws Mail FAQ / S/MIME HowTo)
    • Das Problem tritt mit MS OE und Thawte auf (a-netz.de)
    • und nochmal: Im Zusammenhang mit Thawte Zertifikat und Thunderbird tritt der Fehler auch auf. RC2/40 ist ein schwacher Algorithmus. KDE mailing list
    • gpgsm unterstützt RC2 nicht (zugehöriger bug report)
    • Laut pdf Grundpraktikum wird der verwendete Algorithmus in dem Bereich envelopedData unter Encryption Algorithm angezeigt.


    Die envelopedData ist, wie weiter oben erwähnt BASE64 kodiert. Zum dekodieren bietet sich www.opinionatedgeek.com an.


    Leider krieg ich es nicht hin, die EnvelopedData von meinen Mails auszulesen.* Wäre interessant, welche Verschlüsselung TB benutzt, wenn man sich selbst eine verschlüsselte Mail schickt. TB sollte 3DES verwenden, wie Peter_Lehmann weiter oben festgestellt hat. Nun könnte man die EnvelopedData von einer KMail eMail anschauen und vergleichen. Eventuell kommt man so auch an die bei mir als ersten Punkt erwähnte Präferenz-Liste.


    Meine Vermutung ist, dass KMail nicht nach 3DES verlangt und TB daher RC2 verwendet. Vielleicht könnte dies getestet werden, indem man TB das Zertifikat nicht automatisch hinzufügen lässt, sondern das öffentliche Zertifikat des KMail Nutzers in TB direkt importiert. Eventuell benutzt TB dann standardmäßig 3DES, da es keine eventuell fehlerhafte Signatur von KMail kennt??


    Ist es möglich, dass der Verschlüsselungsalgorithmus im Zertifikat festgelegt wird? Konnte dazu nix finden, war nur so eine Idee.


    Ich selbst benutze Thunderbird 2.0 RC1 (localized build de, kein language pack). KMail läuft mit gpgsm unter OpenSuse 10.2.


    Vielleicht kommen wir ja weiter, wenn jemand die envelopedData auslesen kann.


    Ciao,


    wurstsemmel


    * Ich habe mir unter Ansicht -> Nachrichten-Quelltext den Quelltext angesehen und den unleserlichen Teil unter dem Header in das Webformular kopiert.

  • TB 2.0.0.0 RC1, JavaScript, Junkfilter, Grafiken laden

    Also, in Bug 108153 ist erklärt, warum "img(alt,title,longdesc,src)" auch in Junkmail bzw. vereinfachtes HTML erlaubt ist.


    Abschließend können meine Fragen so beantwortet werden (natürlich ohne Gewähr!):


    zu a. Junkmail wird als vereinfachtes HTML dargestellt (sanitized)
    zu b. JavaScript scheint deaktiviert zu sein
    zu c. Das Laden von externen Grafiken wird für jede email Adresse getrennt eingestellt.


    Schönen Feiertag,


    wurstsemmel

  • TB 2.0.0.0 RC1, JavaScript, Junkfilter, Grafiken laden

    Die standardmäßige Aktivierung von JavaScript wäre aber ein echtes Sicherheitsproblem.
    Wenn ich mir den Schlüssel javascript.allow.mailnews = false ansehe, scheint mir JavaScript per default in Mail und News ausgeschaltet zu sein. Eine Testmail von heise zeigt auch, dass JavaScript aus ist.


    Ich habe noch eine Anregung:
    Durch ein Entfernen von "img(alt,title,longdesc,src)" aus dem Wert für den Schlüssel "mailnews.display.html_sanitizer.allowed_tags" könnte ein Anzeigen von eingebetteten Grafiken in Junk Nachrichten verhindert werden. Dies wäre ein zusätzlicher Sicherheitsgewinn.
    Bin am Überlegen, ob ich dies im engl. Theadback Thread zum RC1 posten soll?


    Zu a: Habe einfach ein bisschen rumprobiert: TB benutzt für Junkmails "Vereinfachtes HTML", dies entspricht der Option Ansicht -> Nachrichtentext -> vereinfachtes HTML. Die Einstellungen für "vereinfachtes HTML" werden in dem oben genannten Schlüssel festgelegt!


    MFG,


    wurstsemmel

  • TB 2.0.0.0 RC1, JavaScript, Junkfilter, Grafiken laden

    Hallo und einen schönen Ostersonntag!


    Ich habe TB 2.0.0.0 RC1 installiert und vermisse folgende Einstellungen aus 1.5.0.x:

    1. Beim Anzeigen von HTML-Nachrichten, die als Junk eingestuft sind, den HTML-Code ignorieren (bei 1.5 unter Extras -> Junk-Filter Einstellungen)
    2. JavaScript in Nachrichten blockieren (bei 1.5 unter Extras -> Einstellungen -> Datenschutz -> Allgemein)
    3. Das Laden von externen Grafiken in Nachrichten blockieren (bei 1.5 unter Extras -> Einstellungen -> Datenschutz -> Allgemein)


    Wo sind diese Optionen in der neuen Version? Nur noch in about:config? Welche ist die Default Einstellung bei 2.0?
    Würde mich über eine Antwort sehr freuen, vielleicht weiß ja jemand Bescheid!


    Viele Grüße,


    wurstsemmel


    edit: zu c. habe ich eine Antwort im englischen Forum gefunden: TB blockiert by default das Laden von externen Bildern, man kann im Adressbuch das Laden von Bildern für einzelne Adressen erlauben.

  • SSL Zertifikat

    Hi Vic~, der Link war nur als "Beweis" für die CRAM MD5 Authentifizierung gedacht. Es gibt ja noch andere Methoden für die Authentifizierung... und wenn man mit der Liste (auf die ich verlinkt habe) was anfangen will, muss man das wissen.


    an alle: Bitte beachtet den Beitrag von Peter_Lehmann 31.03.07 20:36 weiter oben!


    MFG,


    wurstsemmel

  • [erledigt] S/MIME mit Thawte und Fragen zu CRL und OCSP

    Hallo Peter,


    damit ist dann alles geklärt.
    Den Link zur SigV brauche ich nicht, mir geht es nur um die Verschlüsselung im privaten Bereich. Mein Thread war eigentlich auf die Einstellungen in TB bezogen, habe mich wohl leider etwas missverständlich ausgedrückt.


    Schönen Sonntag und nochmal vielen Dank!


    wurstsemmel

  • [erledigt] S/MIME mit Thawte und Fragen zu CRL und OCSP

    Hi Peter,


    komme aus Bayern, da sagt man auch Semmel...


    Danke für Deine Ausführungen. Dass Du Dir soviel Zeit neben dem Brötchen verdienen nehmen kannst! Respekt.


    Leider muss ich aber sagen, dass Deine Antwort nicht 100% meine Frage beantwortet. Das mit den Zertifikaten und den Unterschieden in der Generierung (für verschiedene Zwecke) war mir aus Deinem letzten Posting und meinen Recherchen unter OE schon klar.


    Vielleicht habe ich auch meine Frage missverständlich gestellt oder Deine Antwort falsch verstanden.


    Also ich bin davon ausgegangen, dass die zu einem persönlichen Zertifkat gehörende Zertifizierungsstelle zwingend zur Identifizierung von Mail-Benutzern zugelassen sein muss. Da ich den Haken aber nicht gesetzt habe, verstehe ich nicht warum meine Signatur trotzdem als gültig erkannt wird. Mach Dir keine Arbeit mit der Antwort.

    1. Dem Zertifikat wird vertraut, weil dem übergeordneten Zertifikat vertraut wird oder
    2. meinem persönlichen Zertifikat wird vertraut, weil im Zertifikat steht, dass es zur Identifizierung von Mail-Benutzern zugelassen ist (wäre aber irgendwie sehr unsicher)
    3. ich muss nochmal drüber nachdenken (ich=wurstsemmel ;-))


    Als Antwort einfach einen der 3 Buchstaben angeben.


    Danke.

  • SSL Zertifikat

    Wenn es jemandem hilft:


    GMX bietet SSL für POP3 und TLS/SSL für SMTP an. Steht so auch irgendwo auf deren Homepage.
    Ich habe SSL für POP3 und TLS für SMTP eingestellt. Zusätzlich habe ich "Sichere Authentifizierung" angeklickt, was aber keinen Sicherheitsgewinn darstellt, da das Passwort bei SSL/TLS sowieso verschlüsselt wird.


    MFG,


    wurstsemmel

  • [erledigt] S/MIME mit Thawte und Fragen zu CRL und OCSP

    Danke für die schnelle und ausführliche Antwort!


    Die Checkbox vor "Dieses Zertifikat kann Mail-Benutzer identifizieren" ist bei der Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" nicht gesetzt. Habe ich Dich nun richtig verstanden, dass TB diesem Zertifikat trotzdem vertraut, da der Vertrauensstatus von dem übergeordneten Zertifikat ("Thawte Personal Freemail CA") auf "Dieses Zertifikat kann Mail-Benutzer identifizieren" gesetzt ist?


    Übrigens scheinen den Obulus wohl zwei große Browserhersteller gerne zu nehmen... Von Opera weiß ich es nicht.


    Noch kurz zu OCSP:
    Wird im FF auch ohne aktiviertes OCSP jedes fortgeschrittene oder qualifizierte Zertifikat (z. B. von eBay, meiner Bank etc...) jedesmal überprüft? Oder anders formuliert: Ist der FF eine zugelassene Anwendung, die das Zertifikat überprüft, bevor es verwendet wird?


    Vielen Dank nochmal für die Erwähnung der rechtlichen Gegebenheiten. Das mit dem Vertrauen war nicht auf die "kostnix" Zertifikate im Allgemeinen, sondern auf die Einstellungen im TB bezogen.


    Viele Grüße,


    wurstsemmel

  • [erledigt] S/MIME mit Thawte und Fragen zu CRL und OCSP

    Hallo,


    und einen schönen Gruß in dieses tolle Forum!


    Ich habe mir bei http://www.thawte.com ein "Free Personal E-mail Certificate" geholt. Import in TB war problemlos, signieren und verschlüsseln an mich selbst funktioniert. Auch das Senden von signierten E-mails (nicht verschlüsselt) an andere Personen ist kein Problem.


    Folgende Fragen habe ich dennoch:

    • Die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" wurde beim Import meines persönlichen Zertifikats automatisch zu "Zertifizierungsstellen" hinzugefügt.
      Es sind keine der 3 Vertrauenseinstellungen aktiviert gewesen. Ich habe nachträglich keine Häkchen gesetzt.
      Beides steht im Gegensatz zu
      Quote from "Peter_Lehmann"

      - Zuerst das Herausgeberzertifikat von Thawte importieren (CN = Thawte Personal Freemail Issuing CA) <== müsste es sein
      - Diesem das Vertrauen aussprechen (wichtig)


    • Warum wird in GMX Webmail die Signatur als gültig, aber unbekannt dargestellt? Liegt das daran, dass das Zertifikat nicht auf meinen Namen ausgestellt ist? Oder liegt das daran, dass GMX die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" nicht kennt? Gegen letzteres spricht, dass MS Outlook Express und MS Outlook die Signatur als gültig einstuft, da es über einen Zertifizierungspfad die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" als gültig erkennt, obwohl diese nicht vorinstalliert ist.
    • Sollte ich mein persönliches Zertifikat aus dem FF entfernen?
    • Sehe ich es richtig, dass die Zertifikate von http://www.thawte.com den Vorteil gegenüber Zertifikaten von z.B. http://www.trustcenter.de haben, dass ich bzw. die Empfänger meiner E-mails die Zertifizierungsstelle nicht importieren müssen? Ich glaube, so etwas hier irgendwo auch schon gelesen zu haben...


    Also nochmal zusammenfassend: Warum muss ich der "Thawte Personal Freemail Issuing CA" nicht vertrauen? Warum zeigt GMX Webmail die Signatur als unbekannt an? Ist die Theorie mit dem Zertifizierungspfad (Mozilla nennt das glaube ich Zertifizierungshierarchie) richtig?


    Noch eine Bitte: Vielleicht kann mir jemand mit Thawte- und jemand mit einem anderen Zertifikat eine Testmail schicken. Bitte per PN nach der Adresse fragen.


    Achso: Ist die CRL http://crl.thawte.com/ThawtePersonalFreemailIssuingCA.crl die Richtige? Welche Einstellung habt ihr bei OCSP? Hat jemand Erfahrungen mit dem OCSP Server von openvalidation.org? Bei mir hat der nicht funktioniert. Habe jetzt "OCSP nur zur Valifizierung von Zertifikaten, die..." eingestellt.


    Vielen Dank für Eure Hilfe und Mühe,


    wurstsemmel

  • Thwate zertifikat in Thunderbird importieren!

    Edit am 30.03.07: Habe einen neuen Thread aufgemacht, nachdem hier der letzte Beitrag doch nicht mehr taufrisch ist. Bitte dort anworten. Danke.



    Hallo,


    und einen schönen Gruß in dieses tolle Forum!


    Ich habe mir bei http://www.thawte.com ein "Free Personal E-mail Certificate" geholt. Import in TB war problemlos, signieren und verschlüsseln an mich selbst funktioniert. Auch das Senden von signierten E-mails (nicht verschlüsselt) an andere Personen ist kein Problem.


    Folgende Fragen habe ich dennoch:

    • Die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" wurde beim Import meines persönlichen Zertifikats automatisch zu "Zertifizierungsstellen" hinzugefügt.
      Es sind keine der 3 Vertrauenseinstellungen aktiviert gewesen. Ich habe nachträglich keine Häkchen gesetzt.
      Beides steht im Gegensatz zu
      Quote from "Peter_Lehmann"

      - Zuerst das Herausgeberzertifikat von Thawte importieren (CN = Thawte Personal Freemail Issuing CA) <== müsste es sein
      - Diesem das Vertrauen aussprechen (wichtig)


    • Warum wird in GMX Webmail die Signatur als gültig, aber unbekannt dargestellt? Liegt das daran, dass das Zertifikat nicht auf meinen Namen ausgestellt ist? Oder liegt das daran, dass GMX die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" nicht kennt? Gegen letzteres spricht, dass MS Outlook Express und MS Outlook die Signatur als gültig einstuft, da es über eine Zertifikatskette die Zertifizierungsstelle "Thawte Personal Freemail Issuing CA" als gültig erkennt, obwohl diese nicht vorinstalliert ist.


    Also nochmal zusammenfassend: Warum muss ich der "Thawte Personal Freemail Issuing CA" nicht vertrauen? Warum zeigt GMX Webmail die Signatur als unbekannt an? Ist die Theorie mit der Zertifizierungskette richtig?
    Noch eine Bitte: Vielleicht kann mir jemand mit Thawte- und jemand mit einem anderen Zertifikat eine Testmail schicken. Bitte per PN nach der Adresse fragen.


    Achso: Ist die CRL http://crl.thawte.com/ThawtePersonalFreemailIssuingCA.crl die Richtige? Welche Einstellung habt ihr bei OCSP? Hat jemand Erfahrungen mit dem OCSP Server von openvalidation.org?


    Vielen Dank für Eure Hilfe,


    wurstsemmel