Folks, With OpenSSL 1.0.1b installed (FreeBSD), I made a couple of changes to Exim HEAD; one was to set SSL_MODE_AUTO_RETRY on the SSL_CTX used for accepting connections, so that renegotiation might theoretically work now. (I mention this so as to clarify that renegotiation will likely not work with any *released* version of Exim).
The other was to update a couple of bits of code to handle support for TLS1.1/1.2. If anyone cares: https://github.com/Exim/exim/commit/c80c557026f3933b0472b13331924f8bd4ed9bf7 (and yes, the string conversion can probably be better handled with more recent versions of OpenSSL via SSL_get_version(); I'm assuming the handling inside Exim is because of some historical API limitation). I've had to disable STARTTLS on port 25 because of interop problems from other senders. I'm hoping for pointers to what sort of things might be going wrong and how I should be tackling them, please. Problem 1: given: tls_require_ciphers = ALL:!SSLv2:!LOW:!EXPORT:!EDH:!ADH:!aNULL:!NULL:!DES:@STRENGTH openssl_options = -all +no_tlsv1_1 +no_tlsv1_2 then on connection with { s_client -starttls smtp } I see: 64304 SMTP<< STARTTLS 64304 openssl option, removing from 800: 80000bff (all) 64304 openssl option, adding from 0: 10000000 (no_tlsv1_1) 64304 openssl option, adding from 10000000: 8000000 (no_tlsv1_2) 64304 setting SSL CTX options: 0x18000000 and looking at <openssl/ssl.h>: #define SSL_OP_NO_TLSv1_2 0x08000000L #define SSL_OP_NO_TLSv1_1 0x10000000L So I know that the context has the correct options set. But s_client is negotiating TLS1.2. What am I likely doing wrong here, please? Problem 2: given: openssl s_client -CApath /etc/ssl/certs -crlf -connect mail.globnix.net:24 -starttls smtp -msg -tls1 (to connect to a debugging instance of the server) I get: <<< TLS 1.0 Alert [length 0002], fatal protocol_version 02 46 34373260488:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:s3_pkt.c:1251:SSL alert number 70 34373260488:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:592: The same happens if I remove the SSL_OP settings from the context. The server logs: 64514 TLS error on connection from (openssl.client.net) [94.142.241.89]:61413 I=[94.142.241.89]:24 (SSL_accept): error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number Why would the server be rejecting TLS1.0 as "wrong version number"? The ctx initialisation is SSL_CTX_new(SSLv23_server_method()), which has been fine in previous versions; the documentation could be clearer about whether SSLv23_server_method() will continue to be appropriate for newer TLS. Problem 3: given: openssl s_client -CApath /etc/ssl/certs -crlf -connect mail.globnix.net:24 -starttls smtp -msg then I get a TLS1.2 session; but when I type a line "R", to renegotiate, renegotiation fails, with the client sending back: >>> TLS 1.0 Alert [length 0002], fatal protocol_version 02 46 I understand from the source that the client replies with the unexpected version sent by the server, so the server must be replying with TLS1.0; what am I doing wrong to cause this to happen? Is there some other sort of context to initialise for renegotiation? The ctx is static file scope, so still exists, initialised, when renegotiation happens. Is this something we're doing wrong, or are there some teething issues with TLS1.1 support? Thanks for any help, -Phil ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
