Kopano und S/MIME: Sei wer Du bist!

Kopano S/MIME: rote Karte für Hacker

E-Mail und Identität sind fest miteinander verknüpft. Woher weiß ich, dass eine E-Mail tatsächlich von dem kommt, dessen Namen ich im Absender sehe? Vor allem im geschäftlichen E-Mail-Verkehr ist dieser Nachweis wichtig. Doch wie stellt man das schnell und einfach an?

Was kann beim Mailen schon schief gehen?

Mit welchem Mailsystem auch immer man arbeitet, am Ende ist es SMTP, das Simple Mail Transfer Protocol, welches eine E-Mail zum Empfänger transportiert. Und der Name ist Programm. Es ist wirklich sehr einfach. Die folgenden 9 Zeilen sind es, in denen Voodoo komplett passiert. Mit einer Verbindung per Telnet auf den Port 25 eines offenen SMTP-Servers kann man dies probieren:

[1] MAIL FROM: von.mir@meinserver.de
[2] RCPT TO: zu.dir@deinserver.de
[3] DATA
[4] From: Mein Name <auch_ich@andererserver.de>
[5] To: Dein Name <auch_du@woauchimmer.de>
[6] Subject: Was auch immer
[7]
[8] Bin ich es wirklich?
[9] .

Die Zeile 1 teilt dem Server mit, wer man eigentlich ist. Diese Adresse sollte dem Mailserver bekannt sein. In der Zeile 2 wird die Empfängeradresse kundgetan. Im DATA-Block (Zeile 4 bis 9) wird nun das geschrieben, was ein E-Mal-Client am Ende anzeigt. Die Daten in Zeile 4 müssen nicht mit denen in Zeile 1 übereinstimmen, sie werden nicht einmal geprüft. Mit den Zeilen 5 und 2 verhält es sich analog. Hier ahnt man schon, was ausgenutzt werden kann.

Nun mag man sagen, dass ja SMTP-Server heute eine Authentifizierung verlangen und man solcherlei Betrug damit nicht mehr veranstalten kann, ohne aufzufliegen. Das stimmt nur bedingt. SMTP ist ein dezentrales System. Ich kann mir sehr schnell einen solchen Server aufsetzen und diesen beliebig konfigurieren. Die Zeile 1 obliegt dann vollkommen meiner Kontrolle. Gewiss werde ich damit irgendwann als Spammer geblockt – aber wann ist schon „irgendwann“?

Puh – Und nun?

Mit PGP und S/MIME gibt es zwei Standards für E-Mail-Verschlüsselung. In diesen Systemen steckt aber noch eine viel wichtigere Funktion: Das Nachweis der Identität des Absenders und der Originalität der E-Mail durch die digitale Signatur [1].

Ein Benutzer erhält bei beiden Verfahren einen öffentlichen und einen privaten Schlüssel in digitaler Form. Der öffentliche Schlüssel ist sozusagen der Clubausweis mit Foto und Fingerabdruck, der private Schlüssel sind das dazu passende Gesicht und der Finger. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können mit dem privaten Schlüssel – und zwar nur mit diesem – wieder lesbar gemacht werden und umgedreht. An die Daten kommt man also nur heran, wenn man entweder der mit dem Gesicht und dem Finger ist, oder wenn man den Clubausweis sieht.

Beim Signieren einer E-Mail wendet der Versender seinen privaten digitalen Schlüssel auf die E-Mail an. Dabei wird eine nur für eben diese E-Mail – also den oben gezeigten DATA-Block – passende Prüfsumme errechnet und mit dem Schlüssel verschlüsselt. Die E-Mail wird dann mit dem öffentlichen Schlüssel als Attachment versandt. Der Empfänger kann die Prüfsumme mit dem öffentlichen Schlüssel entschlüsseln und herausfinden, ob diese mit der von ihm selbst errechneten Prüfsumme übereinstimmt. Somit ist sichergestellt, dass die E-Mail von demjenigen versandt wurde, der in Besitz des privaten Schlüssels zum anhängenden öffentlichen Schlüssel ist. Im oben eingeführten Bild zeigt der Versender also mit seinem Gesicht, seinem Finger und seinem Clubausweis, das er derjenige ist, der auf dem Ausweis eingetragen wurde.

