Beiträge von generalsync

Es ist technisch nicht möglich, einen verschlüsselten Schlüssel ohne Eingabe der Passphrase zu nutzen. Das ist ja gerade der Sinn einer Verschlüsselung.

Wenn es Dich so sehr stört, dass Du dafür bereit bist die Sicherheit deutlich zu reduzieren: es ist möglich, Schlüssel ohne Verschlüsselung zu speichern: Im Menü "Enigmail | Schlüssel verwalten", dann Rechtsklick auf Deinen Schlüssel und "Passphrase ändern..." – die Felder können dort leer gelassen werden.

Ich würde aber davon abraten: unverschlüsselte Schlüssel bergen substantielle Sicherheitsrisiken, die gerade ohne tieferes Verständnis der Materie leicht unterschätzt werden. Auch wenn Du später wieder eine Passphrase setzen solltest, können Teile eines vormals unverschlüsselten Schlüssels eventuell rekonstruiert werden.

Ich glaube nicht, dass es dazu eine Dokumentation gibt. Du kannst aber direkt den Code lesen, der die Meldungen ausgibt, für die erste Meldung z.B nsImapProtocol.cpp:1350. Das "this" ist also die Adresse der nsImapProtocol-Instanz, die die Meldung generiert hat. Die Zahlen am Anfang kommen von MOZ_LOG bzw. der Logging-Infrastruktur und identifizieren vermutlich das Modul, das die Meldung generiert sowie das Log-Level der Nachricht. Habe das nicht genau gelesen, Dokumentation zu dem Makro ist in Logging.h:204, zu den Konzepten gibt es einen MDN-Artikel.

Links sind jeweils für Thunderbird 60.

Zitat von Ruhezone

Es würde genügen, wenn der Empfänger die Wahl hätte, sie mit seinen eigenen Präferenzen zu überschreiben.

Nein, da Design viel zu komplex ist um mit "einer Schriftgröße" überschrieben werden zu können. Eine solche Überschreibung birgt die Gefahr, das Layout vollständig zu vernichten (das wäre wirklich nicht tragbar).

Das Standardlayout von Thunderbird sieht dagegen direkt vor, dass der Empfänger die Schrift vorgibt und baut sich in Abhängigkeit davon auf. Man könnte auch ein professionelles Layout auf einer solchen Grundlage aufbauen.

Zitat von Ruhezone

Es gibt eine große Zone zwischen einem professionellen und gar keinem Layout.

Ja, aber die Wahrscheinlichkeit das ein durchschnittlicher Nutzer ein Layout designen kann, dass hinterher so funktioniert wie er/sie sich das vorstellt, ist gering. Das gilt insbesondere für scheinbar einfache Dinge wie Schriftgrößen, denn wie Du richtig sagst:

Zitat von Ruhezone

Dies auch nicht zum Spaß. Eine falsche Schriftgröße kann sich übel auswirken. So entstehen ungewollte Zeilenumbrüche oder zerhackte Überschriften beim Ausdrucken.

Genau diese Probleme kann man nicht mit allein mit einer festen Schriftgröße lösen. Schließlich muss sich die Mail beim Drucken an unterschiedliche Papiergrößen anpassen können, auf einem Smartphone und einem PC-Monitor ordentlich aussehen, etc. Genau das kann ein professionelles Layout.

Eine feste Schriftgröße funktioniert dagegen eher schlechter als der Standard, der wenigstens immer eine gut lesbare Schrift wählen sollte.

Wenn Du das nicht willst: zwei Alternative Lösungen für dein Problem sind PDF (eine feste Dokumentengröße vorgeben, sodass sich das Layout nicht dynamisch anpassen muss) und Reintext (Beschränkung auf ~80 Zeichen in der Breite und Kompatibilität mit noch mehr Ausgabegeräten, z.B. Textmonitor und -drucker). Ersteres geht als Attachment und ist sinnvoll für komplexe Dokumente, letzteres geht direkt (dafür aber ohne Bilder oder erweiterte Formatierung).

Zitat von Ruhezone

Bisher hat mir auch noch niemand erklären können, welchen Vorteil es bietet, dass Thunderbird von diesen Möglichkeiten keinen Gebrauch macht. Mein Eindruck ist inzwischen, dass es sich um ein Relikt aus der Urzeit handelt.

