Beiträge von andihoe

Hallo,

nein, leider hat sich nichts in dieser Richtung getan. Es ist immer noch kein Mailclient in Sicht der auch Zeitstempel auswerten könnte und deshalb auch keine Software die sowas in S/MIME integriert. Es bleibt also weiterhin nichts anderes übrig als dem eh schon verständnislos blickenden Endnutzer zu erklären warum die ach so sichere S/MIME e-Mail nach einiger Zeit auf einmal mit einer kreischenden Warnung markiert wird und normale e-Mails nicht
Eine RFC die sowas regeln würde hab ich ebenfalls noch nicht gesehen.

Sorry

Andreas

Hallo

vielleicht wirklich mal prüfen ob "deine" Web.de root CAs in Ordnung sind. Die md5 Prüfsummen meiner funktionierenden sind:

2a86ebeb194ee5c6d2b3ef2ca92da8cc webderoot.der

43ccb953e18f3dbe0159d615e8c478ec webdeca.der

Wenn sich das unterscheidet ...

Gruß

Andi

Wenn du auf der Webseite ein Eingabefeld findest in welches der Zertifikat-Request kopiert werden soll/muß dann gilt Aussage 1 (der private Schlüssel verläßt deine Maschine nicht). Wenn du nach Angabe von ein paar Daten eine Datei mit Zertifikat und privatem Schlüssel runterladen kannst weiß nur der Aussteller was alles mit deinem privaten Schlüssel passiert. Falls nach der Angabe der Daten ein Zertifikat/Key Paar in deinem persönlichen Zertifikatspeicher im Browser liegt wurden die Browserfunktionen benutzt und der Schlüssel hat deinen PC auch nicht verlassen solange keine Sicherheitslücke im Browser ausgenutzt wurde.

Die erste ist die sicherste Methode, die dritte akzeptabel, die zweite sollte man vermeiden.

Gruß

Andi

Nein

TLS/SSL ist eine Absicherung der Verbindung zwischen dir bzw. deiner Station und dem nächsten Mailserver, i.d.R. der Server deines Mail-Providers. Damit ist TLS/SSL sinnvoll um z.B. deine Zugangsdaten zu schützen, nicht aber den Inhalt der Mail, da diese von deinem Mailprovider i.d.R. ohne TLS/SSL zum Ziel weiter geleitet wird. Um den Inhalt zu sichern musst du also noch die Mail verschlüsseln, Stichwort dazu ist S/MIME oder PGP.

Gruß

Andi

Zitat von "Peter_Lehmann"

Hallo andihoe,

Ja, das könnte man annehmen - ist allerdings Blödsinn (sorry: => "nicht ganz zutreffend").

War wohl nicht eindeutig von mir formuliert: Mit "fest eingebrannt" ist die Tatsache gemeint das die rootCA nicht in einer vom Endnutzer änderbaren Datei vorliegen, sondern eben im Executeable enthalten sind. Die Vertrauenseinstellung ist natürlich wie beschrieben änderbar und der Grund warum diese CAs "mitgeliefert" ist mir auch klar. Das "Fälschung erschweren" bezieht sich auch nur auf den Auslieferungszustand bzw. die enthaltenen root CAs und nicht auf Zertifikate oder der Vertrauenskette an und für sich.

Gruß

Andreas

Bei Thunderbird (und Firefox BTW) sind die mitgelieferten root CAs wohl "fest eingebrannt" damit eine Fälschung erschwert wird. Allerdings kann den root CAs das "Vertrauen" entzogen werden, was auch bei DigiNotar passiert ist. Zu sehen wenn man die CA Zertifikate anklickt und "Vertrauen bearbeiten" auswählt, es sollte keiner der drei Punkte mehr aktiviert sein. In dieser Form werden übrigens auch die eingebauten CAs behandelt wenn sie vom Benutzer gelöscht werden.

Hallo

ich bin auf der Suche nach einer CA die Firmen validierte Zertifikate (Class 2) ohne den Zwang zur Ausweis-Kopie für alle Zertifikate ausgibt. Das einzige was ich gefunden habe wäre Comodo EPKI aber Comodo ist nicht gerade erste Wahl
Hintergrund ist das Bestreben alle validierten geschäftlichen Mails digital zu signieren um die Zugehörigkeit zur Firmendomäne zu bestätigen. Das hantieren mit Personalausweisen außer für den Firmenbeauftragten der die Zertifikate verwaltet ist nicht erwünscht, da es datenschutzrechtlich zumindest bedenklich ist.

Bin dankbar für alle Hinweise

Gruß

Andreas

Was war nochmal die Frage?
Wir hoppeln hier munter durch Vertraulichkeit, Anonymität und Authentizität gewürzt mit Fälschungssicherheit. Was wird den nun benötigt und in welchem Umfeld. Falls es noch nicht klar geworden ist: Manche dieser Sachen schließen sich auch gegenseitig aus...

