Beiträge von wicki_w

Vorsicht bei der Weiterleitung von PGP-mails per TB-Filter!

Wir haben das auf 3 Systemen ausprobiert und sind der Meinung:

das ist ein ziemlicher Hammer.

Eigentlich ein Fall für die Bugzilla-Liste aber es fand sich niemand,

der das machen wollte. Ich hab keinen Account dort und beim Neuanlegen wird rumgezickt:

You have requested an account token too recently to request another. Please wait a while and try again.

So viel Zeit hab ich nicht.

Zusammenfassung:

Eine per Filter eingetragene Mail-Weiterleitung auf PGP-Mails erfolgt

ungefragt unverschlüsselt - egal, ob für die Zieladresse ein PGP-Key vorliegt

oder nicht.

Thunderbird/91.8.1 und 91.11.0 (64-Bit) - Linux

Verschlüsselung standardmässig aktiviert, _kein_ Master-Passwort

definiert.

Letzteres führt dann zumindest dazu, dass beim Empfang einer

weiterzuleitenden Mail ein Passwort abgefragt wird.

Hat man ein Master-Passwort definiert passiert das ganze wohl

völlig ohne Zutun des Anwendert. (nicht getestet)

Wer es nicht glaubt:

Einen neuen Local-Folder anlegen

Eine beliebige PGP-Mail hinein kopieren

Einen Filter mit einer Weiterleitung für diesen Folder einrichten

Den Filter ausführen

Auf der Empfängeradresse nachsehen und staunen

Das Subject kommt dabei als:

"Fwd: ..." an

Der Inhalt ist aber unverschlüsselter Klartext.

Aufgefallen ist das, weil ein Kollege eine Nachrichtauf einen nicht-PGP-Account

haben wollte, wenn eine Mail auf den PGP-Account eintrifft.

Dafür hat er sich dann einen Einganfsfilter gebaut - und war _sehr_

verwundert, das die Mail dort im Klartext ankam.

Ich wollte das nicht glauben - dann habe ich es nochmals selbst

und von 2 Leuten unabhängig testen lassen.

ps: ich hab nun doch die Bugzilla-Account Mail bekommen.

Zwei themenähnliche Bugs habe ich gefunden (beide knapp 20 Jahre alt )

aber keiner beschreibt das Problem.

Also habe ich das dort als neu eingetragen. (bug 1790736)

Wenn es ein Feedback gibt werde ichs hier posten.

Ich fände es ja auch toll, wenn das alles nur heisse Luft wäre.

Aber m. E. ist das ein extremes Sicheheitsrisiko.

Feedback wäre schön - vielelicht machen wir ja irgendwas grundsätzlich

falsch. Aber wenn dem so wäre: auch einem doofen Anwender darf

es nicht möglich sein, ungewollt entschlüsslte PGPs zu versenden.

Zitat von Veteran

Wovor hast Angst – daß es womöglich doch nur auf 'PEBCAC' beruht …?

dachte ich auch zuerst - das ist so brutal, dass man es nicht glauben kann.

und wenn es ein anwenderfehler wäre, dann hätten jetzt 3 leute - allesamt

berufs-IT-ler - den gleichen fehler gemacht.

Ich mache dafür nun einen then Thread auf.

"Ungewollter Klartextversand von PGP-Mails"

naja, ich sags mal so:

Mein letztes Posting hat nichts mehr mit der Einangsfrage zu tun.

Es geht darum, das TB Mail unverschlüsselt versendet ohne dass der

Benutzer des auf "standardmässig verschlüsseln" eingestellten TB

davon etwas mitbekommt.

Das ist krass - und das ist repoduzierbar.

und ich möchte nicht grade in einem offenen Forum posten wie das geht.

Ich werde das aber erst nochmal mit einem anderen Kollegen verifizieren

Ich glaube nicht, dass sowas geht. Das wäre ein Sicherheitsrisiko. Wenn jemand einstellt, dass er nur verschlüsselt senden will, dann darf nicht ohne Warnung unverschlüsselt versendet werden. Das wäre eine krasse Nummer.

Zitat von Altstadt