Dank dieser Methode kann sich die Mail korrekt an die Vorlieben des Empfängers anpassen (z.B. ist eine große Schrift immer größer als "normal", egal wie groß "normal" im konkreten Fall sein sollte). Außerdem funktionieren damit auch "bessere" Layouts im normalen Verfassen-Fenster, ohne dass zusätzliche Add-ons gebraucht werden. Ob das gewollt oder positiver Seiteneffekt eines urzeitlichen Relikts ist, kann ich aber nicht sagen.

Zitat von Ruhezone

Bekommt man eine Mail von so einem Exoten, erkennt man sie auf die ersten Blick, eben weil die Schriftgrößen und die Proportionen nicht stimmen.

Das ist Geschmacksfrage. Ich persönlich mag das Design von Outlook-Mails nicht so. Aber natürlich nimmt Outlook auch nicht unbedingt schmeichelhafte Voreinstellungen, auf denen das Thunderbird-Layout dann aufbaut. Insofern kann ich deine Kritik zumindest in dieser Richtung nachvollziehen.

Wenn du den Outlook-Stil magst, kannst Du ihn ja nachbauen (lassen), bzw. kopieren sofern Dir das Deine Outlook-Lizenz erlaubt.

Man kann sicherlich streiten, ob Thunderbird ein paar "generische" professionelle Layouts als Vorlage anbieten sollte. Wäre vermutlich keine schlechte Idee für Nutzer wie Dich. Mir persönlich reicht auch Reintext

Zitat von Ruhezone

Könntest du das bitte erläutern? Was habe ich von einer Signatur mit fixer Schriftgröße, wenn dies nicht für den eigentlichen Inhalt gilt?

Wenn die Schriftgröße aus der Signatur nicht für den Inhalt gelten würde, hättest Du natürlich nichts davon. Das ist aber nicht der Fall, da diese Signatur das Layout des Dokuments ändert. Probiere das Beispiel aus, dann siehst Du vermutlich gleich was ich meine.

Ob mein primitives Beispiel in allen Mail-Clients korrekt funktioniert, kann ich aus dem Stand aber natürlich nicht garantieren. Außerdem betrifft es nur die Standard-Schrift, nicht aber die größeren / kleineren Varianten. Das wäre aber alles machbar, wenn man Zeit und Lust hätte, ein entsprechendes Layout zu entwickeln.

Zitat von mrb

In einem Büro dürfen derartige Fehler aber nicht vorkommen.

Beim Empfang wurde ja alles korrekt dargestellt, wenn ich die bisherigen Aussagen hier richtig verstanden habe. Und auch gesendete Nachrichten kommen so an, wie sie gesendet wurden. Natürlich hat Outlook bestimmte Modi, in denen es ausschließlich mit Outlook kommunizieren kann (und dann diverse proprietäre Erweiterungen unterstützt). Solche "Mails" sollten Thunderbird allerdings nie erreichen, sofern der Admin des Versenders bei der Konfiguration von Outlook keine groben Fehler gemacht hat.

Solange es also wirklich nur Schriftgrößen und anderen Designkram beim Antworten geht, halte ich das nicht für tragisch. Bestehenden Text in ein anderes Layout setzen ist schon für Menschen nicht immer ganz einfach, da kann man von den Thunderbird-Automatismen keine perfekten Ergebnisse erwarten. Ich hatte bislang aber auch nicht den Eindruck, dass Outlook oder andere Clients in diesem Punkt viel besser sind...

Zitat von mrb

Wer also Wert auf immer korrekt formatierte Mails legt, sollte nicht mit Thunderbird arbeiten und wer es kommerziell zuverlässig nutzen will, sollte besser Abstand halten.

Über die erste Aussage lässt sich sicherlich streiten, der zweiten muss ich aber klar widersprechen.

Wenn ein Mail korrekt aufgebaut ist, wird sie in Thunderbird auch korrekt angezeigt. Einige Mails halten sich nicht an die Regeln, bei diesen kann es zu Problemen kommen. Das ist aber nicht wirklich die Schuld des Mailprogramms, sondern ein Trend vergleichbar mit der Webseitenentwicklung der 90er Jahre: Mails werden gezielt nur für populäre Clients geschrieben wird anstatt sich an die Standards zu halten. Aus Sicht der Versender ist dies positiv: die "offiziell" unterstützten Clients ermöglichen weitgehende Analysefunktionen, um den Empfänger der Mail zu überwachen. Je mehr Nutzer dorthin wechseln, desto mehr Daten kann man sammeln.