Was ist das für ein Club?

Für das etwas alberne Bild eines Clubausweises habe ich mich entscheiden, weil mehr noch nicht gesagt wurde. Den Ausweis kann nämlich so jeder herstellen. Voodoo passiert genau dann, wenn der Ausweis von einer höheren Institution, sagen wir von einem Land, ausgestellt wird. Dann wird daraus ein Personalausweis und das Vertrauen in den Ausweis wächst.

So funktioniert das mit S/MIME. Hier erhält der Benutzer anstelle des öffentlichen Schlüssels ein Zertifikat, in dem neben eben dem öffentlichen Schlüssel auch die Beglaubigungen von höherer Stelle bis hin zu einem Wurzelzertifikat eingetragen wird. Vertraut der Empfänger einer der beglaubigenden Organisationen, so ist die Echtheit des Versenders anzunehmen.

S/MIME-Zertifikate

Bei Kopano haben wir uns für die Arbeit mit S/MIME entschieden. Die strenge Hierarchie der Zertifikate passt sehr gut zu unserem Zielpublikum. Zertifikate werden über eine PKI (Public Key Infrastrcuture [2]) ausgestellt, verteilt und geprüft. Diese PKI kann man sich selbst aufbauen (komplex), beglaubigen lassen (teuer) oder man kauft ein Zertifikat bei einer öffentlichen Zertifizierungsstelle.

Die Zertifikate gibt es nicht nur in verschiedenen Geschmacksrichtungen (Globesign, Comodo, Trustwave und andere), sondern auch in unterschiedlichen Klassen. Diese sind nicht standardisiert [3], jedoch gilt: Je höher die Klasse, desto persönlich bekannter der Inhaber des Zertifikats. Ich denke, dass die Klasse 1, welche bei allen Anbietern die ich gefunden habe die E-Mail-Adresse verifiziert, ausreichend ist. Sie stellt sicher, dass die im oben genannten DATA-Block benutzte Absenderadresse passt.

Wie komme ich an ein Zertifikat?

Immer wieder habe ich gehört, dass der Kauf bei einem Reseller dem Kauf bei der Zertifizierungsstelle selbst vorzuziehen ist. Preis und Service passen hier besser zusammen, sagt man. Das sind aber gewiss alles sehr individuelle Erfahrungswerte.

Ein kostenfreies Zertifikat kann man zum Beispiel bei Comodo [4] bestellen. Ich habe mich letztendlich dafür entschieden, mein S/MIME-Zertifikat bei der PSW Group zu kaufen. Dies ist ein deutschsprachiges Unternehmen und ich habe den Geschäftsführer Christian Heutger früher schon einmal getroffen – Vertrauen zählt eben viel ;-).

Bei der PSW kann man Zertifikate verschiedener Anbieter kaufen. Auch hier setzte ich eher auf die Erfahrung anderer und entschied mich für ein Globesign-Zertifikat. Das haben bereits Kollegen von mir im Einsatz und deren Root-Zertifikat, welches für die finale Identitätsbestimmung notwendig ist, wurde bisher immer zuverlässig akzeptiert.

Identitätsnachweis

