EMails auf dem Relay S/MIME signieren

[Sven Hartge]

Hallo!

Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
(hoffentlich) ist.

Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
"Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
weil du dein Passwort nicht geändert hast", etc.) an Benutzer
verschickt, die ich gerne cryptographisch signiert wissen möchte.

Nun ist es leider so, dass die gegebene Software dies nicht selbst kann
und es auch nur schwer bis unmöglich ist, dies einzubauen.

Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
komplette Konfiguration von allen beteiligten Komponenten. Also die
Idee, dass die Software ihre Mails über eine entsprechend dafür
bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen wird.

Soweit die grobe Idee.

In meinem präferierten MTA Exim sollte sich das nicht zu schwer
einbauen lassen, ein manual_router und ein pipe_transport dürften
reichen.

Auch das Programm, in welches die zu signierende Mail dann hinein
gepipet wird, kann ich durchaus selbst entwickeln, aber gerade bei
Crypto-Kram wäre es natürlichn schöner, wenn man etwas nehmen könnte, wo
vielleicht schon mal mehrere Leute drüber geschaut haben.

Hier findet sich für Postfix eine Idee für soetwas:
http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime

Aber ... Shell-Script? Brrr...

Viel mehr brauchbare Ergebnisse haben meine Suchen bisher nicht ergeben.
Vielleicht hat ja jemand einen Zaunpfahl o.ä. für mich.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

[Juergen P. Meier]

Sven Hartge <sh-...@svenhartge.de>:

> Nun ist es leider so, dass die gegebene Software dies nicht selbst kann
> und es auch nur schwer bis unmöglich ist, dies einzubauen.
>
> Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
> komplette Konfiguration von allen beteiligten Komponenten. Also die
> Idee, dass die Software ihre Mails über eine entsprechend dafür
> bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
> Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen wird.
>
> Soweit die grobe Idee.
>
> In meinem präferierten MTA Exim sollte sich das nicht zu schwer
> einbauen lassen, ein manual_router und ein pipe_transport dürften
> reichen.
>
> Auch das Programm, in welches die zu signierende Mail dann hinein
> gepipet wird, kann ich durchaus selbst entwickeln, aber gerade bei
> Crypto-Kram wäre es natürlichn schöner, wenn man etwas nehmen könnte, wo
> vielleicht schon mal mehrere Leute drüber geschaut haben.

openssl

> Hier findet sich für Postfix eine Idee für soetwas:
> http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime
>
> Aber ... Shell-Script? Brrr...

Warum nicht?

> Viel mehr brauchbare Ergebnisse haben meine Suchen bisher nicht ergeben.
> Vielleicht hat ja jemand einen Zaunpfahl o.ä. für mich.

openssl smime help
man smime

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>(hoffentlich) ist.
>
>Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
>"Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
>weil du dein Passwort nicht geändert hast", etc.) an Benutzer
>verschickt, die ich gerne cryptographisch signiert wissen möchte.
>
>Nun ist es leider so, dass die gegebene Software dies nicht selbst kann
>und es auch nur schwer bis unmöglich ist, dies einzubauen.
>
>Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
>komplette Konfiguration von allen beteiligten Komponenten. Also die
>Idee, dass die Software ihre Mails über eine entsprechend dafür
>bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
>Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen wird.

Du bist Dir bewusst dass Du damit dann im Zweifelsfall kryptografisch
signierte Phishingmails und kryptografisch signierte Malware
versendest?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Michael Ströder]

Marc Haber wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>> (hoffentlich) ist.
>>
>> Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
>> "Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
>> weil du dein Passwort nicht geändert hast", etc.) an Benutzer
>> verschickt, die ich gerne cryptographisch signiert wissen möchte.
>>
>> Nun ist es leider so, dass die gegebene Software dies nicht selbst kann
>> und es auch nur schwer bis unmöglich ist, dies einzubauen.
>>
>> Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
>> komplette Konfiguration von allen beteiligten Komponenten. Also die
>> Idee, dass die Software ihre Mails über eine entsprechend dafür
>> bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
>> Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen wird.
>
> Du bist Dir bewusst dass Du damit dann im Zweifelsfall kryptografisch
> signierte Phishingmails und kryptografisch signierte Malware
> versendest?

Man muss ja nicht per se alles signieren.

Ciao, Michael.

[Arno Welzel]

Am 2015-06-22 um 23:54 schrieb Sven Hartge:

> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
> (hoffentlich) ist.
>
> Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
> "Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
> weil du dein Passwort nicht geändert hast", etc.) an Benutzer
> verschickt, die ich gerne cryptographisch signiert wissen möchte.

Und warum? Also welches Problem wird damit gelöst?

[...]

> In meinem präferierten MTA Exim sollte sich das nicht zu schwer
> einbauen lassen, ein manual_router und ein pipe_transport dürften
> reichen.
>
> Auch das Programm, in welches die zu signierende Mail dann hinein
> gepipet wird, kann ich durchaus selbst entwickeln, aber gerade bei
> Crypto-Kram wäre es natürlichn schöner, wenn man etwas nehmen könnte, wo
> vielleicht schon mal mehrere Leute drüber geschaut haben.
>
> Hier findet sich für Postfix eine Idee für soetwas:
> http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime
>
> Aber ... Shell-Script? Brrr...

Warum? Das ist doch für einen Mailserver genau das Richtige. Oder willst
Du jede Mail in einer GUI von Hand signieren?

Ich frage mich aber trotzdem immer noch, welches Problem Du damit lösen
willst, ausgehende Mails von einer Software automatisch signieren zu lassen.



--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[Marc Haber]

Die Auswahl stelle ich mir allerdings eher schwierig vor.

[Michael Ströder]

Marc Haber wrote:
> Michael Ströder <mic...@stroeder.com> wrote:
>> Marc Haber wrote:
>>> Sven Hartge <sh-...@svenhartge.de> wrote:
>>>> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>>>> (hoffentlich) ist.
>>>>
>>>> Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
>>>> "Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
>>>> weil du dein Passwort nicht geändert hast", etc.) an Benutzer
>>>> verschickt, die ich gerne cryptographisch signiert wissen möchte.
>>>>
>>>> Nun ist es leider so, dass die gegebene Software dies nicht selbst kann
>>>> und es auch nur schwer bis unmöglich ist, dies einzubauen.
>>>>
>>>> Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
>>>> komplette Konfiguration von allen beteiligten Komponenten. Also die
>>>> Idee, dass die Software ihre Mails über eine entsprechend dafür
>>>> bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
>>>> Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen wird.
>>>
>>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall kryptografisch
>>> signierte Phishingmails und kryptografisch signierte Malware
>>> versendest?
>>
>> Man muss ja nicht per se alles signieren.
>
> Die Auswahl stelle ich mir allerdings eher schwierig vor.

Bei postfix könnte man basierend auf Absenderadresse,
Einlieferungs-IP-Adresse, etc. entsprechend via S/MIME-Filter senden oder nicht.

Ich kenne allerdings exim nicht. Aber die exim-Fans behaupten doch immer, dass
der noch viel mächtiger als postfix ist. Also wo liegt das Problem?

Ciao, Michael.

[Michael Ströder]