Wenn jemand einstellt, dass er nur verschlüsselt senden will, dann darf nicht ohne Warnung unverschlüsselt versendet werden. Das wäre eine krasse Nummer.

tja, ich will hier nicht grade ein Riesenfass aufmachen - Aber ein Kollege hat mich auf einen fatalen Bug hingewiesen.

Was ich erst nicht glauben konnte.

Aber er hat Recht. Mit 91.11.0 auf zwei verschiedenen System reproduzierbar:

TB versendet Mails unverschlüsselt. Das ist aber noch nicht alles - es ist noch viel krasser.

Ich brauche nun dringend einen Ansprechpartner mit dem ich das mal diskutieren kann.

An wen wende ich mich?

Fürs offene Forum ist das sicher nichts.

tja, jetzt habe ich haufenweise .eml-files - und bekomme sie nicht in ein TB-kompatibles format.

jedenfalls nicht alle auf einmal...

auch nicht optimal.

aber das import/export-addon - dass kann PGP mails als html-pages

(mit index und file-attaches) exportieren.

das sind dann zwar keine mails mehr - aber das ist in diesem falle nicht schlimm.

Zitat von Veteran

Ich würde die zu übermittelnden Mails in einen neuen 'Export'-Ordner kopieren und diesen als Datei dem Empfänger schicken, damit er ihn in sein Profil einfügen kann. Damit sollte er genauso Zugriff auf die Mails haben wie du.

naja.... dazu ist der export-ordner einfach zu gross....

ich habe nun alles als .eml exportiert und dass dann per bash/ pgp in .eml.decrypt.eml gewandelt.

Hi zusammen,

ein Empfänger, der alle seine eingegangenen PGP-Mails von mir verbaselt hat,

möchte sie jetzt gern nochmal haben (ich spreche von mehreren 1000).

Nochmal senden wäre ziemlicher Irrsinn.

Exportieren und als Archiv senden bringt ja nichts, denn sie sind ja lokal

mit meinem Key verschlüsselt.

Mit Enigmail-Filter unverschlüsselt exportieren geht wohl auch nicht mehr.

(da es kein Enigmail mehr gibt)

Und eine andere Möglichkeit zum unversschlüsselten Export habe ich noch nicht

gefunden.

Hat jemand eine Idee dazu?
(Ausser, die .emls mit einem pgp/bash-script zu entschlüsseln - was dann auch nicht

wirklich deppenkompatible Formate erzeugt)

Gruss

wicki

Hi zusammen,

TB 78.13.0 (64-Bit) - Linux

mich nervt etwas, dass es (wenn PGP-Default eingeschaltet ist) beim Klick auf "senden" immer

eine Meldung gibt

"Die Nachricht kann nicht mit Ende-zu-Ende-Verschlüsselung gesendet werden, weil es Probleme mit den Schlüsseln folgender Empfänger gibt: x@y.de"

und ich mich durch die Sicherheitsfenster klicken muss.

Gibt es eine Option

"versende ohne Nachzufragen onhe PGP wenn der Empfänger keinen Key hat"

?

Wenn es sie gibt hab ich sie noch nicht gefunden....

Viele Güße

Wicki

Zitat von Altstadt

Zitat von wicki_w

Was bitte ist dran eine schlechte Wahl?

Falls das eine ernst gemeinte Frage ist, lies in Ruhe Beitrag #8. Deine selbstgestrickte Lösung hat viele Nachteile und Einschränkungen. Mit dem für Kalender vorgesehenen Protokoll CalDAV oder mit Generalsync hättest du die nicht.

ja, das ist eine "ernst gemeinte Frage".

Ich habe ganz bestimmte Anforderungen. s.o.

Und genau die werden alle erfüllt.

Und WEBDAV/.ics mit zusätzlicher Rechteverwaltung ist weder "selbstgestrickt"

noch hat sie "Nachteile und Einschränkungen" für _diesen_ Anwendungsfall.

Wären die Anforderungen anders, würde ich anders daran gehen.

Aber in diesem Fall wird halt genau das Problem gelöst. Mit Standardmitteln,

die alle vorhanden sind.

