Postfix/Exchange TLS interoperability

[Victor Duchovni]

There was a recent report of interoperability issues between Exchange
acting as TLS client, and Postfix acting as a TLS server. I have just
experienced the converse problem, and the packet capture shows severe
breakage on the Exchange side...

First we send "EHLO hostname.fq.dn\r\n" (21 bytes) in the clear:

23:03:23.491182 Postfix > Exchange: P 1:22(21) ack 126 win 8760 (DF)

Then the server responds with 248 bytes of ESMTP features:

23:03:23.530482 Exchange > Postfix: P 126:374(248) ack 22 win 65514

Then "STARTTLS\r\n" and the server "220 2.0.0 SMTP server ready\r\n"

23:03:23.531045 Postfix > Exchange: P 22:32(10) ack 374 win 8760 (DF)
23:03:23.569872 Exchange > Postfix: P 374:403(29) ack 32 win 65504

Then a normal TLS handshake (short because session is cached):

23:03:23.573556 Postfix > Exchange: P 32:130(98) ack 403 win 8760 (DF)
23:03:23.612668 Exchange > Postfix: P 403:533(130) ack 130 win 65406
23:03:23.614696 Postfix > Exchange: P 130:181(51) ack 533 win 8760 (DF)

Then the client sends "EHLO hostname.fq.dn\r\n" again, but this time with
5 bytes of TLS header + padded CBC encrypted data, with a MAC which expands
to 4 + 48 or 53 bytes:

23:03:23.838369 Postfix > Exchange: P 181:234(53) ack 533 win 8760 (DF)
0x0020 XXXX XXXX XXXX XXXX 1703 0100 3049 49eb
0x0030 7a2f ebae 9049 21c2 0831 18ae fd77 df76
0x0040 7829 b404 92d0 4fad 2091 c802 43bc 941f
0x0050 3bfc d026 19c7 a2cf 88c4 0085 53

The 5 byte TLS header "1703 0100 30" indicates 48 bytes of TLS payload, which
decrypts to the 21 byte EHLO command.

And finally the Exchange response is corrupted! It sends, 258 bytes of TCP
data with a TLS header of "1703 0100 f8" which is 248 bytes of TLS payload
(for a total of 253 bytes of TLS message) plus a mysterious final 5 bytes
"2f 2f77 7777" which decodes to "//www". The first 248 decode to a valid
EHLO response, but the extra 5 bytes totally mess up subsequent communication.

23:03:23.877772 Exchange > Postfix: P 533:791(258) ack 234 win 65302
0x0020 XXXX XXXX XXXX XXXX 1703 0100 f828 fe97
0x0030 5984 aa62 4ce1 0557 a7c6 9fac 54c6 323b
0x0040 6d18 5201 989e 2e02 8433 8132 0d22 fec8
0x0050 b6a6 0990 6350 38f8 736a 92eb 5962 29d7
0x0060 3473 9afe 69a0 d446 74e3 e9e5 de73 489b
0x0070 8eb4 bc6d 35ac eac7 6f1a 645e b827 8027
0x0080 488b 3434 3ad5 dca0 1152 7786 19b7 582c
0x0090 4c59 ee88 2307 aa59 fc7f e79d c9fb abb5
0x00a0 d5e0 489f fb64 0880 58f7 55a5 f900 4ba0
0x00b0 b567 7d7a a59e 801a a8d1 f214 63db 35fc
0x00c0 f39c 97e3 21b3 098d 562b be4f 1221 c82e
0x00d0 ee09 a91c 62cd 9ab2 1269 f6f3 b66f dc73
0x00e0 439d 39ca 3ab1 0b52 f05f a4bf e802 2970
0x00f0 44d5 8da1 cf0b 9dd9 f673 1c26 0c61 db96
0x0100 4417 f726 5016 1a8f 993a 3e22 0546 c456
0x0110 f660 40c0 5083 0f86 4885 6cd2 54a8 1cfc
0x0120 f771 9436 542f 2f77 7777 .q.6T//www

It is very odd to find "//www" in the middle of a TLS stream. At this
point in the TCP stream we should see either a packet boundary, or
the beginning of the next TLS message (another 1703 0100 ... header).
Instead Exchange appended 5 bytes of clear-text junk (reused a buffer
without clearing it perhaps) leaking data from another message and
corrupting the TLS session.

If similar insertion of "random" data is present in the Exchange TLS
client, all manner of protocol issues will arise as garbage is interpreted
as TLS data.

I am no longer attempting to use TLS with the server in question...
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Kenneth Marshall]

