Re: [exim] TLS problems of late

On 2013-02-22 at 15:29 +0200, Warren Baker wrote:
> Disabling TLS fixes the problem or reverting to OpenSSL 0.9.8q (part
> of base in FreeBSD 8.2) fixes the problem.
>
> Anyone have suggestions on the best way to debug this to determine if
> its a OpenSSL or a Exim problem ?

It looks like TLS renegotiation is broken on the remote side.

> 14:28:59 95534 SSL info: SSL negotiation finished successfully
> 14:28:59 95534 SSL info: SSL negotiation finished successfully
> 14:28:59 95534 SSL_connect succeeded
> 14:28:59 95534 Cipher: TLSv1:DES-CBC3-SHA:168
> 14:28:59 95534 SMTP>> EHLO mx1.percol8.co.za

> 14:28:59 95534 SMTP>> MAIL FROM:<warren@???> SIZE=16250
> 14:28:59 95534 tls_do_write(0x7fffffffca80, 59)
> 14:28:59 95534 SSL_write(SSL, 0x7fffffffca80, 59)
> 14:28:59 95534 outbytes=59 error=0
> 14:28:59 95534 waiting for data on socket
> 14:28:59 95534 Calling SSL_read(0x801c0e800, 0x7fffffffaa80, 4096)
> 14:29:00 95534 SSL info: SSL negotiation finished successfully
> 14:29:00 95534 ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1
> first_address is not NULL
> 14:29:00 95534 tls_close(): shutting down SSL
> 14:29:00 95534 SSL info: SSL negotiation finished successfully
> 14:29:00 95534 LOG: MAIN
> 14:29:00 95534 Remote host maile.printspots.com [216.16.225.134]
> closed connection in response to MAIL FROM:<warren@???>

That second block's "SSL info: SSL negotiation finished successfully"
after MAIL FROM suggests that something caused SSL renegotiation.

OpenSSL started supporting the newer renegotiation system in newer
branches.

Also, this is the CBC mode in pre-TLS1.1 so OpenSSL is probably using
the empty fragments mitigation for the IV weaknesses. As of release
4.80, Exim stopped setting +dont_insert_empty_fragments because that
lowers security: the BEAST attacks came out and we couldn't justify
lowering everyone's security by default for the sake of some bad
clients.

It might be that we need an `openssl_options` SMTP transport setting to
match the global option, so that we can retry with lower security, or
decide to turn on more compatibility unless TLS verification is being
requested, since most MX-MX transfer is subject to MitM anyway.

See the "COMPATIBILITY WARNING" in 4.80 in README.UPDATING.

See also SSL_CTX_set_options(3).

Try:

openssl_options = +dont_insert_empty_fragments

If that fixes it, then we know that this option is not *just* needed for
old Eudora, but also some mail servers.

Next, a value of +all might help, which turns on all bug compatibility
fixes (with the combined security costs of all of them together).

The +tls_rollback_bug setting looks like it *might* apply here.

If +legacy_server_connect fixes it, then we're doing something wrong
with options setting, since OpenSSL should have that on by default and
we'd be clearing it inadvertently.

Regards,
-Phil