In der Praxis habe ich in Thunderbird bislang mit keiner seriösen Mail Probleme gehabt. Bei problematischen Mails handelte es sich – zumindest bei mir – ausschließlich um Werbung.

Beim Versenden konzentriert sich Thunderbird auf die direkte Kommunikation. Standardmäßig fügt sich dabei der eigene Text möglichst schmerzfrei in die Oberfläche des Gegenübers ein. Das bedeutet, dass die Darstellungshoheit beim Empfänger und nicht beim Sender liegt. Damit das funktioniert, kann man als Absender keine absoluten Schriftgrößen o.ä. bestimmen. Stattdessen nutzt man HTML so wie es gedacht ist: als Beschreibungssprache. Dazu kommt ein sauber (!) Reintext – oder man lässt HTML gleich ganz weg, da man keine besondere Formatierung braucht.

Wenn man das nicht will, nutzt man stattdessen ein professionelles Layout. Ein "normaler" Nutzer kann und soll ein solches Layout nicht erstellen, das erledigt ein Spezialist einmal für alle. Der Nutzer soll nur noch bestimmen, wo welche Eigenschaft des Layouts zum Tragen kommt. Auch hier kann ein Nutzer nur relativ agieren, z.B. zur Festlegung von Überschriften, Betonungen o.ä.. Die absoluten Schriftgrößen und andere Einstellungen wurden aber bereits im Layout festgelegt (und auch dort ist es nicht zwingend ein absolutes Maß, sondern z.B. abhängig vom Endgerät). Auch die automatische Erzeugung des Reintextes sollte kein Problem sein und ansehnliche Resultate liefern. Solche Layouts unterstützt Thunderbird z.B. mit der Signatur-Funktion.

Um die Ausgangsfrage von @Ruhezone mit einem Layout zu beantworten: aktiviere "HTML verwenden" für die Signatur und füge z.B. '<style>html{font-size:72pt}</style>' in die Signatur ein. Ein so primitives 'Layout' ist aber meiner Meinung nach deutlich schlechter als der Standard, da so die Darstellungsvorlieben des Empfängers überschrieben werden.

Für aufwändige Newsletter o.ä. braucht man aber natürlich ein spezialisiertes Tool (und entsprechende Kenntnisse).

Zitat von MBGucky

Ich halte es für am wahrscheinlichsten, dass nun auch Thunderbird keine Zertifikate mehr von Startcom akzeptiert.

Über eine Rückmeldung ob dies tatsächlich so ist würde ich mich freuen.

In der Standardeinstellung ist dies seit NSS 3.34 (Thunderbird 58) der Fall. Es müsste weiterhin möglich sein, das Root-Zertifikat manuell zu Importieren und ihm Vertrauen auszusprechen, wenn Du das willst. Bedenke dabei aber, dass Startcom dabei erwischt wurde, Zertifikate zu fälschen.

Zitat von Ruhezone

Soweit würde ich aber natürlich nicht gehen.

Deshalb sprach ich von "Szenario". Sicherheit ist immer eine Abwägung und Bewertung von Risiken. Man muss sich der Risiken nur bewusst sein.

Neben Caches und der Wiederherstellung von der Platte will ich auch den unbeabsichtigten Upload durch Virenscanner, andere "Sicherheitstools" oder Tracking/Analyse-Komponenten explizit erwähnt haben (solche Tools können oftmals Daten offline "einsammeln" und erst später hochladen).

Zitat von Ruhezone

Ein Offline-Hauptschlüssel (S/C/E).

Gibt es einen Grund, dass du vom Standard abweichen willst? Ein Hauptschlüssel wird normalerweise nicht direkt zur Verschlüsselung genutzt.

Zitat von Ruhezone

Darunter erstelle ich jeweils einen RSA und ECC Subkey. Die bekommen beide S/E/A.

Du musst dann zuerst den RSA-Key erzeugen, wenn Du ECC als Standard nutzen willst. Gnupg nimmt den neuesten unterstützten Subkey, wenn nichts anderes angegeben ist.

Ich würde außerdem S/A und E trennen. Das ermöglicht Dir mehr Flexibilität, wenn Du dein Subkey-Setup nochmal ändern willst (und ist theoretisch auch einen Tick sicherer).

Zitat von Ruhezone

Die Schlüssel würde ich offline erzeugen (also unter Airgap) und den primären wie beschrieben nach dem Erstellen der Subkeys und dessen externer Sicherung löschen. [...] Somit ist der primäre Schlüssel durchgängig offline und bekommt nie Kontakt zu anderen Geräten oder gar dem Internet. Oder habe ich da einen Haken übersehen?