Victor,

Thank you for posting this analysis. I have been building TLS
exception lists to disable TLS for systems that do not work correctly.
So far they have all been Exchange servers. Just another data point.

Ken

Post by Victor Duchovni
There was a recent report of interoperability issues between Exchange
acting as TLS client, and Postfix acting as a TLS server. I have just
experienced the converse problem, and the packet capture shows severe
breakage on the Exchange side...

...

[Victor Duchovni]

Post by Victor Duchovni
There was a recent report of interoperability issues between Exchange
acting as TLS client, and Postfix acting as a TLS server. I have just
experienced the converse problem, and the packet capture shows severe
breakage on the Exchange side...

I have found that this happens when the Postfix SMTP client insists on
"HIGH" grade ciphers, causing Exchange to negotiate DES-CBC3-SHA, which
it then gets wrong.

When the Postfix SMTP client proposes both "HIGH" and "MEDIUM" strength
ciphers (in that order) the Exchange server overrides the client cipher
preference and elects RC4-MD5, which does not exhibit the problem.

So the trick with at least some versions of the Exchange software is to
allow Exchange to select the RC4-MD5 combination despite the fact that
both are deprecated (RC4 has a poor key-schedule, and MD5 is no longer
collision resistant).
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Wietse Venema]

Post by Victor Duchovni

Post by Victor Duchovni
There was a recent report of interoperability issues between Exchange
acting as TLS client, and Postfix acting as a TLS server. I have just
experienced the converse problem, and the packet capture shows severe
breakage on the Exchange side...

I have found that this happens when the Postfix SMTP client insists on
"HIGH" grade ciphers, causing Exchange to negotiate DES-CBC3-SHA, which
it then gets wrong.
When the Postfix SMTP client proposes both "HIGH" and "MEDIUM" strength
ciphers (in that order) the Exchange server overrides the client cipher
preference and elects RC4-MD5, which does not exhibit the problem.
So the trick with at least some versions of the Exchange software is to
allow Exchange to select the RC4-MD5 combination despite the fact that
both are deprecated (RC4 has a poor key-schedule, and MD5 is no longer
collision resistant).

Is the Postfix default setting OK for Exchange?

- If yes, then we need to add a warning to Postfix documentation
so that people know bad things may happen when they make a change.

- If no, then we may have ti change the default. The primary purpose
of Postfix is to deliver mail, not to satisfy purists.

Wietse

[Victor Duchovni]

Post by Wietse Venema

Post by Victor Duchovni
So the trick with at least some versions of the Exchange software is to
allow Exchange to select the RC4-MD5 combination despite the fact that
both are deprecated (RC4 has a poor key-schedule, and MD5 is no longer
collision resistant).

Is the Postfix default setting OK for Exchange?
- If yes, then we need to add a warning to Postfix documentation
so that people know bad things may happen when they make a change.

Yes, the default is to allow all cipher grades for opportunistic TLS and
"medium" or better for mandatory TLS.

I have already verified that the default client behaviour (even when
TLS is mandatory) is interoperable with Exchange.

Servers that don't enforce TLS interoperate with Exchange clients (otherwise
we would see a lot of reports of broken Exchange->Postfix opportunistic TLS).

I don't know what happens when Exchange sends to Postfix servers that
mandate TLS (smtpd_enforce_tls = yes or smtpd_tls_security_level =
encrypt). In this case by default Postfix will support "medium" or
better ciphers and because OpenSSL servers typically accept the client's
cipher preferences, Exchange should get its first choice of cipher,
presumably this will again be RC4-MD5 or other non-broken choice.

The above needs to be tested by someone who controls a sending Exchange
server and a receiving Postfix server that mandates TLS.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ed Ray]

I went back and disabled "System cryptography: Use FIPS compliant
algorithms for encryption, hashing and signing" Security option on the
Exchange Server so that it would default to RC4-MD5 instead of 3DES-SHA1
for encryption. The Exchange Server now has no errors in
/var/log/maillog, but does not respond to TLS as a client or server:

