Beiträge von Volker_

Zitat von Tom1234

Hmm... und ein S/MIme Zertifilkat ohne CA - also nur Benutzerzertifikat (.p12 Datei) nimmt Thunderbird auch nicht?

Das Benutzerzertifikat (.p12 Datei) enthält den privaten Schlüssel und das öffentliche X.509-Zertifikat, das von einer öffentlichen Zertifizierungsstelle (CA) zertifiziert sein muss, sonst kann es von Thunderbird nicht verifiziert werden, es ist nicht vertrauenswürdig.

Unter windows braucht das Benutzerzertifikat (.p12 Datei) nicht von einer öffentlichen Zertifizierungsstelle (CA) zertifiziert zu sein, es kann selbstsigniert sein.

Zitat von Tom1234

Ich habe mal irgendwo gelesen, dass man zum Mailen nicht unbedingt eine CA braucht, - stimmt das?

Das Zertifikat der öffentlichen Zertifizierungsstelle (CA) muss aber als Stammzertifikat im Zertifikatsspeicher von Thunderbird vorhanden sein, damit beim Signieren und Entschlüsseln von E-Mails das Benutzerzertifikat und beim Verschlüsseln und verifizieren von E-Mails das öffentliche X.509-Zertifikat von Thunderbird verifiziert werden kann.

Zitat von Tom1234

Was kann ich tun, damit ich ein S/MIMe (Benutzer-)Zertifikat in Thunderbird verwenden kann?
Ohne "echte" Ausstellungsbehörde funktioniert die Signierung/Verschlüsselung nicht?

Richtig.

Zitat von Tom1234

Könnt ihr mir bitte meine Codezeilen korrigieren, dass Thunderbird mir wieder die Mails verschlüsseln lässt?
(Vielleicht ohne CA-Ausstellerzertikat und nur Benutzer-Zertifikat?)

Verwende z.B. die E-Mail-Programme von MS.

mfg Volker

Hallo,

soweit mit bekannt, akzeptiert Thunderbird keine selbstsignierte X.509-Zertifikate (ca.crt, cert.csr).

Es muss immer eine öffentliche Zertifizierungsstelle (CA) als Stammzertifikat darüber existieren. Die Option -CA verhält sich wie eine "mini CA". Möglicherweise fehlen in der openssl.conf noch Optionen wie keyUsage und extendedKeyUsage.

Dagegen können selbstsignierte X.509-Zertifikate problemlos in den Zertifikatsspeicher von Windows importiert werden, auch als Stammzertifikat. Die Windows E-Mail-Programme akzeptieren dies.

mfg Volker

Zitat von Solaris

Nein, MDC ist nicht überflüssig. Es schützt selbst dann, wenn der MDC vom Angreifer entfernt wurde, weil GnuPG und Enigmail in den neuen Versionen dann die Entschlüsselung der E-Mail hart verweigern.

Ich muss nochmal nachhaken.
In efail-attack-paper.pdf, Kapitel 5.2 wird der Fall beschrieben, dass ein Angreifer den Ciphertext modifiziert aber den MDC unverändert lässt.
Prüft die neue GnuPG Version 2.2.8 nur auf das Vorhandensein von MDC, entschlüsselt den modifizierten Ciphertext, um dann festzustellen, dass der modifizierte Klartext nicht zum MDC passt?

mfg Volker

Zitat von Solaris

Nur verstehe ich dann den Rest des Einwandes nicht. In dem Moment, in dem der Mailclient und damit der Benutzer bemerkt, dass die erwartete Signatur fehlt oder gebrochen wurde, ist der entschlüsselte Text bereits an den Angreifer versendet worden.

Man kann im besten Fall bemerken, dass man angegriffen wurde. Der Angriff ist zu diesem Zeitpunkt aber schon abgeschlossen und der Angreifer am Ziel.

Dass der Angreifer den Klartext erhält, habe ich auch nicht bestritten.

Mein Einwand bezieht sich darauf, dass durch die fehlende Signatur der E-Mail Empfänger gewarnt wird. Er ist angegriffen worden und kann sich darauf einstellen.

Im übrigen kann auch der MDC vom Angreifer aus der E-Mail entfernt werden, sodass das E-Mail Programm des Empfängers keine Prüfung vornehmen kann, siehe Kapitel 5.2.

mfg Volker

Zitat von Solaris

Eine verschlüsselte und signierte Nachricht muss zunächst entschlüsselt werden, bevor die Signatur überprüft werden kann. Dann ist es im Fall von Efail bereits zu spät. Mit dem Entschlüsseln durch den E-Mailclient wird die Nachricht bereits an den Angreifer gesendet.