Arno Welzel wrote:
> Am 2015-06-22 um 23:54 schrieb Sven Hartge:
>
>> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>> (hoffentlich) ist.
>>
>> Gegeben sei eine Software, welche Mails ("Bitte ändere dein Passwort",
>> "Dein Passwort wurde gerade geändert", "Dein Account wurde deaktiviert,
>> weil du dein Passwort nicht geändert hast", etc.) an Benutzer
>> verschickt, die ich gerne cryptographisch signiert wissen möchte.
>
> Und warum? Also welches Problem wird damit gelöst?

Vielleicht möchte er die Möglichkeit haben, echte Password-Self-Service-Mails
von Phishing-Mails zu unterscheiden?

Oder vielleicht möchte er seine Benutzer dazu erziehen, nur auf Links in
vertrauenswürdigen E-Mails zu klicken?

Und wenn seine Benutzer später mal S/MIME-Zertifikate haben, kann er mit dem
selben Skript die E-Mails auch verschlüsseln.

Ciao, Michael.

[Heiko Schlichting]

An den Möglichkeiten von Exim scheitert das ganz sicher nicht. Ich glaube
auch nicht, dass Marc das so meinte.

Wenn man das verantwortungsvoll konfiguriert, sollte das nicht schlimmer
sein als eine automatisierte Signierung auf einem Client. Aber wie immer
bei Automatismen, besteht die Gefahr, dass diese nicht erkennt, wenn ihr
Schadsoftware oder Spam untergeschoben wird und sie wird auch dieses
signieren. Dieses kann aber auf einem automatisch signierenden Client
genauso passieren. Genauso ein unbefugtes Kopieren des Zertifikates.

Sicherer wird es, wenn das Zertifikat mit einer Passphrase geschützt ist und
durch einen Menschen bei jeder zu signierenden Mail entsperrt wird. Das ist
auch der typische und im allgemeinen erwartete Weg, wie Mail signiert wird.
Bei automatischen Mails (CERT-Warnungen, Ticket-Systeme etc.) kann man
diesen Weg nicht gehen. Ob das *automatische* Signieren von Mails dann noch
einen Vorteil gegenüber unsignierten Mails bringt, muss jeder selbst
entscheiden. Im Einzelfall könnte man sich solche Situationen ja durchaus
vorstellen.

Das automatische Signieren technisch mit Exim zu realisieren, z.B. als
transport_filter (einfacher) oder mit Embedded Perl (technisch schöner,
aber eben auch aufwändiger), ist kein Problem.

Heiko

[Heiko Schlichting]

An den Möglichkeiten von Exim scheitert das ganz sicher nicht. Ich glaube
auch nicht, dass Marc das so meinte.

Wenn man das verantwortungsvoll konfiguriert, sollte das nicht schlimmer
sein als eine automatisierte Signierung auf einem Client. Aber wie immer

bei Automatismen, besteht die Gefahr, dass diese nicht erkennen, wenn ihnen
Schadsoftware oder Spam untergeschoben werden und sie werden dieses auch
signieren. Das kann aber auf einem automatisch signierenden Client genauso
passieren. Ebenfalls das unbefugte Kopieren des Zertifikates.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>> (hoffentlich) ist.

>> Gegeben sei eine Software, welche Mails ("Bitte ändere dein
>> Passwort", "Dein Passwort wurde gerade geändert", "Dein Account wurde
>> deaktiviert, weil du dein Passwort nicht geändert hast", etc.) an
>> Benutzer verschickt, die ich gerne cryptographisch signiert wissen
>> möchte.
>>
>> Nun ist es leider so, dass die gegebene Software dies nicht selbst
>> kann und es auch nur schwer bis unmöglich ist, dies einzubauen.
>>
>> Aber ich kontrolliere natürlich den kompletten Mailverkehr und die
>> komplette Konfiguration von allen beteiligten Komponenten. Also die
>> Idee, dass die Software ihre Mails über eine entsprechend dafür
>> bereitgestelltes Mailrelay verschickt, welches dann nachträglich die
>> Signatur vornimmt, bevor die Mail dann an die weite Welt entlassen
>> wird.

> Du bist Dir bewusst dass Du damit dann im Zweifelsfall kryptografisch
> signierte Phishingmails und kryptografisch signierte Malware
> versendest?

In welchem Fall? Der spezielle Mailrelay wird natürlich nur für den
Versand dieser speziellen Info-Mails benutzt. Der normale Mailtraffic
läuft getrennt davon über andere Systeme.

S°

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Michael Ströder <mic...@stroeder.com> wrote:
>>Marc Haber wrote:

>>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall
>>> kryptografisch signierte Phishingmails und kryptografisch signierte
>>> Malware versendest?

>> Man muss ja nicht per se alles signieren.

> Die Auswahl stelle ich mir allerdings eher schwierig vor.

Warum?

Den vorgesehenen Server dürfen nur 4 Systeme mit 3 bestimmten
Absender-Adressen als Mail-Relay nutzen.

Im Exim könnte ich entweder via ACL oder im Manual-Router prüfen, ob
eine bestimmte Absender-Adresse vorliegt und nur dann die Signatur
durchführen.

Streng genommen muss ich das ohnehin machen, da ja die Mail im CN des
Zertifikats mit der Absender-Adresse der Mail übereinstimmen muss.

S°

[Sven Hartge]

Arno Welzel <use...@arnowelzel.de> wrote:
> Am 2015-06-22 um 23:54 schrieb Sven Hartge:

>> Der Betreff klingt erst einmal bescheuerter, als das Vorhaben
>> (hoffentlich) ist.
>>
>> Gegeben sei eine Software, welche Mails ("Bitte ändere dein
>> Passwort", "Dein Passwort wurde gerade geändert", "Dein Account wurde
>> deaktiviert, weil du dein Passwort nicht geändert hast", etc.) an
>> Benutzer verschickt, die ich gerne cryptographisch signiert wissen
>> möchte.

> Und warum? Also welches Problem wird damit gelöst?

Die Echtheit der Mail gegenüber Phishing-Mails abzuheben.

Und ja, ich weiss, dass ich damit a) weder die Doofheit der Benutzer
löse, außerdem weiss ich, dass b) aus dem Schluss "Signiert=Echt" sich
kein Umkehrschluss "unsigniert=unecht" ergibt.

Es wird gewünscht, dass die administrativen Info-Mails mit einem
offiziellen Schlüssel signiert sind.

> [...]
>> In meinem präferierten MTA Exim sollte sich das nicht zu schwer
>> einbauen lassen, ein manual_router und ein pipe_transport dürften
>> reichen.
>>
>> Auch das Programm, in welches die zu signierende Mail dann hinein
>> gepipet wird, kann ich durchaus selbst entwickeln, aber gerade bei
>> Crypto-Kram wäre es natürlichn schöner, wenn man etwas nehmen könnte, wo
>> vielleicht schon mal mehrere Leute drüber geschaut haben.
>>
>> Hier findet sich für Postfix eine Idee für soetwas:
>> http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime
>>
>> Aber ... Shell-Script? Brrr...

> Warum? Das ist doch für einen Mailserver genau das Richtige. Oder
> willst Du jede Mail in einer GUI von Hand signieren?

Nein, aber das automatisierte Tool vielleicht in einer anderen Sprache
haben, z.B. Perl oder Python, von mir aus auch Ruby.

S°

[Sven Hartge]

Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
> Michael Ströder <mic...@stroeder.com> wrote:
>> Marc Haber wrote:

>>> Die Auswahl stelle ich mir allerdings eher schwierig vor.

>> Bei postfix könnte man basierend auf Absenderadresse,
>> Einlieferungs-IP-Adresse, etc. entsprechend via S/MIME-Filter senden
>> oder nicht.
>>
>> Ich kenne allerdings exim nicht. Aber die exim-Fans behaupten doch
>> immer, dass der noch viel mächtiger als postfix ist. Also wo liegt
>> das Problem?

> An den Möglichkeiten von Exim scheitert das ganz sicher nicht. Ich
> glaube auch nicht, dass Marc das so meinte.

> Wenn man das verantwortungsvoll konfiguriert, sollte das nicht
> schlimmer sein als eine automatisierte Signierung auf einem Client.
> Aber wie immer bei Automatismen, besteht die Gefahr, dass diese nicht
> erkennen, wenn ihnen Schadsoftware oder Spam untergeschoben werden und
> sie werden dieses auch signieren. Das kann aber auf einem automatisch
> signierenden Client genauso passieren. Ebenfalls das unbefugte
> Kopieren des Zertifikates.

Dadurch, dass ich das Signieren auf einem speziellen Mailserver
vornehmen will, der ausschließlich für eben die automatisierten Mails
zuständig ist, dürfte dieses Problem auszuschließen sein.

Dass ich nicht versuche, so eine Aktion auf dem zentralen Mailrelay
durchzuführen, versteht sich von selbst. (Vor allem, weil dessen
Konfiguration schon komplex genug ist.)

> Das automatische Signieren technisch mit Exim zu realisieren, z.B. als
> transport_filter (einfacher) oder mit Embedded Perl (technisch
> schöner, aber eben auch aufwändiger), ist kein Problem.

Die Erfahrungen dieser Stelle, in welche Stolperfallen evtl. jemand
schon gefallen ist, versuche ich hier zu erhalten. Man muss ja nicht
jeden Fehler selbst wiederholen, man kann ja durchaus von den Fehlern
anderer lernen. Sofern diese bereit sind, diese zu teilen.

S°

[Heiko Schlichting]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
>> Das automatische Signieren technisch mit Exim zu realisieren, z.B. als
>> transport_filter (einfacher) oder mit Embedded Perl (technisch
>> schöner, aber eben auch aufwändiger), ist kein Problem.
>
> Die Erfahrungen dieser Stelle, in welche Stolperfallen evtl. jemand
> schon gefallen ist, versuche ich hier zu erhalten. Man muss ja nicht
> jeden Fehler selbst wiederholen, man kann ja durchaus von den Fehlern
> anderer lernen. Sofern diese bereit sind, diese zu teilen.

Das würde ich tun, aber ich mache schon diverse Dinge mit Transport-Filtern
und manches auch mit embedded Perl, aber den Bedarf zentral zu signieren
hatte ich bislang nicht. Daher kann ich hier kein konkretes Beispielscript
posten.

Heiko

[Arno Welzel]

Am 2015-06-23 um 14:33 schrieb Sven Hartge:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 2015-06-22 um 23:54 schrieb Sven Hartge:

[...]

>>> Hier findet sich für Postfix eine Idee für soetwas:
>>> http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime
>>>
>>> Aber ... Shell-Script? Brrr...
>
>> Warum? Das ist doch für einen Mailserver genau das Richtige. Oder
>> willst Du jede Mail in einer GUI von Hand signieren?
>
> Nein, aber das automatisierte Tool vielleicht in einer anderen Sprache
> haben, z.B. Perl oder Python, von mir aus auch Ruby.

Was das Script tut, ist eigentlich recht klar - es wird openssl benutzt,
um die Nachricht zu signieren und das ganze läuft als Filter - d.h.
unsignierte Nachricht rein, signierte Nachricht raus. Das kann man
natürlich auch in Perl, Python oder Ruby nachbauen - am Ende geht's ja
nur darum, openssl an passender Stelle mit den nötigen Parametern
aufzurufen:

openssl smime -sign -in <eingabe> -out <ausgabe> -from <absender>
-to <empfaenger> -signer <zertifikat> -inkey <schluessel>
-text

[Sven Hartge]

Sven Hartge <sh-...@svenhartge.de> wrote:
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 2015-06-22 um 23:54 schrieb Sven Hartge:

>>> Hier findet sich für Postfix eine Idee für soetwas:
>>> http://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime

>> Warum? Das ist doch für einen Mailserver genau das Richtige. Oder
>> willst Du jede Mail in einer GUI von Hand signieren?

> Nein, aber das automatisierte Tool vielleicht in einer anderen Sprache
> haben, z.B. Perl oder Python, von mir aus auch Ruby.

Nun, ich habe mal das folgende zusammengestoppelt:

--------8<-------------
#!/bin/bash
EX_UNAVAILABLE=69

umask 077

MAILTMP=`mktemp`

trap "rm -f ${MAILTMP} ${MAILTMP}.header ${MAILTMP}.body ${MAILTMP}.signedbody" 0 1 2 3 15

# STDIN in Datei schreiben
cat > "${MAILTMP}" || { echo "Cannot save mail to file"; exit $EX_UNAVAILABLE;}

# Header extrahieren, leere Zeile am Ende entfernen
sed -e '/^$/ q' < "${MAILTMP}" | head -n -1 > "${MAILTMP}.header" || { echo "Cannot save header to file"; exit $EX_UNAVAILABLE;}

# Body extrahieren
sed -e '1,/^$/ d' < "${MAILTMP}" > "${MAILTMP}.body" || { echo "Cannot save body to file"; exit $EX_UNAVAILABLE;}

# Signieren
openssl smime -passin file:/etc/smime-signer/smimepass -sign -signer /etc/smime-signer/smime-signer.pem -text < "${MAILTMP}.body" > "${MAILTMP}.signedbody" || { echo "Cannot sign mail"; exit $EX_UNAVAILABLE;}

# Heeader und signierten Body ausgeben
cat "${MAILTMP}.header" "${MAILTMP}.signedbody"

rm -f "${MAILTMP}" "${MAILTMP}.header" "${MAILTMP}.body" "${MAILTMP}.signedbody"
--------8<-------------

Die Lösung aus der URL mit der separaten Angabe von Subject und Co.
gefiel mir nicht.

Den Body muss man vor dem "openssl smime" abtrennen, sonst passen die
Header nicht bzw. werden mitsigniert und sind somit für den MTA keine
Header mehr.

Daher meine Variante den Header mit sed abzulösen, den Body zu signieren
und am Ende alles wieder auf STDOUT auszugeben.

Wenn man in Shell-Golf geübt ist, bekommt das sicherlich auch kürzer und
mit weniger Temp-Dateien hin.

[Marc Haber]

Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
>An den Möglichkeiten von Exim scheitert das ganz sicher nicht. Ich glaube
>auch nicht, dass Marc das so meinte.

Genau. Aber Michael versteht mich gerne mal miß ;-)