Das zuverlässige Löschen eines Schlüssels ist je nach Szenario nur schwer bis gar nicht möglich.

Wenn man davon ausgeht, dass Hardware prinzipiell unbemerkt Daten speichern kann, darf ein Gerät hinter der Airgap bis zur physischen Vernichtung nicht mehr mit dem Internet verbunden werden. Der Schlüssel kann also ohnehin einfach gespeichert bleiben, bis Du ihn das nächste mal brauchst.

Wenn in Deinem Szenario die Hardware vertrauenswürdig ist, reicht das vollständige Überschreiben aller Datenträger. Den Schlüssel zusätzlich einzeln zu Löschen bringt dann keinen nennenswerten Sicherheitsgewinn. Wenn du Linux nutzen würdest, könnte man eventuell noch debattieren, ob und wie man gezielter vorgehen kann – bei Windows, insbesondere Windows 10, macht das aus meiner Sicht keinen Sinn. Es gibt einfach zu viele Komponenten, die Kopien von Dateien machen und später hochladen könnten. Als Alternative ginge vielleicht auch ein Live-Linux, dass keine Spuren auf den Platten hinterlässt, aber auch hier würdest du den Schlüssel nicht einzeln löschen.

Daher meine Aussage zur fehlenden Airgap: es klingt, als wolltest Du den Schlüssel auf einem "normalen" Gerät erzeugen, den Primärschlüssel aus dem Schlüsselbund löschen und das Gerät dann im Internet weiternutzen. Das erfordert absolutes Vertrauen in Hard- und Software des Geräts (incl. aller installierter Programme!). Wenn du das Vertrauen hast, spricht natürlich nichts gegen diese Vorgehensweise. Ich hätte es aber nicht, auch da das Löschen von Schlüsseln seit der Einführung von gnupg-agent (ab gnupg 2.0) bei mir nicht immer zuverlässig funktioniert hat. Von anderen Komponenten mal ganz zu schweigen

Wenn Du dem "Schlüsselerzeugungs-Gerät" und seiner Software vollständig vertraust, kannst Du darauf aber natürlich den Primärschlüssel weiternutzen und für den Laptop oder andere Geräte Subkeys erstellen. Ist dann zwar keine Airgap, aber ermöglicht immer noch das einzelne Zurückziehen von Schlüsseln für die anderen Geräte. Und ist ein ganzes Stück bequemer als eine echte Airgap.

Zitat von scorpion57

Irgendwelche Ideen?

Zwei Optionen:

• Langfristige Lösung: die Thunderbird-Entwickler haben sich bereit erklärt, eine versteckte Einstellung hinzuzufügen. Bislang hat ihnen aber niemand einen solchen Patch zukommen gelassen. Wenn Du programmieren kannst, schreib einen entsprechenden Patch und hänge ihn an Bug 1140035.
• Kurzfristige Lösung: mach es wie bisher. Der einzige Unterschied ist, dass man eine .xpi-Datei nicht mit einem Texteditor öffnen darf, dabei geht sie kaputt. Benenne sie stattdessen in .zip um und entpacke sie. Dann kannst du die darin enthaltenen Dateien ganz normal ändern. Anschließend wieder alles in ein zip-Archiv einpacken und wieder in .xpi umbenennen. Mit jeder neuen Version von Thunderbird muss der Vorgang wiederholt werden.

Zitat von Ruhezone

Was schickt Enigmail denn mit, wenn ich meinen öffentlichen Schlüssel anhänge?

In PGP enthält ein "öffentlicher Schlüssel" alle öffentlichen Schlüssel (Subkeys und Primärkey), UIDs, exportierbare Signaturen, etc.

Zitat von Ruhezone

Werden sämtliche öffentlichen Subkeys mitgeschickt, also auch die der anderen E-Mailadressen?

Ich glaube, hier hat sich ein Verständnisproblem eingeschlichen: Subkeys beziehen sich nicht auf E-Mail-Adressen, sondern sind immer für alle UIDs des Schlüssels gültig. Die Einschränkungen der Subkeys beziehen sich auf die damit erlaubten Aktionen (z.B. kann ein S-Subkey ausschließlich zum Signieren von Nachrichten oder Daten verwendet werden, nicht aber zum Entschlüsseln oder Signieren anderer Keys). Außerdem haben Subkeys individuelle Gültigkeit, können also einzeln mit einem Ablaufdatum versehen werden oder zurückgezogen werden.