Der Prozess der Bestellung war recht einfach. Er beginnt auf der Website des Resellers, in meinem Falle also bei der PSW:

  1. Zertifikate auswählen
  2. Persönliche Daten, Daten für die Rechnungsstellung, korrekte E-Mail-Adresse und ein temporäres Passwort eintragen.
    WICHTIG: Die E-Mail-Adresse MUSS diejenige sein, die im Absender steht, wenn eine E-Mail das Unternehmen verlässt! Nutzt man hier einen Alias, so wird das Zertifikat nie greifen.
  3. Warten, bis der Auftrag akzeptiert wurde. Dies geschieht bei der PSW Group manuell ;-).
  4. Die Zertifizierungsstelle versendet an die angegebene E-Mail-Adresse einen Link.
    Class 1: Diese Mail hätte mich nicht erreicht, wenn es nicht meine E-Mail-Adresse gewesen wäre.
  5. Auf der verlinkten Website werde ich noch einmal nach dem temporären Passwort gefragt.
  6. Das eigentliche Zertifikatspasswort wird abgefragt.
  7. Das finale Zertifikat kann als PFX-File in einem ZIP-Archiv heruntergeladen werden. Per E-Mail erhielt ich einen weiteren Link hierzu, falls dieser Download fehlgeschlagen sein sollte.

Sehr wichtig ist nun, dass dieses Zertifikat nur in meinen Händen bleibt! Das PFX-File enthält sowohl meinen öffentlichen, als auch meinen privaten Schlüssel.

Zertifikat in den Mailclient einbinden

Je nach Mailclient funktioniert das Einbinden des Zertifikates auf eine andere Art und Weise. Bei Kopano haben wir uns dafür entschieden, nicht auf den Zertifikatsstore der jeweiligen Betriebssysteme zu vertrauen – Unser Client ist plattformunabhängig und das Handling wäre je nach „Welt“ zu unterschiedlich und kompex geworden. Somit kümmern wir uns komplett selbst um die Schlüssel.

Notwendig für die Nutzung von S/MIME ist ein aktiviertes S/MIME-Plugin [5][6]. In der DeskApp oder WebApp kann das Plugin unter Einstellungen → Plugins aktiviert werden.

Kopano: S/MIME-Plugin aktivieren

Ist das Plugin aktiv, so speichert Kopano die öffentlichen Zertifikate empfangener E-Mails automatisch. Diese sind wichtig, um verschlüsselte E-Mails zu versenden. Dann taucht in den Einstellungen auch die Registerkarte S/MIME auf. Hier wird das private Zertifikat – also das PFX-File – hochgeladen und mit dem beim Erstellen des Zertifikates vergebenen Passwort entsperrt. Außerdem kann man hier dieses Passwort ändern und eine Liste der gespeicherten Zertifikate einsehen.

Kopano: S/MIME-Plugin Einstellungen

Der Prozess des Signierens ist nun sehr einfach: Beim Erstellen einer neuen E-Mail tauchen sehr präsent zwei neue Buttons zum „Signieren“ und „Verschlüsseln“ auf. Diese machen exakt das, was sie versprechen. That‘s it.

Kopano: E-Mail verschlüsseln oder signieren

Abschluss und Weiterführendes

Ein langer Blog für einen simplen Button. E-Mails zu signieren ist viel einfacher als die Hintergründe zu verstehen ;-). Für letzteres empfehle ich auch einen Blog-Artikel auf unserem Kopano Blog [7], den meine Kollegen Bob und Mike geschrieben haben. Darin erklären sie auch, warum das Speichern der Zertifikate auf unserem Server ein guter Kompromiss zwischen 100%-iger Sicherheit und alltäglich geforderter Usability ist.

Wir werden unser S/MIME-Plugin noch weiter optimieren. Und ich freue mich über jede und jeden, der S/MIME mit unserem Plugin nutzt und Feedback dazu gibt!

[1] https://de.wikipedia.org/wiki/Digitale_Signatur
[2] https://de.wikipedia.org/wiki/Public-Key-Infrastruktur
[3] https://www.psw-group.de/smime/
[4] https://www.comodo.com/home/email-security/security-software.php
[5] https://kopano.com/produkte/email-security/
[6] https://download.kopano.io/community/smime:/
[7] https://kopano.com/smime-description/