Ansonsten kann ich Dir nur vollumfänglich zustimmen.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Michael Ströder <mic...@stroeder.com> wrote:
>>>Marc Haber wrote:
>
>>>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall
>>>> kryptografisch signierte Phishingmails und kryptografisch signierte
>>>> Malware versendest?
>
>>> Man muss ja nicht per se alles signieren.
>
>> Die Auswahl stelle ich mir allerdings eher schwierig vor.
>
>Warum?
>
>Den vorgesehenen Server dürfen nur 4 Systeme mit 3 bestimmten
>Absender-Adressen als Mail-Relay nutzen.

Mein Gefühl sagt (ohne das jetzt technisch fundieren könnte):
- Port 587 und SMTP auth mit ekligem Passwort nehmen
- Kommunikation per Paketfilter auf die vorgesehenen Clients
beschränken

>Im Exim könnte ich entweder via ACL oder im Manual-Router prüfen, ob
>eine bestimmte Absender-Adresse vorliegt und nur dann die Signatur
>durchführen.

Das sowieso.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:

>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall kryptografisch
>> signierte Phishingmails und kryptografisch signierte Malware
>> versendest?
>
>In welchem Fall?

In dem Fall, dass das absendende System kompromittiert wurde. Was bei
einem System, das auf Java 5 in einer ganz bestimmten Version besteht,
ja nicht gerade unwahrscheinlich ist.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Nein, aber das automatisierte Tool vielleicht in einer anderen Sprache
>haben, z.B. Perl oder Python, von mir aus auch Ruby.

