[openssl-dev] cert_cb and TLS tickets

Fedor Indutny fedor at indutny.com
Fri Dec 9 22:22:54 UTC 2016


On Fri, Dec 9, 2016 at 11:13 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

> 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.
>

The problem with ticket keys is that they are assigned globally and there
is no way to control what's happening independently in asynchronous manner.
Thus API looks a bit odd: on one hand OpenSSL allows selecting certs
asynchronously, on other hand TLS tickets are going to be processed
synchronously anyway.


>
> > 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.
>

This means disabling TLS ticket keys for both bud and node.js . It is
possible, but will hurt performance significantly.


>
> > 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.
>

While I agree about OCSP, I don't see how this fundamental feature helps in
backend selection case. Clearly it is impossible to choose backends
dynamically with such reduced API implementation.

All in all, what I am asking for is an internal change that will still
adhere to the documentation. There is no fundamental feature of TLS that
could prohibit this.



>
> --
>         Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/69fe81a9/attachment-0001.html>


More information about the openssl-dev mailing list