6 Gedanken zu „Kopano und S/MIME: Sei wer Du bist!

  • 20. Juli 2017 um 15:14
    Permalink

    Hi Andreas,

    Danke für Deinen Artikel! Ich habe genau so ein (kostenloses) Zertifikat von Comodo und in Kopano eingefügt. „Sie haben ein valides Zertifikat, das zu Ihrem Account passt“. Wenn ich mit DeskApp oder WebApp eine signierte E-Mail an meinen Kopano- und Firmen-Account versende, ist alles prima.
    Dasselbe Zertifikat habe ich auf meinem iPhone für denselben Kopano-Account installiert. Absender-Adresse ist dieselbe wie oben. Wenn ich jetzt mit dem iPhone eine signierte E-Mail an meinen Kopano- und Firmen-Account sende, ist auf dem Firmen-Account alles gut „Die digitale Signatur ist vertrauenswürdig“, aber auf meinem Kopano-Account hat die E-Mail in DeskApp und WebApp den Status „Überprüfung mit der Zertifizierungsstelle ist fehlgeschlagen“.
    Jetzt habe ich meinen Kopano-Account in meinem Firmen-Outlook als Active-Sync Konto hinzugefügt. In Outlook wird die Signatur der E-Mail im Kopano-Account als gültig angezeigt.
    Was muss ich tun, damit auch im DeskApp und WebApp die E-Mail als „OK“ angezeigt wird? Löschen und wieder Anlegen des Accounts im iPhone hat nichts geändert.

    Viele Grüße,
    Hans-Jörg

    Antworten
    • 30. Juli 2017 um 22:12
      Permalink

      Moin Hanbs-Jörg,

      sorry für die späte Antwort – ich war im Urlaub. Deine Frage ist interessant, die kann ich so auch nicht beantworten. Stellst Du sie bitte einmal im Kopano Forum (Sektion: Plugins für die WebApp)? Wäre cool, wenn Du den Link zu Deinem Post hier postest, dann haben wir alle was von der Antwort ;-).

      Viele Grüße,

      Andreas

      Antworten
      • 26. September 2017 um 10:46
        Permalink

        Moin moin Andreas,

        inzwischen habe ich auch für die Firmen-E-Mail-Adresse ein Comodo Zertifikat in Outlook 2016 (das Programm) zum Testen eingerichtet. Damit passiert folgendes:
        Eine signierte E-Mail an mich@Firma und Kollege@Firma ist vertrauenswürdig. Dieselbe E-Mail an meinen Kopano-Server und mich@outlook.com ist nicht verifizierbar.
        Spannenderweise scheint Outlook (also das Programm) etwas nachzuladen, denn bei meinem Kollegen (Outlook 2016) gab es ebenfalls eine Warnung, der Zertifizierungspfad des Zertifikates war zuerst rot und nach ca. einer Minute dann grün, ohne dass er irgendwo auf „Vertrauen“ oder so geklickt hatte. Ich vermute, dass Outlook/Windows in der Zeit das Intermediate Certificate nachgeladen und installiert hat. Das muss ich nochmal an einem anderen PC testen.

        Gestern habe ich versucht, das Intermediate Certificate für „COMODO RSA Client Authentication and Secure Email CA“ in mein .P12 File mit OpenSSL einzubauen und dann E-Mails mit diesem Zertifikat zu signieren. Das neue .P12 File ist OK, es hat alles funktioniert, die E-Mail ist signiert, aber das Ergebnis (Überprüfung mit der Zertifizierungsstelle ist fehlgeschlagen) blieb das gleiche bei meinem Kopano und auch bei outlook.com.

        Ich kaspere deshalb auch seit letzter Woche mit dem Comodo-Support herum, das sollte eigentlich eine Lösung bringen, weil es bei outlook.com nicht funktioniert. So etwas ist ja leicht nachzustellen…

        Stay tuned,
        Hans-Jörg

        PS: Hier das komplette Popup, das angezeigt wird, wenn man in Kopano auf die Warnung klickt:
        ———-
        Die WebApp kann digitale Signaturen verifizieren. Eine erfolgreiche Verifizierung stellt sicher, dass die E-Mail nach dem Versand nicht verändert wurde und wirklich vom angegebenen Absender kommt.

        You are seeing this message because the verification of the digital signature has failed for this message.

        Was ist der Grund dafür?

        Der Prüfungsdienst der Zertifizierungsstelle, die das Zertifikat des Absenders signiert hat, ist nicht verfügbar. Deswegen konnte die Echtheit des Zertifikates nicht sichergestellt werden.

        Was kann ich machen?

        Sie können weiterarbeiten. Aber Sie sollten in Erinnerung behalten, das die Identität des Senders und die Echtheit der Nachricht nicht verifiziert werden konnten.

        Bitte kontaktieren Sie Ihre Supporthotline oder den Systemadministrator, wenn Sie sich unsicher sind.
        ———-

        Antworten
        • 26. September 2017 um 16:55
          Permalink

          Selbstgespräche sind ein Zeichen für psychische Labilität – (c) MausNet

          Irgendwie habe ich es jetzt hingekriegt, dass zumindest die E-Mails mit meinem ersten Problem funktionieren. Ich habe das Intermediate Certificate an meine beiden .p12 drangebastelt und nun meckert Kopano nicht mehr, wenn ich vom iPhone eine signierte E-Mail an Kopano sende.
          Bei outlook.com bleibt der Fehler.

          Das Procedere dazu war:
          – OpenSSL installieren und die Original-Zertifikate (das eigene X.509 und das Intermediate/Zwischenzertifizierungsstellenzertifikat) bereithalten
          Mein eigenes Zertifikat auseinanderrupfen:
          – openssl pkcs12 -in ich@domain.de.p12 -nocerts -out privateKey.pem
          – openssl pkcs12 -in ich@domain.de.p12 -clcerts -nokeys -out publicCert.pem
          Das Intermediate umwandeln:
          – openssl x509 -inform DER -in „COMODO RSA Client Authentication and Secure Email CA.cer“ -out COMODORSAClientAuthenticationandSecureEmailCA.pem
          Das Intermediate an den öffentlichen Teil meines Zertifikates anhängen:
          – type publicCert.pem COMODORSAClientAuthenticationandSecureEmailCA.pem >out.pem
          Öffentlichen und Privaten Teil wieder zusammenbasteln:
          – openssl pkcs12 -export -in out.pem -inkey privateKey.pem -out ich@domain.de.p12
          Das neue Zertifikat enthält nun das Intermediate und damit ist der Zertifizierungspfad für den Empfänger unterbrechungsfrei nachvollziehbar. Zertifikat in Kopano / iPhone / Outlook 2016 installieren und gut ist’s.

          Antworten
          • 27. September 2017 um 14:39
            Permalink

            Nochmal ich…
            Anscheinend hatte sich beim Export aus dem Firefox der Datenwurm an den beiden Zertifikaten zu schaffen gemacht – ein weiteres mit dem Internet Explorer angefordertes Zertifikat funktioniert überall – nur nicht bei outlook.com.
            Also: Bei Zertifikatsanforderungen lieber den IE verwenden…

          • 2. Oktober 2017 um 10:40
            Permalink

            Moin Hans-Jörg,

            kannst Du das bitte einmal in das Kopano Forum (Sektion: Plugins für die WebApp) posten? Eigentlich betrifft es unser Plugin nur, wenn wir es nicht richtig erkennen. Das Signieren sollte einwandfrei funktionieren. der OCSP-Mechanismus macht jedoch vielen Anbietern zu schaffen – vielleicht ist das auch bei outlook.com der Fall? Die Jungs im Forum haben da am ehesten eine passende Aussage parat.

            Danke,

            Andreas

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.