perl hätte den Vorteil, dass man die Signatur per embedded perl
einbringen könnte.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:

>>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall
>>> kryptografisch signierte Phishingmails und kryptografisch signierte
>>> Malware versendest?
>>
>> In welchem Fall?

> In dem Fall, dass das absendende System kompromittiert wurde. Was bei
> einem System, das auf Java 5 in einer ganz bestimmten Version besteht,
> ja nicht gerade unwahrscheinlich ist.

Das war Java6 und ist glücklicherweise ein anderes System und nicht
dieses.

[Sven Hartge]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Nun, ich habe mal das folgende zusammengestoppelt:

Für die Mitspieler an den Schirmen zu Hause:

-------------8<---------------
#!/bin/bash
EX_UNAVAILABLE=69

export RANDFILE=/var/spool/exim4/.rnd

umask 077

MAILTMP=`mktemp /tmp/smime.XXXXXXXX`

trap "rm -f ${MAILTMP} ${MAILTMP}.header ${MAILTMP}.body ${MAILTMP}.signedbody ${MAILTMP}.signedbody-tr" 0 1 2 3 15

# STDIN in Datei schreiben

cat > "${MAILTMP}" || ( echo "Cannot save mail to file"; exit $EX_UNAVAILABLE;)

# Header extrahieren, leere Zeile am Ende entfernen

