Viktor Dukhovni wrote: > > 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. > >
Viktor: Found it after prolonged diagnostics. The /dev/urandom for cyrus-imapd was corrupted (chrooted). Upon correction all TLS communications are now working. Thank you for your input. -- View this message in context: http://old.nabble.com/postfix-lmtp-ssl-failure-tp33705787p33737544.html Sent from the Postfix mailing list archive at Nabble.com.