Das ist korrekt.
Aber die Signatur muss vom Angreifer aus der E-Mail entfernt werden, aufgrund des modifizierten Ciphertextes. Ein aufmerksamer Empfänger bemerkt dies, denn er hat eine Signatur erwartet.

Nachzulesen in efail-attack-paper.pdf, Kapitel 4.2, Abschnitt "Meaningless signatures"

Vielleicht ist doch PGP/INLINE sicherer, da i.d.R. kein Automatismus im E-Mail Programm abläuft.

mfg Volker

Zitat von graba

Hallo,

zur Information: Verschlüsselung - GnuPG verschärft Integritäts-Checks E-Mail [heise/security]

Hallo,

Zitat aus dem o.a. Link:
Als Konsequenz aus Efail verschärft GnuPG jetzt den Umgang mit den Modification Detection Codes (MDC).

Naja, irgendwie wird MDC überschätzt. Wenn eine Nachricht NUR verschlüsselt wird, dann macht MDC Sinn.

Wird dagegen eine Nachricht signiert & verschlüsselt, dann ist wohl MDC überflüssig.

Hier ein Auszug aus der Spezifikation OpenPGP RFC 4880, Kapitel 5.13, Abschnitt "NON-NORMATIVE EXPLANATION":

The MDC system, as packets 18 and 19 are called, were created to provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.

mfg Volker

Hallo,

Es gibt bereits Server die ECDSA anbieten.

