configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Michael Richardson]

Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    >> Diversionary issue:
    >> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
    >> and:
    >> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
    >>
    >> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
    >> intended to be used on the client to set the SNI, but I'm not sure.

    > Yes, e.g. in the Postfix TLS client:

    >     https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045

So, okay.
Either this URL can go into the man page, or some short code extract could go in.

    >> The legacy cb function returns int, but it's values are not
    >> documented.

    > On the server side I'm using SSL_CTX_set_tlsext_servername_callback():

    >     https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043
    > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668

    >> I guess the point is that CB can set the server certificate to
    >> something appropriate, or I think, it could just decide to ignore the
    >> SNI value completely and force the certificate regardless.

    > Yes.

I can see that the CB provides comprehensive functionality, but I worry about
applications trying to parse ClientHello extensions themselves and getting it wrong.

    >> What is the SNI functionality otherwise on the server?

    > You can interpose a secondary "virtual-host-specific" SSL_CTX for for
    > the rest of the handshake.  This carries the server certificate, but
    > also the trust store settings for validating client certificates, the
    > settings to request (or not) client certificates, the verification
    > callbacks, ...  It is a rather heavyweight object, best cached and
    > re-used for multiple connections.

So, it's okay to change the SSL_CTX for an SSL* after creation.
That is rather surprising to me, but I guess it's okay.
I suppose I feel that there ought to be reference counts, but this is C, not Rust.

    > In Postfix, it is configured with the same settings as the initial
    > SSL_CTX, *but* no server certificates.  During the SNI callback I
    > interpose the certificate-less context, and then set the certificate
    > chain on the connection handle (SSL *) instead.

okay, I'll use Postfix as my reference :-)

    >> Is there any support for picking a certificate based upon the SNI
    >> name?

    > The application does the "picking"...  The application sets one or more
    > certificate chains (one per supported public key algorithm) that best
    > match the SNI name, and then OpenSSL chooses one of these based on the
    > client's advertised supported signature algorithms, ...

What I was observing (wrongly) was that maybe the server was doing something
itself if there was no callback, and it was failing.  This was from looking
at the code around the error code that came out.
This (see other email) proved to wildly incorrect.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190508/cd3793fd/attachment.sig>