<
Oct 24 11:57:04 portus postfix/smtp[1759]: Host offered STARTTLS:
[127.0.0.1]
Oct 24 11:57:04 portus postfix/smtpd[2294]: 820329EC002:
client=portus.netsecdesign.com[127.0.0.1]
Oct 24 11:57:04 portus postfix/cleanup[1752]: 820329EC002:
message-id=<***@mmicmanhomenet.local>
Oct 24 11:57:04 portus postfix/qmgr[1678]: 820329EC002:
from=<***@webworldinc.com>, size=2178, nrcpt=1 (queue active)
Oct 24 11:57:04 portus postfix/smtp[1759]: D737C9EC001:
to=<***@netsecdesign.com>, relay=127.0.0.1[127.0.0.1]:10025,
delay=1.1, delays=0.64/0/0.04/0.44, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as 820329EC002)
Oct 24 11:57:04 portus postfix/smtpd[2294]: disconnect from
portus.netsecdesign.com[127.0.0.1]
Oct 24 11:57:04 portus postfix/qmgr[1678]: D737C9EC001: removed
Oct 24 11:57:04 portus postfix/smtp[1754]: Host offered STARTTLS:
[exchange.mmicmanhomenet.local]
Oct 24 11:57:05 portus postfix/smtp[1754]: 820329EC002:
to=<***@netsecdesign.com>,
relay=exchange.mmicmanhomenet.local[192.168.1.103]:25, delay=0.49,
delays=0.44/0/0.01/0.05, dsn=2.6.0, status=sent (250 2.6.0
<***@mmicmanhomenet.local> Queued mail for
delivery)
Oct 24 11:57:05 portus postfix/qmgr[1678]: 820329EC002: removed
<

In this case "portus postfix/smtp[1759]: Host offered STARTTLS:
[127.0.0.1]" is the Postfix Mail Gateway and "portus postfix/smtp[1754]:
Host offered STARTTLS: [exchange.mmicmanhomenet.local]" is the exchange
2003 server. BTW on the Exchange side, I only have "TLS Encryption"
enabled, not "Require secure channel/Require 128 bit encryption" If I
enable those options for inbound mail to Exchange from Postfix, my
messages get bounced back with the error "host
exchange.mmicmanhomenet.local[192.168.1.103} said: 530 5.7.0 Must issue
a STARTTLS command first (in reply to MAIL FROM command)"


Is there a way to force TLS for all communications between Postfix and
Exchange while keeping it optional for all other connections between
Postfix and the outside world?


It would help if Microsoft would implement crypto properly. AES has
been the standard FIPS compliant algorithm for a few years now, yet
Microsoft does not support it. And Microsoft's 3DES implementation is
not compatible with anyone.


Thanks in advance for any help/advice.

Edward Ray



-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Victor Duchovni]

Post by Ed Ray
[exchange.mmicmanhomenet.local]

This means that you have the default TLS security level set to "none"
and the host in question has no policy override enabling TLS.

Post by Ed Ray
Is there a way to force TLS for all communications between Postfix and
Exchange while keeping it optional for all other connections between
Postfix and the outside world?

http://www.postfix.org/TLS_README.html#client_tls_policy
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ed Ray]

Post by Ed Ray
[exchange.mmicmanhomenet.local]
This means that you have the default TLS security level set to "none"
and the host in question has no policy override enabling TLS.

This may be more of an exchange question than a postfix question, but
how do I enable TLS on inbound from postfix to Exchange?

Post by Ed Ray
Is there a way to force TLS for all communications between Postfix and
Exchange while keeping it optional for all other connections between
Postfix and the outside world?
http://www.postfix.org/TLS_README.html#client_tls_policy

This is my tls setup from main.cf and tls_policy let me know if I
screwed up somewhere:

smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_auth_only = no
smtp_tls_ask_ccert = yes
smtpd_tls_key_file = /etc/postfix/newreq.pem
smtpd_tls_cert_file = /etc/postfix/newcert.pem
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtpd_tls_cipherlist = DEFAULT
smtpd_tls_mandatory_ciphers = high
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom


/etc/postfix/tls_policy:

mmicmanhomenet.local encrypt protocols=SSLv3:TLSv1 ciphers=medium
netsecdesign.com encrypt protocols=SSLv3:TLSv1 ciphers=high
mmicman.com encrypt protocols=SSLv3:TLSv1 ciphers=high


Edward W. Ray







-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Victor Duchovni]

Post by Ed Ray
This is my tls setup from main.cf and tls_policy let me know if I
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_auth_only = no
smtp_tls_ask_ccert = yes
smtpd_tls_key_file = /etc/postfix/newreq.pem
smtpd_tls_cert_file = /etc/postfix/newcert.pem
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtpd_tls_cipherlist = DEFAULT
smtpd_tls_mandatory_ciphers = high
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
mmicmanhomenet.local encrypt protocols=SSLv3:TLSv1 ciphers=medium
netsecdesign.com encrypt protocols=SSLv3:TLSv1 ciphers=high
mmicman.com encrypt protocols=SSLv3:TLSv1 ciphers=high