Beispielsweise bietet Wikipedia ( https://de.wikipedia.org/) ECC an.

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (TLS1.0)
X.509-Zertifikat: EC 256 bits / SHA256withRSA

Also elliptische Kurven sowohl für den geheimen Schlüsselaustausch als auch für die Authentifizierung.

mfg Volker

Hallo,

möglicherweise akzeptiert Thunderbird Mail keine selbstsignierten X.509-Zertifikate. Es muss immer eine Zertifizierungsstelle (CA) darüber existieren. Mich wundert nur, dass das früher mal funktioniert haben sollte?

mfg Volker

Gibt es denn Server die ECDSA anbieten?

Beispielsweise liefert De-Mail von der Telekom maximal die Cipher Suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp384r1 (TLS1.2).

Also elliptische Kurven nur für den geheimen Schlüsselaustausch.

mfg Volker

Edit: Ich habe deinen folgenden inhaltlich identischen Beitrag gelöscht. graba, Gl.-Mod.

Zitat von SusiTux

Hallo Volker,

ich habe gestern Abend noch ein Zertifikat erstellt. Wie erwartet enthält es kein "Stammzertifikat" sondern lediglich die Angaben zum Herausgeber und dessen Unterschrift...

Möglicherweise bezieht das Kommando "openssl x509 -in Test.crt -noout -text" nicht alle Zertifikate im Zertifizierungspfad ein oder Test.crt besteht wirklich nur aus dem Zertifikat von "Subject"? Ich bin selbst im Zweifel.

Meine Vorgehensweise nach dem Empfang einer digital signierten E-Mail (S/MIME) in Outlook Express, deren Stamm- und Zwischenzertifikat nicht im Zertifikatsspeicher vorhanden und auch nicht öffentlich verfügbar sind, ist die:

(1) Digitale ID anzeigen -> Zertifizierungspfad -> Stamm- und Zwischenzertifikat jeweils anzeigen und in eine Datei kopieren (Base-64-kodiert .CER).

(2) Stamm- und Zwischenzertifikat in den Zertifikatsspeicher von Windows importieren.

(3) Das gleiche Ergebnis erhält man, wenn im "Sicheren Quelltext" der E-Mail die Base-64-kodierte Anlage als Datei "smime.p7s" gespeichert wird. Nach dem Öffnen können dann explizit Stamm- und Zwischenzertifikat in eine Datei gespeichert werden.

Das kann ich mir nur so erklären, dass Stamm- und Zwischenzertifikat in "smime.p7s" bereits mitgeliefert werden.

mfg Volker

Zitat von SusiTux

Es ist funktioniert doch so, dass die Echtheit des Zertifikats einer Person durch die Signatur des Ausstellers bestätigt wird.Dass nun nun auch die Signatur dieses Ausstellers korrekt ist, wird durch den öffentlichen Schlüssel des Ausstellers überprüft. Dieser ist wiederum Teil eines Zertifikats mit der Signatur eines Ausstellers. So geht es weiter, bis hinauf zur Root-CA als der obersten Zertifizierungsstelle.

Das ist richtig. Die Korrektheit des Signaturzertifikats wird in der Kette bis zum Stammzertifikat geprüft. Damit ist das Signaturzertifikat aber noch nicht vertrauenswürdig. Erst wenn das Stammzertifikat auch im Zertifikatsspeicher für vertrauenswürdige Stammzertifizierungsstellen vorliegt, wird der Vertrauensstatus des Ausstellers übernommen und das Signaturzertifikat als vertrauenswürdig eingestuft.

Übrigends handhabt Outlook Express den Vertrauensstatus nicht so streng wie Thunderbird. Das Signaturzertifikat kann auch explizit im Adressbuch als vertrauenswürdig eingestuft werden, ohne dass das Stammzertifikat importiert werden muss.

mfg Volker

Zitat von SusiTux

Kann es sein, dass dieses Stammzertifikat bereits vorhanden war? Der TB bringt ja ebenfalls einen ganze Reihe bekannter CAs mit.

Gruß

Susanne

Hallo,

nein, i.d.R. wird mit dem Signaturzertifikat die ganze Kette bis zum Stammzertifikat mitgeliefert, unabhängig davon, ob das Stammzertifikat bereits im Zertifikatsspeicher vorliegt. Daher kann das Stammzertifikat nachträglich in Thunderbird importiert werden und das Vertrauen ausgesprochen werden.

Zumindestens mit Outlook Express unter Windows funktioniert das so.

mfg Volker

Hallo,

die Vorgehensweise kann ich nur für Outlook Express unter Windows beschreiben:

Liegt eine E-Mail vor, die vom Absender digital signiert ist (S/MIME digital signiert), dann kann das Signaturzertifikat mit der Schlüsselverwendung "Sichere E-Mail" i.d.R. auch zum Verschlüsseln verwendet werden. Es entspricht dem Zertifikat des Absenders.

Das Signaturzertifikat kann in Outlook Express angezeigt werden. Unter dem Zertifizierungspfad ist dann die Kette bis zum Stammzertifikat zu sehen. Das Stammzertifikat kann angezeigt und in eine Datei (.cer), Base-64-codiert, kopiert werden. Diese Datei (.pem) kann dann als Stammzertifikat in Thunderbird importiert werden.

mfg Volker

Hallo,

wenn das X.509-Zertifikat (S/MIME) des Empfängers kein selbstsigniertes ist, dann kann doch aus dem Zertifizierungspfad das Stammzertifikat extrahiert und in Thunderbird importiert werden.

mfg Volker

Hallo,

das PGP Plugin (Firefox, Chrome) von Mailvelope wurde bereits für De-Mail eingeführt.

Sowohl Schlüsselerzeugung/Import als auch unverschlüsselte/entschlüsselte Nachrichten werden im Web-Portal des E-Mail Provider im Bereich des Sicherheitshintergrundes (Wasserzeichen, ein stilisiertes Schloss) angezeigt, vermutlich inline (HTML5 sandboxed Iframe).

Ob sichergestellt ist, dass weder der E-Mail Provider, noch Geheimdienste und Ermittlungsbehörden Zugriff auf die Daten im Bereich des Sicherheitshintergrundes haben, bleibt offen.

Meine diesbezügliche Frage an Mailvelope ergab nur als Antwort, dass dieser Bereich vom E-Mail Provider isoliert ist.

Das Schlüsselpaar wird lokal im Firefox-Profil (store.json) gespeichert.

mfg Volker

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
* Thunderbird-Version: 12.0.1 und 24.2.0
* Betriebssystem + Version: Windows XP
* Kontenart (POP / IMAP): POP
* Postfachanbieter (z.B. GMX): Telekom
* S/MIME oder PGP: S/MIME

Mit Outlook/Outlook Express unter Windows XP ist S/MIME möglich, wenn mein selbstsigniertes X.509-Zertifikat (Inhaber = Aussteller) auch als Stammzertifikat importiert wird. Das Zertifikat und der P12-Container wurden mit OpenSSL erzeugt. Thunderbird verweigert den Import als Stammzertifikat, da es kein Zertifikat für eine Zertifizierungsstelle ist.

Der Abschnitt [ usr_cert ] in der Konfigurationsdatei openssl.cfg für das User-Zertifikat:

basicConstraints=CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = emailProtection

Erzeuge ich dagegen zusätzlich ein selbstsigniertes X.509-Zertifikat für eine Zertifizierungsstelle (CA) mit dem gleichen Inhaber wie im User-Zertifikat, dann kann es zwar als Stammzertifikat importiert werden, aber der danach importierte P12-Container (Ihre Zertifikate) zum User-Zertifikat kann aus unbekannten Gründen nicht verifiziert werden.

Der Abschnitt [ v3_ca ] in der Konfigurationsdatei openssl.cfg für CA:

basicConstraints = CA:true

Was mache ich falsch?

mfg Volker