Richtig. Mail ist store-and-forward d.h. eine mail läuft möglicherweise über viele Server bis sie ihr Ziel erreicht hat. Mit SMTP-TLS sicherst du nur die Strecke bis zu dem Eingangsrelay deines Providers. Dort liegt die Mail dann im Klartext vor. Danach wird sie weiter geleitet, entweder wieder über SMTP-TLS oder auch (eher) nur über SMTP bis zum Provider des Empfängers. Dort liegt die e-Mail als Klartext in der Mailbox bis der Empfänger die Mail z.B. per POP3-SSL abholt.

Mit S/MIME oder PGP interessiert dich das ganze nur deshalb, weil du zum Provider trotzdem TLS/SSL verwenden solltest, um deine Zugangsdaten zu schützen. Der Inhalt ist damit auf dem ganzen Weg bis zum Empfänger nicht einsehbar und auch nicht von Geheimdiensten zu knacken.
Mailprovider müssen übrigens seit einiger Zeit eine Schnittstelle für Behörden-Zugriff vorhalten:
http://de.wikipedia.org/wiki/E-Mail-%C3%9Cberwachung

So ein Mist, der Fehler besteht ja immer noch (Thunderbird 3.1.10). Ich bin darüber gestolpert weil Thunderbird zur Verschlüsselung das falsche Zertifikat verwendet. Ich hab zwei Zertifikate von Trustcenter.de mit gleichem Namen, aber unterschiedlicher Mailadresse (Private und Firmenadresse). Wenn ich nun aus der Firma eine verschlüsselte Mail an mein Privataccount schreibe funktioniert es nur wenn ich im Firmenaccount *nicht* das Trustcenter.de Zertifikat installiert habe. Sobald ich auch in der Firma das TC Zertifikat+Key installiert habe scheint er dieses zu verwenden (obwohl die Mailadresse dafür falsch ist) und zuhause kann ich die Mail natürlich nicht mehr entschlüsseln.

Also bei solchen Fehlern wundert es mich nicht das verschlüsselte Mails so gut wie nie verwendet werden.

Vielleicht nochmal als einfache Merkhilfe:
- Derjenige der will das er verschlüsselte e-Mail erhält muß aktiv werden indem er sich ein Zertifikat/Key besorgt und das Zertifikat an jede verschickte Mail dranhängt. D.h. der Empfänger bietet an, der Sender muß es nutzen damit es funktioniert.
- Andere Verfahren wie TLS/POP3S VPN etc. decken nur ein Teil der Strecke ab, dazwischen sind Lücken in denen die e-Mail wie bisher auch als Klartext vorliegt.
- Sicherheit ist niemals ein "no-Brainer". Man kann ja auch nicht autofahren ohne mitzudenken weil man ja ABS zur Sicherheit hat (obwohl es bei manchen so aussieht als würden sie es versuchen

Gruß

Andreas

Bedeutet das nun Insider-Wissen oder ist es lediglich eine Vermutungsfrage?

Welche Trustcenter wären den wirklich vertrauenswürdig?

D-Trust (Bundesdruckerei):
Klingt zwar gut, soweit ich weiß sind allerdings die Root-CAs nicht wirklich weit verbreitet.

S-Trust (Sparkassen):
Zumindest in TB auch keine Root-CA vorhanden, oder wird das über die "Kooperation" mit VeriSign geregelt?

Telesec(dt. Telekom):
Soweit ich sehen keine "Softtoken", sondern ausschließlich QS mit Karte oder eigene PKI für ganz große Firmen.

Vieleicht weiß ja jemand was darüber, vom Wohnort her würde ich darauf tippen das zumindest ein Spezialist im Forum bei Nummer 3 arbeitet, oder?

Aber Hallo!
Ich habe nirgends behauptet das ich das Beibehalten der Verschlüsselung bei lokal gespeicherten Mails als sinnvoll betrachte. Es war mir lediglich nicht klar warum immer die Anhänge als Argument benutzt werden, dort funktioniert es ja mit der "Entschlüsselung". Das Argument "Starke" Geheimhaltung ist auch nicht von mir sondern wird immer wieder als Argument *für* den momentanen Zustand verwendet. Sehr schön wäre ein Funktion ähnlich dem "Anhang abtrenne" um die verschlüsselung lokal aufzuheben.
Wie bereits von anderen erwähnt gibt es für das Umfeld "zentral verwaltete Netze" aka. Firmen, Gateway-Lösungen die das Ganze recht schmerzfrei und bei richtiger Handhabung auch ausreichend sicher umsetzten, im privaten Umfeld d.h. für Einzelplatz gibt es das eher nicht. Das ist sicher auch mit ein Grund warum im Bereich der privaten Mailkommunikation so gut wie keiner verschlüsselt oder auch nur signiert. Es ist schlicht zuviel technisches Wissen erforderlich.

Also bezüglich Anhängen versteh ich dein Problem nicht. Wenn ich "speichern unter" auswähle und das Ding auf die Platte schreibe ist es bei mir nicht mehr verschlüsselt (S/MIME, TB 3.1.9). Mit der Volltextsuche muß ich dir allerdings recht geben. Aber wie der Fachmann schon dargelegt hat: "Starke" Geheimhaltung und Komfort schließen sich aus.

Nicht ganz, es ist eigentlich so das man das "Masterpasswort" immer verwenden sollte um die eigentlich zu schützenden Konfigurations Daten (Zugangsdaten mehrerer Mailkonten, private Keys etc.) sicher zu verwahren.

Gruß

Andreas

Soweit ich das sehe hat das nichts mit fehlender root CAs zu tun sondern es scheint ein Link in der Mail zu sein der per HTTPS auf eine URL verzweigt deren Servername (newsletter.westfalia.de) nicht im Zertifikat hinterlegt ist.
Lösung: Beim Verantwortlichen von diesem Newsletter nachfragen warum überhaupt HTTPS in der URL angegeben wird...

Hallo

Danke für die Lorbeeren

Tatsächlich hat unser Problem zwei Seiten:
- Das Einbringen des Zeitstempel: Da wir auf dem Mailgateway signieren (ja nahezu alle Mails und die verwendete Software in Java geschrieben ist, wäre dieses Problem lösbar. Ein Fragezeichen steht wie gesagt bei der sauberen S/MIME Integration, wobei ein Entwickler sich bereits mit "machbar" gemeldet hat, da S/MIME ja ebenfalls auf x509 basiert.
- Das Überprüfen im Mailclient: Hier kommt z.B. TB ins Spiel, wobei die Überprüfung deutlich einfacher sein sollte als das einbringen, da ja im Prinzip nur folgendes notwendig wäre
1.) check ob Timestamp CA vertraut bzw. gültig
2.) check ob Signatur Zertifikat zum Zeitpunkt "Timestamp" gültig war