I think you forgot the [] around the destination names despite the
documentation trying hard to remind you at every turn... :-)

The tls_policy lookup key is the exact nexthop from the relayhost setting
or the transport table.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Edward Ray]

<I think you forgot the [] around the destination names despite the
documentation trying hard to remind you at every turn... :-)

<The tls_policy lookup key is the exact nexthop from the relayhost setting
or the transport table.

I am going around in circles trying to get this to work. I think I am going
to take a break for a few hours. I am probably just not reading the
instructions at http://www.postfix.org/TLS_README.html#client_tls_policy
correctly.


Edward Ray

<

My tls_policy file (which I assume is wrong but I do not know why]:

sub1.mx-hosts encrypt protocols=SSLv3:TLSv1
ciphers=medium
sub2.mx-hosts encrypt protocols=SSLv3:TLSv1
ciphers=high
[exchange.mmicmanhomenet.local] secure match=nexthop
[mail.mmicman.com] secure match=nexthop
[mail.netsecdesign.com] secure match=nexthop


My transport file:

netsecdesign.com smtp:sub1.mx-hosts

Sub1.mx-hosts was used so that I could hae multiple e-mail servers active
during the Sendmail to Exchange transtion. My sub1.mx-hosts file is:

$ORIGIN .
$TTL 172800 ; 2 days
sub1.mx-hosts IN SOA portus.netsecdesign.com.
secadmin.netsecdesign.com. (
2006102101 ; serial
3600 ; refresh (1 hour)
3600 ; retry (1 hour)
604800 ; expire (1 week)
900 ; minimum (15 minutes)
)
NS portus.netsecdesign.com.
MX 5 exchange.mmicmanhomenet.local.
MX 10 mail.netsecdesign.com.
MX 20 mail.mmicman.com.
$ORIGIN sub1.mx-hosts.
exchange.mmicmanhomenet.local A 192.168.1.103
mail.mmicman.com A 66.6.208.5
mail.netsecdesign.com A 66.6.208.11

<





-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Victor Duchovni]

sub1.mx-hosts encrypt protocols=SSLv3:TLSv1 ciphers=medium
sub2.mx-hosts encrypt protocols=SSLv3:TLSv1 ciphers=high
[exchange.mmicmanhomenet.local] secure match=nexthop
[mail.mmicman.com] secure match=nexthop
[mail.netsecdesign.com] secure match=nexthop
netsecdesign.com smtp:sub1.mx-hosts

In that case the policy lookup key is "sub1.mx-hosts", and provided the
postmapped table actually holds the data you report, and you are running
Postfix 2.3.x and smtp_tls_policy_maps points at this table, deliveries
to recipients in netsecdesign.com (after virtual expansion) should use TLS.

The "protocols" attribute you set is the default value, best to not set
it explicitly.

Sub1.mx-hosts was used so that I could hae multiple e-mail servers active
$ORIGIN .
$TTL 172800 ; 2 days
sub1.mx-hosts IN SOA portus.netsecdesign.com.
secadmin.netsecdesign.com. (
2006102101 ; serial
3600 ; refresh (1 hour)
3600 ; retry (1 hour)
604800 ; expire (1 week)
900 ; minimum (15 minutes)
)
NS portus.netsecdesign.com.
MX 5 exchange.mmicmanhomenet.local.
MX 10 mail.netsecdesign.com.
MX 20 mail.mmicman.com.
$ORIGIN sub1.mx-hosts.
exchange.mmicmanhomenet.local A 192.168.1.103
mail.mmicman.com A 66.6.208.5
mail.netsecdesign.com A 66.6.208.11

The "A" records don't belong in this zone, and because the LHS is not
"." terminated, are not actually used when finding IP addresses for this
zone. I expected to see an "mx-hosts" zone, with "sub1" and "sub2" as
ordinary names (not zone-cuts). If you want the IPs to be in this zone,
the MX hosts must have names inside the zone.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ed Ray]

Now I need to post on getting the certificates to authenticate properly:

Oct 24 18:58:03 portus postfix/smtp[21358]: certificate verification
failed for exchange.mmicmanhomenet.local: num=20:unable to get local
issuer certificate
Oct 24 18:58:03 portus postfix/smtp[21358]: certificate verification
failed for exchange.mmicmanhomenet.local: num=27:certificate not trusted


Since this is a separate issue and TLS is working perfectly on both send
and receive, I consider this matter closed, and thank Victor and
everyone for all their help.

Edward Ray

