On Fri, Dec 09, 2016 at 09:47:19PM +0100, Fedor Indutny wrote:

> > The callback is *correctly* only called when choosing the server
> > certificate.  In *that* case, it is always called.  When sessions
> > are resumed, there is no certificate to present, so no callback is
> > made.
> That's why I said that the intended logic is clear. However, this
> implementation makes the API unusable in at least one case. Even more,
> there are no alternatives to this API, meaning that there is no other way
> to delay certificate/key/context selection. Clearly this is the case for
> which the API was created.

Resumed sessions don't select any certificates, so it makes no
sense to invoke certificate selection callbacks.

> Ticket rotation is already possible in both bud and node.js and is
> completely unrelated to this issue. Even with ticket rotation valid tickets
> will cause asynchronous SNI lookups to be skipped.

If you deny the key id, then a new session will be negotiated, and
certificate selection callbacks will be invoked.

> However, when valid TLS ticket is received - OpenSSL will skip the
> `cert_cb` and will just do regular handshake as no `cert_cb` was set. This
> breaks balancing and OCSP stapling fetching, which are major use cases for
> both bud and node.js (which can do all of this too through external
> modules).

There is no OCSP with resumed sessions, no certificates are sent
by the server or checked by the client.  If you want certificates,
don't do session resumption.

OpenSSL is behaving correctly.  This is a fundamental feature of TLS.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to