sed -e '/^$/ q' < "${MAILTMP}" | head -n -1 > "${MAILTMP}.header" || ( echo "Cannot save header to file"; exit $EX_UNAVAILABLE;)

# Body extrahieren
sed -e '1,/^$/ d' < "${MAILTMP}" > "${MAILTMP}.body" || ( echo "Cannot save body to file"; exit $EX_UNAVAILABLE;)

# Signieren
openssl smime -text -passin file:/etc/smime-signer/smimepass -sign -signer /etc/smime-signer/smime-signer.pem -in "${MAILTMP}.body" -out "${MAILTMP}.signedbody" 2>/dev/null || ( echo "Cannot sign mail"; exit $EX_UNAVAILABLE;)

# Überflüssige \r entfernen, die openssl hinzufügt, die später doppelt entfernt werden würden
# -> Signatur passt nicht mehr
tr -d '\r' < "${MAILTMP}.signedbody" > "${MAILTMP}.signedbody-tr"

# Heeader und signierten Body ausgeben

cat "${MAILTMP}.header" "${MAILTMP}.signedbody-tr"

rm -f "${MAILTMP}" "${MAILTMP}.header" "${MAILTMP}.body" "${MAILTMP}.signedbody" "${MAILTMP}.signedbody-tr"
-------------8<---------------

Das Verhalten von openssl, vor dem Signieren noch ein \r zuzufügen, hat
mir echt Kopfschmerzen bereitet.

Exim fügt dann nämlich vor dem Versenden an alle anderen Zeilen der Mail
noch ein \r hinzu, wie von SMTP-RFC gefordert, nur nicht bei den Zeilen,
die schon ein \r haben (das hat openssl ja schon gemacht).

Das Zielsystem entfernt dann alle \r zur Anzeige wieder und schon stimmt
die Signatur nicht mehr, da die \r im signierten Teil ja auch entfernt
wurden.

Das man den Pfad für RANDFILE für openssl hilfsweise angeben muss, ist
da noch die kleinere Sache.

