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
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to