Zitat von Ruhezone

Ich hatte mir das so gedacht, auf der Kommandozeile: [...]

Mit Glück kann das zwar funktionieren, aber deine Schlüssel bleiben dabei nicht offline. Normalerweise wäre das Vorgehen:

1. Erzeugung des gesamten Schlüssels (alle UIDs und Unterschlüssel) unter Airgap, d.h. auf einem isolierten Gerät ohne Netzwerkzugriff
2. Ggf. Beglaubigung des Schlüssels mit anderen Schlüsseln unter Airgap
3. Export von öffentlichem Schlüssel
4. Export von privaten Teilschlüsseln (je nach Szenario einer bis viele)
5. Übertragung des öffentlichen Schlüssels sowie der Teilschlüssel auf die Geräte, auf denen die Schlüssel eingesetzt werden sollen (2 Dateien je Gerät: eine öffentliche und eine private)
6. Import des öffentlichen Schlüssels auf aktiv genutzten Geräten
7. Import des jeweiligen privaten Teilschlüssels auf aktiv genutzten Geräten
8. Ggf. Upload auf Keyserver (von einem der aktiv genutzten Geräte)

Bis auf Schritte 1 und 4 musst Du dabei nicht wirklich auf Subkeys achten.

Zitat von Ruhezone

Ich nehme an, dies bezieht sich auf den Fall mehrerer Subkeys zu einer Identität? Das könnte ich in meinem Fall ausschließen. Es wird für jede Mailadresse nur einen Subkey zum Signieren geben.

Wie bereits erwähnt, gibt es keinen Bezug von Subkeys zu UIDs. Wenn Du für zwei UIDs unterschiedliches Schlüsselmaterial nutzen willst, gehören die UIDs logischerweise nicht mehr zur selben Identität (und sollten daher unabhängige Schlüssel nutzen). In diesem Fall können sich die Schlüssel höchstens wechselseitig beglaubigen.

Zur eigentlichen Frage: Nein, das Problem tritt nicht auf, wenn ein Schlüssel nur einen S-Subkey enthält. Ich habe es nicht getestet, aber ich glaube abgelaufene S-Subkeys machen keine Probleme.

Zitat von Ruhezone

Die Frage ist, wie man diese dann später in Thunderbird benutzt. Genügt es, dazu den öffentlichen Teil des Hauptschlüssels in Thunderbird auszuwählen? Findet Enigmail dann den jeweils richtigen Unterschlüssel anhand der Mailadresse?

Für Deine Kommunikationspartner funktioniert alles automatisch. Es wird also immer der richtige öffentliche (Sub-)Schlüssel verwendet, um Deine Signaturen zu prüfen oder Nachrichten an Dich zu verschlüsseln.

Wenn Du entschlüsseln oder (Nachrichten) signieren willst, brauchst Du aber natürlich die entsprechenden privaten (Sub-)Schlüssel. Der öffentliche Teil ist dafür nicht ausreichend. Wenn Du zuerst den öffentlichen Schlüssel und erst danach die privaten Subkeys importierst, sollte der Import wie gewohnt funktionieren. Wenn ich mich recht erinnere kann es mit dem "modernen" gnupg ab Version 2 aber Probleme geben, wenn vor dem Import des öffentlichen Schlüssels private Komponenten desselben Schlüssels im Schlüsselbund gespeichert wurden.

Bei der Nutzung sollte immer automatisch der richtige Subkey gewählt werden. Aus mir unbekannten Gründen versagt die Automatik aber beim Signieren von Nachrichten, wenn mehrere Subkeys zum Signieren vorhanden sind und der private Teil des ersten S-Subkeys fehlt (siehe hier). Wenn ich mich richtig erinnere, lässt sich das entweder durch ein "Umsortieren" der Schlüssel beheben (sehr aufwändig, da gnupg das offiziell nicht kann) oder man löscht lokal einfach alle anderen S-Subkeys. Dann kann man eigene Signaturen nicht mehr zuverlässig prüfen, aber das Signieren funktioniert wieder.

Zumindest auf der Kommandozeile kann man alternativ den Subkey auch manuell wählen (Ausrufezeichen vor die Key-Id stellen). Mit Enigmail wird das aber schwierig. Da wäre es vermutlich einfacher, direkt das eigentliche Problem in gnupg zu patchen.

