On Thu, Apr 10, 2014 at 09:58:47PM +0200, Dominik Mahrer (Teddy) wrote: > > openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA > Server public key is 1024 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : SSLv3 > Cipher : DHE-RSA-AES256-SHA
As expected, this works because SSLv3 sends no extensions. > Another Domain with the same problem: mx02.jhcn.net Thanks, I'll also test these with Postfix. > > Enable TLS padding extension using official value from: > > > http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v > > (cherry picked from commit cd6bd5ffda616822b52104fee0c4c7d623fd4f53) > > I did not understand what you mean. I think 1.0.1g has enabled TLS padding > extension by default? Yes, 1.0.1g enables the padding extension by default, to work-around common problems with F5 load-balancers that confuse SSLv3 Client HELLO that are 256--511 bytes in length with SSLv2 HELLO. This solves a problem, but appears to introduce a new problem with the ironports in question. > For the moment I have fixed my problems by adding the heartbleed-fix to > version 1.0.1f and took this into production. But I would like to understand > the problem with TLS padding anyway. The IETF TLS WG mailing list has a post from an F5 engineer from some time in late 2013 IIRC that explained the F5 issue, and lead to the padding extension being introduced. It is enabled unconditionally in OpenSSL 1.0.1g: -- Viktor. commit 4a55631e4dc76fb8d668218bf461c45a9abc5b94 Author: Dr. Stephen Henson <st...@openssl.org> Date: Fri Dec 13 14:41:32 2013 +0000 Backport TLS padding extension from master. (cherry picked from commit 8c6d8c2a498146992123ef5407d7ba01a1e7224d) Conflicts: CHANGES ssl/t1_lib.c diff --git a/CHANGES b/CHANGES index f6fabf9..58ac884 100644 --- a/CHANGES +++ b/CHANGES @@ -4,7 +4,24 @@ Changes between 1.0.1f and 1.0.1g [xx XXX xxxx] - *) + *) TLS pad extension: draft-agl-tls-padding-02 + + Workaround for the "TLS hang bug" (see FAQ and PR#2771): if the + TLS client Hello record length value would otherwise be > 255 and + less that 512 pad with a dummy extension containing zeroes so it + is at least 512 bytes long. + + To enable it use an unused extension number (for example chrome uses + 35655) using: + + e.g. -DTLSEXT_TYPE_padding=35655 + + Since the extension is ignored the actual number doesn't matter as long + as it doesn't clash with any existing extension. + + This will be updated when the extension gets an official number. + + [Adam Langley, Steve Henson] Changes between 1.0.1e and 1.0.1f [6 Jan 2014] diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c index e22ebbf..29ccd83 100644 --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -662,6 +662,36 @@ unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned cha } #endif +#ifdef TLSEXT_TYPE_padding + /* Add padding to workaround bugs in F5 terminators. + * See https://tools.ietf.org/html/draft-agl-tls-padding-02 + * + * NB: because this code works out the length of all existing + * extensions it MUST always appear last. + */ + { + int hlen = ret - (unsigned char *)s->init_buf->data; + /* The code in s23_clnt.c to build ClientHello messages includes the + * 5-byte record header in the buffer, while the code in s3_clnt.c does + * not. */ + if (s->state == SSL23_ST_CW_CLNT_HELLO_A) + hlen -= 5; + if (hlen > 0xff && hlen < 0x200) + { + hlen = 0x200 - hlen; + if (hlen >= 4) + hlen -= 4; + else + hlen = 0; + + s2n(TLSEXT_TYPE_padding, ret); + s2n(hlen, ret); + memset(ret, 0, hlen); + ret += hlen; + } + } +#endif + if ((extdatalen = ret-p-2)== 0) return p; ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