Wenn es mal eine Zeit lang im Einsatz ist, denke ich vielleicht anders darüber.

Zitat von Altstadt

Mehr als dir zu erklären, dass deine Methode eine schlechte Wahl ist, kann man nicht machen. generalsync hat wie ich finde sehr gut erläutert, wie es besser geht.

Was bitte ist dran eine schlechte Wahl?

Ich möchte die Daten für alle berechtigten User lesbar als plain-ASCII

auf einem Server haben.

Die Übertragung soll nicht im Klartext erfolgen.

Jeder darf _alle_ Termine _lesen_.

_schreiben_ darf nur der Eigentümer des Kalenders.

Das Problem "Schreibrechte" löse ich entweder durch ein Servlet-Filter

oder durch Verzeichnishierarchie.

Damit ist genau das erfüllt, was ich wollte.

> Nackter Dateizugriff ist völlig untauglich sobald es um mehr als einen Computer geht

eigentlich ging es erst mal nur darum, die daten nicht im klartext übers netz zu schicken.

das ist jetzt mit https/webdav gelöst.

das war der primäre grund für diesen thread.

da war ich noch davon ausgegangen, das TB in der lage ist, zu erkennen ob jemand

zwischenzeitlich den kalender verändert hat. aber das ist ja nicht der fall.

also die nächste stufe: jeder bekommt seinen eigenen kalender und jeder andere

bekommt darauf lesezugriff.

das setzt aber wiederum den "guten willen" des benutzers voraus.

(dass er nicht einfach in meinem kalender rumschreibt).

da ich keine lust habe, das auf verzeichnisebene zu handlen, werde ich wohl ein

filter-servlet vorschalten, dass user nur auf ihre eigenen kalender schreiben und

alle anderen nur lesen dürfen.

scheint mir momentan das sinnvollste zu sein.

ich möchte zunächst bei .ics bleiben - aber es gibt doch bestimmt auch fertige tools,

die .ics nach .sonstwas portieren können.

hintergrund/endziel: ich möchte termindaten zwischen bestehenden

alt-anwendungen und TB hin- und her schieben können.

Zitat von Roaster

 

Ich denke nicht, dass das CalDAV Protokoll in der Lage sein wird, lediglich einzelne Terminfelder abzugleichen und auszutauschen, das wäre mir neu. Ich denke es wird der komplette Termin immer wieder aufs Neue in die CalDAV Datenbank geschrieben, auch wenn User A nur den Starttermin und User B nur den Endetermin geändert hat.

ich glaube, das ist alles noch viel schlimmer:

da wird offenbar nicht der aktutelle stand eines termins

auf dem server mit dem aktuellen lokalen stand abgeglichen

oder ge"diff"t und ggf. gewarnt.

da wird einfach das gesamte ics-file auf dem server mit dem inhalt

des lokalen ersetzt.

so sieht es jedenfalls nach einem ersten test aus.

Zitat von generalsync

Ich verstehe dein Szenario glaube ich noch nicht ganz: was ist dein Ziel, und was ist dein Angriffsszenario?

 

Es geht lediglich darum, dass die Termindaten und user/passwort nicht

"im klartext" übers Netz laufen sollen.

Nachtrag:

heisst das obige, dass TB nicht selbständig sowas wie "locking" betreibt und

User a

den Kalender von

User b

überschreibt, wenn er einen Termin einträgt - und User b 1 Sekunde vorher

ebenfalls einen eingetragen hat ?

(wenn beide den gleichen Account benutzen)

und es somit nur einen schreibberechtigten User pro Kalender geben darf?

Hi zusammen,

wie löst Ihr das Problem der unverschlüsselten Übertragung der Daten via I-Net ?

SFTP scheidet aus, das TB das nicht kann (wenn ich auf dem laufenden bin)

VPN setzt clientseitig einen gewissen Aufwand voraus

plain FPT scheidet aus

bleibt also nur WEBDAV per HTTPS

(habe ich noch nicht ausprobiert)

oder kennt Ihr andere Lösungsmöglichkeiten?

BTW: kann jemand ein Script zur externen Auswertung des .ICS-Formats empfehlen?