Zitat von muzel

Für "Anfänger" ist es vielleicht besser, genau ein Schlüsselpaar eineindeutig einer Mailadresse zuzuordnen, dann kann es keine Probleme bei der Zuordnung geben.

Dem kann ich nur zustimmen.

Das Einrichten und Pflegen eines Schlüssels mit mehreren Subkeys ist deutlich aufwändiger als die direkte Verwendung eines "normalen" Schlüssels. Wenn man aber (aus welchen Gründen auch immer) unterschiedliche Schlüssel auf derselben UID nutzen will, sind Subkeys sehr viel praktischer. Insbesondere kann auch ein Anfänger Mails an einen Schlüssel mit Subkeys senden, die Komplexität bleibt also beim Schlüsselinhaber. Bei mehreren primären Schlüsseln muss dagegen jeder einzelne Mailpartner mehr Aufwand treiben.

Zitat von Hanisch

Allerdings irritiert mich dort links die Angabe der Benutzer-ID 0x... (18 Zeichen), die mit irgendeinem Fingerprint nicht zusammenpaßt.

Das ist vermutlich die ID des verwendeten Subkeys. Auch bei einem "normalen" Schlüssel wird die Verschlüsselung intern mit einem Subkey durchgeführt. Das ermöglicht das nachträgliche Umsteigen auf komplexere Subkey-Strukturen und war bei einigen alten Verschlüsselungsverfahren auch technisch notwendig. Ich bin auch der Meinung, dass hier (zusätzlich!) die Anzeige des primären Schlüssels sinnvoll wäre, aber das ist eine andere Diskussion...

Zitat von Hanisch

Offensichtlich nimmt Enigmail aus dem Schlüsselbund für eine e-Mail Adresse (bei Vorhandensein mehrerer öffentlicher Schlüssel für diese e-Mail Adresse) immer nur die erste zum Verschlüsseln.

Das ist aber von Enigmail total suboptimal.

In Deiner Situation, ja. In der anderen Situation ist es dagegen essentiell, dass das genau so passiert. Nimm folgendes an:

• Nutzer A richtet PGP neu ein, es gibt aber noch einen alten (kompromittierten) Schlüssel. Da Nutzer A seinen Schlüssel verlegt hat, kann er nicht widerrufen werden, obwohl er kompromittiert wurde.
• Nutzer B will eine Email an Nutzer A schreiben, hat aber noch den alten Schlüssel.
• Nutzer B importiert den neuen Schlüssel und schreibt eine verschlüsselte E-Mail an A.

Es gibt nun drei Möglichkeiten, was passieren könnte:

1. Enigmail verschlüsselt nur mit dem aktuellsten Schlüssel. Das ist das in diesem Fall gewünschte Verhalten.
2. Enigmail verschlüsselt nur mit dem kompromittierten Schlüssel. Das würde zumindest auffallen, da die Mail beim Empfänger nicht lesbar ist.
3. Enigmail verschlüsselt mit beiden Schlüsseln. Jede angeblich verschlüsselte Mail ist kompromittiert, ohne das die Mailpartner davon viel mitbekommen (da ja alles "wie erwartet" funktioniert).

In meinem Umfeld ist diese Situation schon oft eingetreten. Eine mehrfache Schlüsselerzeugung habe ich dagegen noch nie "in freier Wildbahn" gesehen (von unabsichtlicher Verwendung mehrerer Schlüssel auf demselben Gerät mal abgesehen). Ich bin daher davon ausgegangen, dass sich Dein Mailpartner mit PGP intensiv auseinandergesetzt hat und nach Risikoabwägung beschlossen hat mehrere Schlüssel zu nutzen, um bei Geräteverlust die Schlüssel einzeln widerrufen zu können. Daher hatte ich Subkeys vorgeschlagen.

Zitat von Hanisch

Oder wird bei verschlüsseltem Versenden nicht jeweils für beide ID's (Fingerprint) verschlüsselt?

Ich würde mich nicht darauf verlassen. Du kannst das aber selbst testen: wähle unter Schlüsselauswahl "Immer (auch) manuell" und schaue Dir an, welche Keys genutzt werden (markiert durch Haken). Bei Bedarf kannst Du dann im Einzelfall weitere Keys aktivieren.

