On Thu, Apr 10, 2014 at 08:24:33PM +0000, Viktor Dukhovni wrote:
> > > openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25
> > Protocol : SSLv3
> > Cipher : DHE-RSA-AES256-SHA
>
> As expected, this works because SSLv3 sends no extensions.
When I test with Postfix and 1.0.1g and the full set of TLSv1.2
cipher-suites the client HELLO length exceeds 256 bytes and the
padding extension kicks in, this triggers the decode alert from
migros.ch:
< 220 migze121.migros.ch ESMTP
> EHLO amnesiac.local
< 250-migze121.migros.ch
< 250-8BITMIME
< 250-SIZE 47185920
< 250 STARTTLS
> STARTTLS
< 220 Go ahead with TLS
SSL_connect:before/connect initialization
write to 01F36460 [01F623E0] (517 bytes => 517 (0x205))
SSL_connect:SSLv2/v3 write client hello A
read from 01F36460 [01F67940] (7 bytes => 7 (0x7))
0000 15 03 01 00 02 02 32 ......2
SSL3 alert read:fatal:decode error
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect error to migze121.migros.ch[146.67.146.31]:25: -1
warning: TLS library problem: error:1407741A:SSL routines:
SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:
> > Another Domain with the same problem: mx02.jhcn.net
>
> Thanks, I'll also test these with Postfix.
When I truncate the cipherlist to "HIGH+AES:@STRENGTH", the client
HELLO is short enough to not trigger padding and the connection
succeeds:
< 220 migze121.migros.ch ESMTP
> EHLO amnesiac.local
< 250-migze121.migros.ch
< 250-8BITMIME
< 250-SIZE 47185920
< 250 STARTTLS
> STARTTLS
< 220 Go ahead with TLS
SSL_connect:before/connect initialization
write to 01D69130 [01D78170] (253 bytes => 253 (0xFD))
SSL_connect:SSLv2/v3 write client hello A
read from 01D69130 [01D7D6D0] (7 bytes => 7 (0x7))
0000 16 03 01 00 35 02 ....5.
read from 01D69130 [01D7D6DA] (51 bytes => 51 (0x33))
SSL_connect:SSLv3 read server hello A
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
0000 16 03 01 03 8b .....
read from 01D69130 [01D7D6D8] (907 bytes => 907 (0x38B))
SSL_connect:SSLv3 read server certificate A
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
read from 01D69130 [01D7D6D8] (397 bytes => 397 (0x18D))
SSL_connect:SSLv3 read server key exchange A
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
read from 01D69130 [01D7D6D8] (4 bytes => 4 (0x4))
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
write to 01D69130 [01D8B090] (198 bytes => 198 (0xC6))
SSL_connect:SSLv3 flush data
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
read from 01D69130 [01D7D6D8] (202 bytes => 202 (0xCA))
SSL_connect:SSLv3 read server session ticket A
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
read from 01D69130 [01D7D6D8] (1 bytes => 1 (0x1))
read from 01D69130 [01D7D6D3] (5 bytes => 5 (0x5))
read from 01D69130 [01D7D6D8] (48 bytes => 48 (0x30))
SSL_connect:SSLv3 read finished A
Untrusted TLS connection established to
migze121.migros.ch[146.67.146.31]:25: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
So it seems that the F5 work-around breaks interoperability with
some Ironport systems... Ironport and F5 need to fight it out to
see who can fix their customer's appliances sooner to not require
the extension. The extension may need an SSL_OP_... control bit
that applications can use to disable it.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