Mit obigem Code bekomme ich auf meinem Test-System jetzt sauber
signierte Mails hin, wenn man das Ding einfach via transport_filter (und
"size_addition = -1" um die SIZE-Extension für den Transport zu
deaktivieren, da der Filter die Mail doch deutlich vergrößert) aufruft.

Sinnigerweise macht man einen speziellen Transport, der von einem
speziellen Router aufgerufen wird, der über entsprechende conditions
etc. prüft, ob die Mail überhaupt signiert werden soll.

Braucht man mehrere Signatur-Keys, so ist das obige Script natürlich
anzupassen, damit dies entweder als Parameter übergeben oder aus der
Mail geparst wird.

Grüße,
Sven.

[Sven Hartge]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Nun, ich habe mal das folgende zusammengestoppelt:

Für die Mitspieler an den Schirmen zu Hause:

-------------8<---------------
#!/bin/bash
EX_UNAVAILABLE=69

export RANDFILE=/var/spool/exim4/.rnd

umask 077

MAILTMP=`mktemp /tmp/smime.XXXXXXXX`

trap "rm -f ${MAILTMP} ${MAILTMP}.header ${MAILTMP}.body ${MAILTMP}.signedbody ${MAILTMP}.signedbody-tr" 0 1 2 3 15

# STDIN in Datei schreiben

cat > "${MAILTMP}" || ( echo "Cannot save mail to file"; exit $EX_UNAVAILABLE;)

# Header extrahieren, leere Zeile am Ende entfernen

sed -e '/^$/ q' < "${MAILTMP}" | head -n -1 > "${MAILTMP}.header" || ( echo "Cannot save header to file"; exit $EX_UNAVAILABLE;)

# Body extrahieren

sed -e '1,/^$/ d' < "${MAILTMP}" > "${MAILTMP}.body" || ( echo "Cannot save body to file"; exit $EX_UNAVAILABLE;)

# Signieren
openssl smime -text -passin file:/etc/smime-signer/smimepass -sign -signer /etc/smime-signer/smime-signer.pem -in "${MAILTMP}.body" -out "${MAILTMP}.signedbody" 2>/dev/null || ( echo "Cannot sign mail"; exit $EX_UNAVAILABLE;)

# Überflüssige \r entfernen, die openssl hinzufügt, die später doppelt entfernt werden müßten

# -> Signatur passt nicht mehr
tr -d '\r' < "${MAILTMP}.signedbody" > "${MAILTMP}.signedbody-tr"

# Heeader und signierten Body ausgeben

cat "${MAILTMP}.header" "${MAILTMP}.signedbody-tr"

rm -f "${MAILTMP}" "${MAILTMP}.header" "${MAILTMP}.body" "${MAILTMP}.signedbody" "${MAILTMP}.signedbody-tr"
-------------8<---------------

Das Verhalten von openssl, nach dem Signieren noch ein \r zuzufügen, hat
mir echt Kopfschmerzen bereitet.

Exim fügt dann nämlich vor dem Versenden an alle Zeilen der Mail noch
ein \r hinzu, wie von SMTP-RFC gefordert, auch bei den Zeilen, die schon

ein \r haben (das hat openssl ja schon gemacht).

Das Zielsystem entfernt dann alle \r zur Anzeige wieder und dann stimmt
die Signatur nicht mehr, da die \r im signierten Teil doppelt vorhanden
waren und doppelt entfernt werden müßten.

Das man den Pfad für RANDFILE für openssl hilfsweise angeben muss, ist
da noch die kleinere Sache.

Mit obigem Code bekomme ich auf meinem Test-System jetzt sauber
signierte Mails hin, wenn man das Ding einfach via transport_filter (und
"size_addition = -1" um die SIZE-Extension für den Transport zu
deaktivieren, da der Filter die Mail doch deutlich vergrößert) aufruft.

Sinnigerweise macht man einen speziellen Transport, der von einem
speziellen Router aufgerufen wird, der über entsprechende conditions
etc. prüft, ob die Mail überhaupt signiert werden soll.

Braucht man mehrere Signatur-Keys, so ist das obige Script natürlich
anzupassen, damit dies entweder als Parameter übergeben oder aus der
Mail geparst wird.

Grüße,
Sven.

[Sven Hartge]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Mit obigem Code bekomme ich auf meinem Test-System jetzt sauber
> signierte Mails hin, wenn man das Ding einfach via transport_filter
> (und "size_addition = -1" um die SIZE-Extension für den Transport zu
> deaktivieren, da der Filter die Mail doch deutlich vergrößert)
> aufruft.