Allgemeiner Hinweis: um mehrere Schlüssel auf derselben UID zu nutzen, sollten lieber Subkeys genutzt werden. Damit kann derselbe primäre Schlüssel auf mehrere Geräte aufgeteilt werden und bei Bedarf partiell widerrufen werden. Ein weiterer Vorteil: auch wenn weitere Geräte dazukommen, müssen die Mailpartner nichts weiter tun als den Schlüssel aktualisieren.

Da dies der zuletzt aktive Thread zum Thema ist, hänge ich das mal hier an:

Die Entfernung von ATO war ein versehen und wird bald™ revidiert. Die bislang gewohnte Methode, das Add-on über die Add-on-Seite zu installieren und zu updaten soll also weiterhin unterstützt werden.

Zitat von Lord Wacky Armadillo

Codestelle im Sourcecode an der mbox gelesen oder geschrieben wird

Einstiegspunkte: "Berkeley Mailbox stores" werden in der Klasse nsMsgBrkMBoxStore (header, implementation) verwaltet. Eventuell ebenfalls hilfreich: nsEmlxHelperUtils::ConvertToMboxRD aus dem Apple-Mail-Importer. Links sind jeweils für Thunderbird 60.

Zitat von Hanisch

Ja, aber wenn in meinem Signaturtext die richtigen 8 Stellen stehen, dann wird doch nicht auf einen gefälschten Key ausgewichen

Ein beliebiger Teil des Fingerabdrucks eines neuen Schlüssels lässt sich frei festlegen, der Aufwand steigt aber mit der Länge des festgelegten Teils exponentiell an. 8 Zeichen sind mit heutigen Computern machbar. Jeder motivierte Angreifer kann also in Deinem Namen einen neuen Schlüssel erzeugen, der an 8 Stellen denselben Fingerabdruck aufweist. Es gibt also keine "richtigen" und "falschen" Stellen im Fingerabdruck: wenn der Angreifer weiß, welche Stellen Du in deiner Mail angibst, kann er einen entsprechend präparierten Schlüssel erzeugen und hochladen.

Wenn man auf einen Schlüssel verweist, sollte man daher mindestens 16 Zeichen (64 bit) des Fingerabdrucks oder – noch besser – direkt den gesamten Fingerabdruck angeben.

Zitat von Solaris

weshalb jemand z.B. Kalender nicht in der Cloud ablegen möchte, während sämtliche - auch sehr private - E-Mails dort unverschlüsselt liegen

Ich sehe darin keinen Widerspruch. Das "normale" E-Mail nicht optimal ist, steht denke ich außer Frage. Das heißt aber nicht, dass man deswegen aufgeben sollte. Im Gegenteil, es sollte anspornen, es bei der E-Mail besser zu machen (Verschlüsseln, zumindest für geheime/private Nachrichten auf bessere Technologien wechseln).

Gerade bei Daten, die traditionell mit den Geräten einer Person "mitreisen", bietet ein zentraler Cloud-Dienst im Alltag kaum spürbare Vorteile. Die Nachteile bleiben aber unverändert bestehen (z.B. Abhängigkeit von einer zentralen Infrastruktur, Probleme bei der Offline-Nutzung).

Man kann sicherlich streiten, ob und inwieweit die Cloud eine zusätzliche Rolle spielen soll. So halte ich den Einsatz der Cloud z.B. für die Verbindungsfindung zwischen Peers oder gar als "Datenhalte" von E2E-verschlüsselten Fragmenten durchaus für sinnvoll, solange der Nutzer diesbezüglich das letzte Wort hat. Die Cloud sollte aber meiner Meinung nach bei solchen Daten keine zentrale Stellung einnehmen.

Es gibt natürlich auch Anwendungen, bei denen ein solcher "lokaler" Ansatz nicht zweckmäßig ist. "Kommunikation zwischen Personen, die sich nicht persönlich kennen" ist so eine Anwendung. Eine lupenreine Verschlüsselung ist in so einem Fall technisch ohnehin nicht möglich, und eine gewisse "wolkigkeit" bietet hier tatsächlich oftmals Vorteile. Dazu kommen in diesem Fall soziale Argumente, die sich nicht rein technisch beantworten lassen. Aber auch hier ist es wichtig, Vor- und Nachteile abzuwägen. So bieten z.B. föderierte Systeme (E-Mail, XMPP, ...) oft mehr Funktionalität, Sicherheit und Flexibilität als zentrale Dienste aus der Cloud (Facebook und Co.).