Desweiteren wäre es auch interessant zu wissen wie andere KMU mit diesem Problem umgehen oder ob es eher auf der Liste "Warum wir kein S/MIME verwenden" steht...

Gruß

Andreas

Nochmal zur Erklärung: Es geht nicht um die "qualifizierte elektronische Signatur" nach dt. Recht sondern lediglich um das Einbringen eines signierten Zeitstempels welcher z.B. auch recht einfach per HTTP von einer CA Stelle mit Zeitstempel Server bezogen werden kann. Damit könnte das Problem entschärft werden das die Anwender mit wechselndem Status Ihrer Mails konfrontiert werden. Wir sind z.B. dabei unsere Anwender darauf zu trimmen jegliche Fehlermeldung die mit Signatur/Verschlüsselung zu tun hat an den Support zu melden und das schlimmste was dabei vorkommen kann ist das wir als Hilfestellung "macht nichts, bitte Meldung ignorieren" anbieten müssen

Hallo & Danke für die Antwort

meine Idee war ein Verfahren wie es bei Code-Signing angewendet wird. Wir signieren z.B. Java Applets mit einem gekauften Zertifikat/Key und versehen die Applets zusätzlich mit einem Zeitstempel welcher von diversen CAs per Internet bezogen werden kann siehe z.B. http://mindprod.com/jgloss/timestamp.html. Damit wird auch nach Ablauf des Zertifikates die Code-Signatur als "gültig zum Zeitpunkt der Erstellung" erkannt, da ansonsten die Software nach Ablauf des Zertifikates nicht merh verwendbar wäre. Dies gilt zumindest solange bis die root-CA des Zeitstempels abgelaufen ist also i.d.R deutlich länger. Das System der Zeitstempel ist meiner Meinung nach auch unabhängig von dem deutschen Monstrum QS. Es wäre jedenfalls sehr hilfreich die üblichen Mail Anwender die wir mühsam darauf trimmen Warnmeldungen zu beachten nicht noch mehr zu verwirren.
Die Frage bleibt allerdings ob in den S/MIME RFCs Platz für Zeitstempel ist.

Gruß

Andreas

Hallo

wir haben vor einiger Zeit mit S/MIME im Firmenumfeld angefangen und sind dabei auf das Problem gestoßen, daß
korrekt signierte Mails nach Ablauf des verwendeten Zertifikates beim Empfänger als "ungültigt signiert" angezeigt werden. Da wir natürlich unserer Anwender darauf trimmen auf solche Dinge zu achten, die Signatur aber eigentlich gültig ist bzw. zumindest war, ist es schon sehr unschön.
Die Lösung wären wohl Zeitstempel wie sie z.B. beim Code-Signing oder Qualifizierten Signaturen Anwendung finden (RFC 3161) womit sich die "Gültigkeit" zum Zeitpunkt des Signierens ermitteln läßt. Allerdings habe ich keinerlei Hinweise auf Zeitstempel im Zusammenhang mit S/MIME gefunden
Ich nehme an das TB also nicht in der Lage ist Zeitstempel auszuwerten, aber weiß jemand Bescheid ob es mit S/MIME überhaupt möglich wäre ohne Verwirrung zu stiften.

Besten Dank für Hinweise

Andreas