-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Victor Duchovni]

Post by Ed Ray
Since this is a separate issue and TLS is working perfectly on both send
and receive, I consider this matter closed, and thank Victor and
everyone for all their help.

Please confirm that not disabling "medium" ciphers enables bi-directional
TLS inter-operability. It would be helpful if you could post the name
of the cipher that is negotiated in each direction (presumably RC4-MD5
in both cases).
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ed Ray]

Post by Ed Ray
Since this is a separate issue and TLS is working perfectly on both
send and receive, I consider this matter closed, and thank Victor and
everyone for all their help.

<Please confirm that not disabling "medium" ciphers enables
bi-directional TLS inter-operability.

smtpd_tls_cipherlist = HIGH
smtpd_tls_mandatory_ciphers = high


Probably redundant, but has no effect on bi-directional TLS
inter-operability.


It would be helpful if you could post the name of the cipher that is
negotiated in each direction (presumably RC4-MD5 in both cases).

Outbound received headers (Exchange -> Postfix -> Outside World):

Received: from exchange.mmicmanhomenet.local
(exchange.mmicmanhomenet.local [192.168.1.103])
(using TLSv1 with cipher RC4-MD5 (128/128 bits))


Inbound received headers (outside world -> Postfix -> Exchange):

Microsoft Mail Internet Headers Version 2.0
Received: from portus.netsecdesign.com ([192.168.1.97]) by
exchange.mmicmanhomenet.local over TLS secured channel with Microsoft
SMTPSVC(6.0.3790.1830);
Tue, 24 Oct 2006 19:05:28 -0700


Presume this is RC4-MD5 as well.

It is important to have "Use FIPS compliant algorithms for encryption,
hashing, and signing" is disabled on the Exchange 2003 server; if enable
Exchange will attempt to use 3DES-SHA1, which will result in no e-mails
being sent or received due to incompatibility between how Microsoft and
the rest of the world implements 3DES.

Edward Ray
CCIE Security, CISSP, GCIA Gold, GCIH Gold, MCSE+Security, P.E.
NetSec Consulting
http://www.netsecdesign.com




-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Victor Duchovni]

Post by Ed Ray

Post by Ed Ray
Since this is a separate issue and TLS is working perfectly on both
send and receive, I consider this matter closed, and thank Victor and
everyone for all their help.

<Please confirm that not disabling "medium" ciphers enables
bi-directional TLS inter-operability.
smtpd_tls_cipherlist = HIGH

This parameter is not used by Postfix 2.3.x

Post by Ed Ray
smtpd_tls_mandatory_ciphers = high

This is only used when TLS is enforced, do you enforce TLS?

Post by Ed Ray
It would be helpful if you could post the name of the cipher that is
negotiated in each direction (presumably RC4-MD5 in both cases).
Received: from exchange.mmicmanhomenet.local
(exchange.mmicmanhomenet.local [192.168.1.103])
(using TLSv1 with cipher RC4-MD5 (128/128 bits))

This is encouraging, since restricting the server ciphers to "medium"
and up does not eliminate this cipher, so it should still be the one
selected in mandatory TLS enforcement mode.

Post by Ed Ray
It is important to have "Use FIPS compliant algorithms for encryption,
hashing, and signing" is disabled on the Exchange 2003 server; if enable
Exchange will attempt to use 3DES-SHA1, which will result in no e-mails
being sent or received due to incompatibility between how Microsoft and
the rest of the world implements 3DES.

The 3-DES problem is not an "implementation incompatibility" it is a bug.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ed Ray]

Post by Ed Ray
smtpd_tls_mandatory_ciphers = high
This is only used when TLS is enforced, do you enforce TLS?

Only on the domains (and mailservers) that I control is TLS enforced.
My tls_policy now reads:

sub1.mx-hosts encrypt
sub2.mx-hosts encrypt
[sub1.mx-hosts] secure match=nexthop
[sub2.mx-hosts] secure match=nexthop


Edward Ray




-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------

[Ed Ray]

Got SSL/TLS to work with Exchange as the client sending mail out the
Postfix Gateway. TLSv1 with cipher RC4-MD5 (128/128) No client
certificate requested is how it was sent.

I would like to use the certificates I created on Postfix and Exchange.
I have imported the Postfix cert into my Certificate store, but have not
done the same for importing the Exchange Server cert into postfix. If
any one has a methodology on how to import the certificate and require
its use, please let me know.

Still not encrypting Postfix mail traffic inbound to Exchange 2003.


Edward Ray

-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


-------------------------------------------------------------