OpenSSL 1.0.1b: TLS disabling, renegotiation, etc

[Phil Pennock]

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 openss...@openssl.org
Automated List Manager majo...@openssl.org

[Dr. Stephen Henson]

Can't reproduce that behaviour with s_server/s_client, it correctly negotiates
TLS 1.0 with those options.

Only thing I can think of is setting options in the parent ctx after calling
SSL_new but if I read your code correctly that's not it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

[Phil Pennock]

On 2012-05-02 at 22:29 +0200, Dr. Stephen Henson wrote:
> > 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?
> >
>
> Can't reproduce that behaviour with s_server/s_client, it correctly negotiates
> TLS 1.0 with those options.

Curiously, when s_client sends TLS1.2, s_server logs the *received*
message as the maximum version supported by the server, per the msg_cb
triggered from -msg. I can see the two sides disagreeing about the
version of the message sent.

This appears to be ssl3_get_message() calling s->msg_callback() with
s->version, rather than the version from the packet on the wire.

Is it intended that the version header shown always be "currently
negotiated version", rather than the version actually in the packet
being reported upon?


I've been able to resolve Problems 1 and 2, I believe: Exim is calling
SSL_clear() on the handle returned from SSL_new(ctx), before setting
session ids and calling SSL_accept().

Is SSL_clear() on a new handle always unnecessary?
Is SSL_clear() on a new handle a programming mistake?
Should this behaviour have been happening after the SSL_clear()?


Problem 3: (to recap:) renegotiation of TLS1.2 leading to:
----------------------------8< cut here >8------------------------------

>>> TLS 1.0 Alert [length 0002], fatal protocol_version
02 46

----------------------------8< cut here >8------------------------------

I *can* reproduce this problem with s_client/s_server.

Thanks,
-Phil