[sorry for reposting but the original copy I got back had been truncated] libssl has a new "feature" implemented by: crypto/openssl/ssl/t1_lib.c 672 /* Add padding to workaround bugs in F5 terminators. 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 674 * 675 * NB: because this code works out the length of all existing 676 * extensions it MUST always appear last. 677 */ 678 //if (s->options & SSL_OP_TLSEXT_PADDING) unfortunatly this makes sendmail incompatible with various email servers around the world, including (apparently (ironically (*))) Ironport email gateways. It fails in TLS handshake. These are commonly installed at companies and government departments. consequently if you are mailing an important documant to your bank, or maybe some tax information to your friendly tax department, youe emails sit in your queue for a week until they time out and get dropped. (you may r may not get notified depending on your spam filters) I had to make the following "fix" to libssl to get sendmail to be able to get my tax forms out. Index: crypto/openssl/ssl/t1_lib.c ==================================================================--- crypto/openssl/ssl/t1_lib.c (revision 279747) +++ crypto/openssl/ssl/t1_lib.c (working copy) @@ -675,7 +675,8 @@ * NB: because this code works out the length of all existing * extensions it MUST always appear last. */ - if (s->options & SSL_OP_TLSEXT_PADDING) + //if (s->options & SSL_OP_TLSEXT_PADDING) + if (0) { int hlen = ret - (unsigned char *)s->init_buf->data; /* The code in s23_clnt.c to build ClientHello messages I saw some hints that there is a change in send mail somewhere that gets around this but haven't been able to find the exact configuration change required to make it happen. Julian (*) Ironically because : 1/ Ironport runs on FreeBSD 2/ I used to work there.
On 3/10/15 23:57, Julian Elischer wrote:> [sorry for reposting but the original copy I got back had been truncated] > > libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 > 674 * > 675 * NB: because this code works out the length of all > existing > 676 * extensions it MUST always appear last. > 677 */ > 678 //if (s->options & SSL_OP_TLSEXT_PADDING) > > unfortunatly this makes sendmail incompatible with various email servers > around the world, > including (apparently (ironically (*))) Ironport email gateways. > It fails in TLS handshake.I hate workarounds of workarounds :( How about this? %%% Index: contrib/sendmail/src/readcf.c ==================================================================--- contrib/sendmail/src/readcf.c (revision 279857) +++ contrib/sendmail/src/readcf.c (working copy) @@ -116,7 +116,7 @@ readcf(cfname, safe, e) #if STARTTLS Srv_SSL_Options = SSL_OP_ALL; - Clt_SSL_Options = SSL_OP_ALL + Clt_SSL_Options = SSL_OP_ALL & ~SSL_OP_TLSEXT_PADDING #ifdef SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 #endif %%% Cheers,
[Forwarded from Greg, before he had to go offline] On Tue, 10 Mar 2015, Julian Elischer wrote:> libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 > 674 * > 675 * NB: because this code works out the length of all existing > 676 * extensions it MUST always appear last. > 677 */ > 678 //if (s->options & SSL_OP_TLSEXT_PADDING) > > unfortunatly this makes sendmail incompatible with various email servers > around the world, including (apparently (ironically (*))) Ironport email > gateways. It fails in TLS handshake....> I had to make the following "fix" to libssl to get sendmail to be able > to get my tax forms out.This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that #define exists. I believe Greg is working on importing that to FreeBSD. Pending that, simply copy the relevant code from the 8.15.1's readcf.c:readcf(), which has this: #if STARTTLS Srv_SSL_Options = SSL_OP_ALL; Clt_SSL_Options = SSL_OP_ALL # ifdef SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 # endif # ifdef SSL_OP_NO_TICKET | SSL_OP_NO_TICKET # endif ; # ifdef SSL_OP_TLSEXT_PADDING /* SSL_OP_TLSEXT_PADDING breaks compatibility with some sites */ Srv_SSL_Options &= ~SSL_OP_TLSEXT_PADDING; Clt_SSL_Options &= ~SSL_OP_TLSEXT_PADDING; # endif /* SSL_OP_TLSEXT_PADDING */ #endif /* STARTTLS */ You'll just need to add the #ifdef SSL_OP_TLSEXT_PADDING block. If the default is overriden by explicitly setting the ClientSSLOptions option in then config, then you may need to explicitly remove it there as well, such as seen in the implicit default: O ClientSSLOptions=SSL_OP_ALL SSL_OP_NO_SSLv2 SSL_OP_NO_TICKET -SSL_OP_TLSEXT_PADDING This option and default is documented in op.me in the source distribution. Philip Guenther Proofpoint Engineering
On Mar 10, 2015, at 11:57 PM, Julian Elischer <julian at freebsd.org> wrote:> unfortunatly this makes sendmail incompatible with various email servers around the world, > including (apparently (ironically (*))) Ironport email gateways. > It fails in TLS handshake.Can you say which email servers *other* than unpatched Ironport fail? I've only seen it with unpatched Ironport on my (somewhat active) FreeBSD-based mail server. FWIW, I only see these bounces in my mail queue for exactly two sites. Cisco has known about this for many months; see <https://tools.cisco.com/quickview/bug/CSCuo25276>. I have been told by an Ironport user that there is already a patch that is available from Cisco. If that's true (I can't confirm), why would we want to do a patch to our core crypto? --Paul Hoffman