TL;DR: Man sollte meiner Meinung nach nicht blind alles in die Cloud legen, nur weil andere Daten bereits dort liegen. Die Cloud hat Ihre Vor- und Nachteile, die im Einzelfall abgewägt werden müssen. Kalender und E-Mails sind unterschiedliche Einzelfälle.

Zitat von slengfe

Ist das keine Cloud?

Je nachdem, wen man fragt. Für mich ist der entscheidende Faktor, dass die physische Maschine in den Hintergrund tritt, d.h. nicht konkret vereinbart wird, auf welchem Server eine Dienstleistung konkret erbracht wird. Für intern administrierte Anwendungen auf "eigenen" Servern würde ich daher den Begriff Cloud eher nicht verwenden.

Es gibt aber auch Definitionen, bei der jeder einzelner Server eine Cloud darstellt, manchmal sogar bereits ohne Verbindung zum Internet (Marketing spricht dann gerne von "Private Cloud"). Die genaue Auslegung des Begriffes ist damit inzwischen eher eine Geschmacksfrage

Zitat von slengfe

Du wirst eine Cloud brauchen - von alleine kommen die Daten nicht von einem TB auf den anderen

Dem letzten Teil kann ich nur zustimmen. Neben der Cloud gibt es aber natürlich auch andere Optionen (mit anderen Vor- und Nachteilen):

• Wenn der Arbeitgeber einen Server betreibt, der von beiden Arbeitsplätzen aus erreichbar ist, kann eventuell darüber synchronisiert werden
• Wenn ein oder mehrere Geräte regelmäßig zwischen den Arbeitsplätzen hin- und herpendeln (z.B. ein Smartphone), können darüber Daten übertragen werden. Entweder manuell wie slengfe das mit seinen lokalen Kalendern macht, oder automatisiert mit einem Tool wie GeneralSync
• Wenn zwischen den Arbeitsplätzen bereits ein VPN besteht, kann zumindest zwischen parallel eingeschalteten Geräten wie im lokalen Netzwerk synchronisiert werden.

Disclaimer: als Entwickler von GeneralSync bin ich bei dem Thema befangen.

Auf den Screenshots ist Lightning bereits installiert und aktiv. Oben rechts in der Tab-Leiste gibt es daher die beiden Schaltflächen für Kalender und Aufgaben. Ein Klick auf die Kalenderschaltfläche sollte demnach den Kalender anzeigen (in Deinem Screenshot "Thunderbird.JPG": oben rechts in der Tab-Leiste, die Schaltfläche mit der Ziffer "7" in einem Kalender-Rahmen).

Alternativ kann der Kalender auch über das Menü geöffnet werden: "Termine und Aufgaben|Kalender".

Lightning ist also bereits korrekt eingerichtet. Allerdings kann Lightning selbst nicht direkt mit Android synchronisieren, sondern stellt nur den Kalender in Thunderbird bereit und bietet Schnittstellen für die Synchronisation mit einem Online-Dienst oder Server ("CalDAV").

Zum Austausch zwischen Thunderbird und Android hast Du prinzipiell drei Möglichkeiten:

• Thunderbird und Android jeweils mit einem Online-Dienst synchronisieren
• Thunderbird und Android jeweils mit einem eigenen Server synchronisieren
• Thunderbird und Android mit einem Tool wie GeneralSync direkt synchronisieren

Das für und wieder dieser Optionen wird im Lexikon-Artikel zur Synchronisation mit Smartphones genauer erläutert. Dort befinden sich auch weiterführende Links zu den jeweiligen Optionen.

Ich selbst nutze GeneralSync, bin als Entwickler dieses Tools aber natürlich befangen. Ein Vorteil ist dabei, dass alle Daten ausschließlich auf den eigenen Geräten bleiben, der Kalender also nicht ins Internet übertragen wird. Nach der einmaligen Einrichtung ist darüber hinaus kein ständiger Arbeitsaufwand notwendig, sofern sich Smartphone und PC zumindest gelegentlich gleichzeitig im selben Netzwerk befinden (z.B. WLAN).

Im Rahmen der Beta ist GeneralSync derzeit noch kostenlos nutzbar, darüber hinaus gibt es ein Video-Tutorial zur Synchronisation von Smartphone und Thunderbird. Das Video sollte sich durch Anklicken jederzeit pausieren lassen, wenn Du den Schritten direkt folgen willst. Bei Rückfragen zu GeneralSync stehe ich hier oder über den GeneralSync-Support zur Verfügung.