On Thu, Apr 19, 2012 at 04:36:06PM -0700, fr47Tb wrote:

> >> lmtp[1638]: > 127.0.0.1[127.0.0.1]:24: STARTTLS
> >> lmtp[1638]: < 127.0.0.1[127.0.0.1]:24: 220 Begin TLS negotiation now
> >> lmtp[1638]: read from 080B5008 [080D2E80] (7 bytes => 7 (0x7))
> >> lmtp[1638]: 0000 34 35 34 20 34 2e 33                  454 4.3
> > 
> > The server is busted, it attempts to reneg on doing TLS after
> > sending "220 Begin TLS negotiation now". Sending a plaintext "454
> > ..." error in the midle of the SSL handshake is too late!
> 
> I see the issue now, much troubleshooting ahead. As a comparison I have a 
> lmtptest -t "" -p 24 localhost  output which shows no collision. Note
> however a collision may be generated by multiple test sequences. Makes
> me think a timing issue is involved. Also using tcpdump the message turns
> out to be 454 4.3.3 STARTTLS failure ( never receiving initial client
> sequence properly).

I don't know what you mean by a "collision". The server is unable
to complete the TLS handshake with the client. As for timing,
Postfix does not (yet) reuse SSL connections, so there is certainly
no possibility of timing issues within a single connection. If the
issue is timing-related in the server across multiple connections,
I can't speak to that.

> SSL_connect:before/connect initialization
> write to 08077BF8 [08085F3B] (113 bytes => 113 (0x71))
> 0000 16 03 01 00 6c 01 00 00|68 03 01 4f 90 88 a5 18 
> 0010 6a 61 48 2a 48 91 e6 7b|12 f6 ea 64 11 eb 9c ef 
> 0020 88 ae 04 38 8a 79 6a 77|09 c9 90 00 00 3a 00 39 
> 0030 00 38 00 88 00 87 00 35|00 84 00 16 00 13 00 0a 
> 0040 00 33 00 32 00 9a 00 99|00 45 00 44 00 2f 00 96 
> 0050 00 41 00 05 00 04 00 15|00 12 00 09 00 14 00 11 
> 0060 00 08 00 06 00 03 00 ff|02 01 00 00 04 00 23    
> 0071 - <SPACES/NULS>

This client hello message differs from the one sent by
Postfix as follows:

        8,9d7
        <       TLS_DH_anon_WITH_AES_256_CBC_SHA
        <       TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
        14d11
        <         TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
        22,24d18
        <       TLS_DH_anon_WITH_AES_128_CBC_SHA
        <       TLS_DH_anon_WITH_SEED_CBC_SHA
        <       TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
        28d21
        <         TLS_DH_anon_WITH_RC4_128_MD5
        30a24,31
        >         TLS_DHE_RSA_WITH_DES_CBC_SHA
        >         TLS_DHE_DSS_WITH_DES_CBC_SHA
        >         TLS_RSA_WITH_DES_CBC_SHA
        >         TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
        >         TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        >         TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
        >         TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        >         TLS_RSA_EXPORT_WITH_RC4_40_MD5

Basically omits all anonymous ciphers, and adds a bunch
of low-grade and export ciphers. It is possible that the
server fails when anonymous ciphers are used, or only
supports export-grade crypto. You can try:

        lmtp_tls_exclude_ciphers = aNULL
and/or
        lmtp_tls_mandatory_ciphers = export

and report which combinations work or fail. Please try all
four cases:

either of:

        lmtp_tls_mandatory_ciphers = export
        lmtp_tls_mandatory_ciphers = medium

combined with either of:

        lmtp_tls_exclude_ciphers = aNULL
        lmtp_tls_exclude_ciphers =

-- 
        Viktor.

Reply via email to