Ja, solange es sich um 7bit-ASCII handelt. Hmpf. Zurück zum
Zeichenbrett.

S°

[Sven Hartge]

OK, nach wilden grep-arien verfrachte ich nun den Content-Type und
Content-Transfer-Encoding vom Header in den Teil, der später im
MIME-Container ist, bevor ich openssl darüber laufen lassen.

Spätestens jetzt ist wohl der Zeitpunkt gekommen, den Kram in Perl mit
Hilfe von MIME::Entity sauber zu reimplementieren.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Michael Ströder <mic...@stroeder.com> wrote:
>>>> Marc Haber wrote:

>>>>> Du bist Dir bewusst dass Du damit dann im Zweifelsfall
>>>>> kryptografisch signierte Phishingmails und kryptografisch
>>>>> signierte Malware versendest?
>>
>>>> Man muss ja nicht per se alles signieren.
>>
>>> Die Auswahl stelle ich mir allerdings eher schwierig vor.
>>
>> Warum?
>>
>> Den vorgesehenen Server dürfen nur 4 Systeme mit 3 bestimmten
>> Absender-Adressen als Mail-Relay nutzen.

> Mein Gefühl sagt (ohne das jetzt technisch fundieren könnte):
> - Port 587 und SMTP auth mit ekligem Passwort nehmen

Das wollte ich über eine x509-Anmeldung machen.

> - Kommunikation per Paketfilter auf die vorgesehenen Clients
> beschränken

Grundsätzlich, natürlich.

[Paul Muster]

On 23.06.2015 16:22, Marc Haber wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Den vorgesehenen Server dürfen nur 4 Systeme mit 3 bestimmten
>> Absender-Adressen als Mail-Relay nutzen.
>
> Mein Gefühl sagt (ohne das jetzt technisch fundieren könnte):
> - Port 587 und SMTP auth mit ekligem Passwort nehmen

Wieso Passwort? Ich denke, es liefert eine _Maschine_ ein? Sollte die
sich dann nicht mit einem Maschinen-Zertifikat ausweisen? Finde ich
schicker.


mfG Paul

[Sven Hartge]

Es werden 4 Systeme sein, die solche Mails erzeugen. Aber dennoch ein
eng begrenzter Quell-Bereich.

[Marc Haber]

SMTP Auth können die exim-Pakete aber von Haus aus trivial. Und
unsicherer als Zertifikate ist es auch nicht.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Mein Gefühl sagt (ohne das jetzt technisch fundieren könnte):
>> - Port 587 und SMTP auth mit ekligem Passwort nehmen
>
>Das wollte ich über eine x509-Anmeldung machen.

auch gut.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:

>>> Mein Gefühl sagt (ohne das jetzt technisch fundieren könnte): Port

>>> 587 und SMTP auth mit ekligem Passwort nehmen
>>
>> Das wollte ich über eine x509-Anmeldung machen.

> auch gut.

Außerdem eine gute Gelegenheit, mal wieder das Wissen in der Richtung zu
verbreitern.

[Nomen Nescio]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Nun, ich habe mal das folgende zusammengestoppelt:

Warum nicht einfach DKIM?

[Juergen P. Meier]

Nomen Nescio <nob...@dizum.com>:

> Sven Hartge <sh-...@svenhartge.de> wrote:
>
>> Nun, ich habe mal das folgende zusammengestoppelt:
>
> Warum nicht einfach DKIM?

DKIM signiert quasi den Dominapart der Absenderadresse mit
Kaufzertifikaten deren Aussagekraft sich ansonsten gegen die
Hintergrundtermperatur des Universums annaehert. von unten.

S/MIME signiert den Inhalt.

[Nomen Nescio]

"Juergen P. Meier" <nospa...@jors.net> wrote:

> DKIM signiert quasi den Dominapart der Absenderadresse mit
> Kaufzertifikaten deren Aussagekraft sich ansonsten gegen die
> Hintergrundtermperatur des Universums annaehert. von unten.

Nein. Nuhr.

[Michael Ströder]

Nein, siehe Definition von "bh" hier:

https://tools.ietf.org/html/rfc6376#section-3.5

> S/MIME signiert den Inhalt.

Ja, aber derzeit leider keine Header, weil RFC 7508 wahrscheinlich noch
niemand umgesetzt hat.

Der Vorteil von S/MIME im Gegensatz zu DKIM ist aber, dass gängige MUAs eine
mehr oder minder geglückte Anzeige der Signatur implementiert haben.

Ciao, Michael.