(also zum Zerlegen in Datum, Zeit, Ort, Text usw...)

so, ich habe nun 2 installationen

(gleiche TB-version, gleicher Rechner, gleiches OS, gleicher User

- nur anderes Profile)

eine version sendet (unverschlüsselt signiert) eine nicht.

das console-log:

JavaScript error: resource://gre/modules/ActorManagerChild.jsm, line 297: TypeError: singletons is null
Extension error: Error while loading 'jar:file:///usr/lib/thunderbird/omni.ja!/chrome/messenger/search-extensions/twitter/manifest.json' (NS_ERROR_FILE_NOT_FOUND) resource://gre/modules/Extension.jsm:570 :: readJSON/</<@resource://gre/modules/Extension.jsm:570:20
onStopRequest@resource://gre/modules/NetUtil.jsm:128:18


console.log: (new Error("Cannot load required OTR library", "resource:///modules/OTRLib.jsm", 75))
console.debug: "public keys: 92, secret keys: 0"
console.debug: "Successfully loaded optional OpenPGP library libgpgme.so.11 from system's standard library locations"
console.debug: "gpgme version: 1.13.1-unknown"

bis hier hin ist es bei beiden gleich - und bei der version, die signiert sendet,

ist das log auch hier zu ende.

in der anderen version geht es so weiter:

JavaScript error: chrome://enigmail/content/modules/subprocess.jsm, line 344: uncaught exception: Object
JavaScript error: chrome://enigmail/content/modules/subprocess.jsm, line 344: uncaught exception: Object
(ja, diese zeile kommt 2x)


JavaScript error: , line 0: uncaught exception: Object
JavaScript error: chrome://chat/content/conversation-browser.js, line 853: NotSupportedError: CustomElementRegistry.define: 'conversation-browser' has already been defined as a custom element
console.debug: "in getEncryptionFlags, gSendEncrypted=false, gSendSigned=true"
console.debug: "getCryptParams parameters: from=0x0112233445566778, to=hans@wurst.de, bcc=, hash=SHA256, flags=37057, ascii=0, errorObj=%o, logObj=%o" ({value:""}) ({})
console.debug: "getCryptParams, got: to=tu@nix.de, bcc="
console.debug: "getCryptParams returning:"
console.debug: ({sender:"0x0112233445566778", sign:true, signatureHash:"SHA256", sigTypeClear:false, sigTypeDetached:true, encrypt:false, encryptToSender:false, armor:true, senderKeyIsExternal:true, to:["tu@nix.de"], bcc:[]})
console.debug: "sendFlags=000090c1"
console.debug: (new Error("failure in finishCryptoEncapsulation", "chrome://openpgp/content/modules/mimeEncrypt.jsm", 592))
JavaScript error: chrome://openpgp/content/modules/mimeEncrypt.jsm, line 592: Error: failure in finishCryptoEncapsulation

klar, ich kann einfach das andere profil benutzen - aber ich wüsste

gerne: was ist die ursache

jemand eine idee dazu?

nachtrag:

ja, ich schreibe von PGP-mails...

weil er beim reply auf PGP-mails offenbar ein

"unterzeichnen" mit S/MIME als default eingestellt hat.

warum auch immer.....

aber nun kann ich mich drum kümmern, warum er das cert nicht will.

wenn ichs weiss, werde ich berichten.

dass es nicht am grossen "H" liegt weiss ich nun.

also: danke susi.

vielleicht haben wir es da wirklich mit einem mistverständnis zu tun:

ja, ich bin davon ausgegangen, dass TB mit "nachricht unterchreiben"

natürlich eine digitale signatur im sinne von

"der inhalt dieser nachricht ist von hast@wurtst.de erstellt worden

und wurde nach dem erstelle nicht verändert"

und nicht eine "signatur" im sinne von

---------------------- hier abbeissen ---------------------

---

hans@wurst.de - die wurst ohne enden

------------------------------------------------------------------

und ich gehe auch davon aus, dass "nachricht unterschreiben" im TB

genau das bedeutet.

und ich habe es gerade nochmal getestet.

einen zweiten TB mit hans@wurst.DE als absender eingerichtet:

die mail geht raus!

also ist es tatsächlich nicht case-sesitiv.

susi hat recht.

also ist das problem ein anderes.

das sehe ich mir am WE mal an.

drauf gestossen bin ich eh nur, weil beim reply auf eine PGP-mail

immer "unterschreiben" aktiv ist und die mail nicht rausgeht, wenn

man das nicht _AB_wählt. (ja, das war ein typo)

weil das nervte (und nur deshalb) dachte ich mir:

"na gut, soll er halt ne signatur bekommen"

und was in der us version "digitally sign this.." heisst,

heisst in der .de-version "unterschreiben".

dass das jemand einen "footer" drunter versteht

hätte ich nun nicht gedacht....

" dann ist es für mich irgendwann mal gut."

warum hältst du dann nicht einfach die klappe?

welche infos die fehlen hast du immer noch nicht gesagt...

es steht alles drin -

es geht um _diesen_ default, der immer angewählt ist, wenn man eine

pgp-mail beantwortet.

und um die tatsche, dass er eine signatur nicht nimmt, wenn

sie von hans@ statt von Hans@ ist.

irgendwie ist es müßig, dass es hier immer so sehr an der eigentlichen Thematik vorbei geht...

"Außerdem hast du wieder einmal die Eingangsfragen nicht beantwortet,"

welche (hier relevante) "Eingangsfragen sind unbeantwortet?

> "Zitat von wicki_w Das mit der case-sensitivity sehe ich richtig - oder ?

> Das wäre mir neu. Ich kenne solche Berichte nur in Zusammenhang

> mit Apple Mail. Ich habe mir das aber noch nie angeschaut.

"das wäre mir neu" ist aber auch alles andere als eine verbindliche Aussage.

Probier es aus. Eine Mail von Hans@Wurst.de mit der Signatur von hans@wurst.de

signieren, das geht nicht.

Vielleicht mache ich was falsch - will ich nicht ausschliessen. Daher frage ich ja.

Vielleicht ist das auch nur bei Signaturen von "Actalis" so ?

> > Zitat von wicki_w Nachdem TB 78 defaultmässig PGP-Mails immer signieren will,
> > habe ich ihm nun eine Signatur gegeben.

> Diese Aussage ergibt so keinen Sinn, zumal du im weiteren Verlauf

> von S/MIME schreibst. Das klingt, als würdest gerade so einige Dinge

> komplett durcheinander bringen.

ich bringe keine "dinge durcheinander" - TB78 will beim Reply auf eine PGP-Mail

eine Signatur setzen. Das lässt sich nicht abschalten - zumindest habe ich keine

Möglichkeit gefunden

Ja, ich kann es explizit anwählen - aber wenn man das nicht macht, dann kommt

"Senden nicht möglich" (ohne zu erwähnen, _warum_ nicht.

(Und um herauszufinden, was dernn der Grund für "Senden nicht möglich" ist,

musst ich die consolen-Meldungen ausgeben lassen, mitlesen und interpretieren)

Nachdem TB 78 defaultmässig PGP-Mails immer signieren will,

habe ich ihm nun eine Signatur gegeben.

Da ich aber eine Signatur von hans@wurst.de habe, aber als

Hans@Wurst.de sende, will er die Signatur nicht nehmen.

Sie stammt von "Actalis". Habe ich testweise mal zum ausprobieren

gemacht - und da Mailadressen case-insensitiv sind, habe ich

das Zertifikat für hans@wurst.de genommen.

Das nimmt TB aber nicht - wg. der Gross/klein-schreibung...

Wenn ich versuche, dort ein neues für Hans@Wurst.de zu bekommen,

dann sagen die aber: "Hans@Wurst.de" hat schon ein Zertifikat....

Das ist technisch natürlich verständlich bzw. erklärbar - wirklich

"logisch" kommt es aber nicht rüber.

Darüber möchte ich nun aber keine Grundsatzdiskussion anstossen.

Sondern einfach nur wissen:

Das mit der case-sensitivity sehe ich richtig - oder ?

und

Woher bezieht Ihr eure Zertifikate ?

wicki