Digitale Email Signatur ungültig wenn appliance mail relay

[chrisweibel]

Die appliance ist als mail relay konfiguriert (wegen sicherheit, Spamfilterung, ...), dahinter ein SBS2003 server mit exchange.
Wenn Emails mit einer Digitalen ID signiert werden ist die Signatur beim Empfänger ungültig, da der Header geändert wird, somit stimmt der hashwert nicht mehr.

Nach studieren des S/MIME RfC`s und lesen auf Technet ist das ein Fehler der appliance.

Wenn die Email mit zertifikaten verschlüsselt wird, wird der Header nicht verändert und somit das zertifikat gültig.
Wenn die signierten mails die appliance "übergehen" ist die signatur ebenfalls gülltig.
Das selbe ist bei eingehenden Emails.

[chrisweibel]

hallo support team
habe bei Heise security soeben einen Artikel gelesen, der evtl zu diesem Fall passt.
http://www.heise.de/security/Eingriff-i ... ung/116073

Hoffe dass es bald funktioniert

[chrisweibel]

Hallo supportteam,
ich habe bei anderen Firewalls eine option gesehen, dass die signatur nicht ungültig macht.
wenn die Firewall als mailrelay verwendet wird kann man eine checkbox aktivieren, so dass vom relay nichts in den Header geschrieben wird. Dies wäre u.a. auch aus security sicht sehr gut, dass man nichts von den Internen adressen und Hostnamen hat.

[rkkh-ffm]

Hallo zusammen!

Ich bin bei unserem System auf die selben Symptome gestoßen.
Unsere Securepoint (2007nx R3) arbeitet z. Zt. als Relay mit Greylisting und Virenkiller. Daran soll sich auch nichts ändern.

Sende ich nun Mails mit Outlook (oder einem anderen Mailclient, oder auch direkt per Telnet zum sendmail der Securepoint...) an einen externen Empfänger, passiert nun folgendes:

Eine vom Versender mit S/MIME signierte Mail sieht im Klartext aus wie im folgenden Beispiel:

Code: Alles auswählen

From sender@my.domain Wed Feb 18 15:32:45 2009
Received: from [10.0.0.57] (10.0.0.57) by exchange.my.domain
	(10.0.0.1) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 18 Feb
	2009 15:32:45 +0100
From: From User <sender@my.domain>
To: Recipient <recipient@other.domain>
Date: Wed, 18 Feb 2009 12:14:45 +0100
Subject: TEST
Thread-Topic: TEST
Thread-Index: AcmR1cPm2mmseWnsQgCSW2Glieo5Ow==
Message-ID: <1234955685.7871.2.camel@clientcomputer>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 0a
X-MS-Exchange-Organization-AuthSource: exchange.my.domain
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-dAy+SdGoIpjgemAQRBB0"
MIME-Version: 1.0

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

TEST TEST TEST

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCCBEEw
ggOqoAMCAQICDwCjcwABAAJvLobPDn8qujANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc
MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh

# viele Daten ausgelassen #

TPgEzat01mMEddjl3ueZrCxFoft80GsybZWAia2LiNzCj4l/Zo7hjnS7htswQMlJPmL2AofiTRWX
RnUz3HgU38jh+cCpc83FFHBqOq4FoQA/k4SZnBMvOc4AvmV6mzUO3aYTCXRpWbb5kVBUAAAAAAAA



--=-dAy+SdGoIpjgemAQRBB0--

Beim Empfänger sieht die Mail dann aber wie folgt aus:

Code: Alles auswählen

# Transportdaten mal weggelassen, da irrelevant für das Beispiel #
From sender@my.domain Wed Feb 18 15:32:45 2009
Received: from [10.0.0.57] (10.0.0.57) by exchange.my.domain
	(10.0.0.1) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 18 Feb
	2009 15:32:45 +0100
From: From User <sender@my.domain>
To: Recipient <recipient@other.domain>
Date: Wed, 18 Feb 2009 12:14:45 +0100
Subject: TEST
Thread-Topic: TEST
Thread-Index: AcmR1cPm2mmseWnsQgCSW2Glieo5Ow==
Message-ID: <1234955685.7871.2.camel@clientcomputer>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 0a
X-MS-Exchange-Organization-AuthSource: exchange.my.domain
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-dAy+SdGoIpjgemAQRBB0"
MIME-Version: 1.0

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

TEST TEST TEST


--=-dAy+SdGoIpjgemAQRBB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCCBEEw
ggOqoAMCAQICDwCjcwABAAJvLobPDn8qujANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc
MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh

# viele Daten ausgelassen #

TPgEzat01mMEddjl3ueZrCxFoft80GsybZWAia2LiNzCj4l/Zo7hjnS7htswQMlJPmL2AofiTRWX
RnUz3HgU38jh+cCpc83FFHBqOq4FoQA/k4SZnBMvOc4AvmV6mzUO3aYTCXRpWbb5kVBUAAAAAAAA




--=-dAy+SdGoIpjgemAQRBB0--

Das sieht zwar, oberflächlich betrachtet, gleich aus, allerdings wurde (nachweislich in der Securepoint) am Ende jedes MIME-Subparts eine Leerzeile angefügt!

Als Folge verändert sich dann der Inhalt des signierten ersten, signierten Subparts von

Code: Alles auswählen

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

TEST TEST TEST

--=-dAy+SdGoIpjgemAQRBB0

auf:

Code: Alles auswählen

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

TEST TEST TEST


--=-dAy+SdGoIpjgemAQRBB0

und die Unterschrift wird ungültig!


Die Unterschrift selber ist ja an sich base64-codiert und wird daher nicht verändert, die Leerzeile ist ja hinter dem eigentlichen Signatur-Block, aber noch vor Ende des Subparts von:

Code: Alles auswählen

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCCBEEw
# viele Daten ausgelassen #
RnUz3HgU38jh+cCpc83FFHBqOq4FoQA/k4SZnBMvOc4AvmV6mzUO3aYTCXRpWbb5kVBUAAAAAAAA



--=-dAy+SdGoIpjgemAQRBB0--

auf:

Code: Alles auswählen

--=-dAy+SdGoIpjgemAQRBB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCCBEEw
# viele Daten ausgelassen #
RnUz3HgU38jh+cCpc83FFHBqOq4FoQA/k4SZnBMvOc4AvmV6mzUO3aYTCXRpWbb5kVBUAAAAAAAA



--=-dAy+SdGoIpjgemAQRBB0--

Dieser Fehler tritt beispielsweise nicht auf, wenn der Inhalt des zu signierenden Blocks entweder nicht als Klartext versandt wird (vergleiche Outlook 2003: Menü Extras -> Optionen... -> Tab Sicherheit -> Punkt "Signierte Nachricht als Klartext senden"-Haken entfernen). Dann wird der gesammte zu signierende Text sammt Signatur in einen base64-transkodierten Block verpackt und diese verändert sich nicht inhaltlich durch die angehängte Leerzeile.
(Das Beispiel poste ich jetzt mal nicht mit, Fakt ist, dass es funktioniert.)

Andere Mailprogramme (siehe Einleitung :-) ) sind ebenfalls betroffen, sofern diese nicht ebenfalls die Option bieten, die Nachricht nicht im Klartext zu senden...

Soweit zu den Symptomen.

Meine Frage an das Support-Team:
Wie bringen wir nun dem Sendmail bei (ich gehe mal davon aus, dass es er oder einer seiner Helfer ist), die Leerzeilen eigenmächtig in die Mails zu stopfen?

Für eine baldige Antwort wäre ich wirklich sehr dankbar, wir benötigen in absehbarer Zeit eine funktionierende Mail-Verschlüsselungs und -signaturfunktion!

Gruß aus Frankfurt/Main
Edwin Kelm

[carsten]

Hallo,

und vielen Dank für die ausführliche Ananyse! Habe dies weitergeben und hoffe auf baldige Beseitigung des Bugs.

Temporär sollte dies behoben werden können indem der Attachment_Cleaner ausgeschaltet wird.

Code: Alles auswählen

change extc_value sendmail ENABLE_ATTACHMENTFILTER 0

[rkkh-ffm]

Hallo, Carsten!

Danke für die schnelle Hilfe!

Temporär sollte dies behoben werden können indem der Attachment_Cleaner ausgeschaltet wird.

Code: Alles auswählen

change extc_value sendmail ENABLE_ATTACHMENTFILTER 0

OK, ich hab's mal mit Outlook/Exchange getestet und die Signatur ist jetzt ok.

Erstaunlicherweise bricht die Securepoint aber den 2. Subpart, also den mit der Signatur von

Code: Alles auswählen

------=_NextPart_000_000F_01C99394.5AF94BE0
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMeDCCA1ww

nach

Code: Alles auswählen

------=_NextPart_000_000F_01C99394.5AF94BE0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMeDCCA1ww

um: Die Zeile mit "Content-Type" und "Content-Disposition" wird immer noch "bereinigt" (Wobei sich ja die Frage erhebt, wieso die von Outlook überhaupt umgebrochen werden :twisted: )...

Immerhin stimmen jetzt zumindest erstmal die Signaturen...
Wenn sich bei weiteren Test was ergibt, lasse ich es Euch wissen!

Schönes Wochenende, und danke für die schnelle Hilfe!

Edwin Kelm

[rkkh-ffm]

Hallo, wertes Support-Team!

Hat sich bezüglich unseres Problem mit den "kaputtgesäuberten" signierten Mail schon etwas ergeben?

Schöne Grüße aus dem sonnigen Frankfurt