On Tue, Oct 22, 2019 at 5:09 PM Benjamin Kaduk <bkaduk@xxxxxxxxxx> wrote: > > There's some (additional?) discussion on this topic in > https://github.com/openssl/openssl/pull/10018 . A couple comments inline, though... Thanks, will look at it. More comment below too... > On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote: > > > > And it _seems_ that browsers (or Chrome only?) don't set a > > tlsext_hostname in their session (ASN1) on resumption, so > > I don't understand what you mean by "set a tlsext_hostname in their session (ASN1) > on resumption". Are you saying that browsers do not send the server_name_indication > extension in the ClientHello for resumption handshakes? Sorry for the shortcut, by "tlsext_hostname" I meant the name of the field in SSL_SESSION_ASN1. My observation is that when browsers resume a session, s->hit is set but s->session->ext.hostname is NULL, which I interpret as no SNI found in the SSL_SESSION (and thus no SNI encoded in the session ticket, presumably). On the other hand, the SNI is always in ClientHello (though there is no way to match it against the session's). > > Note that the documentation for SSL_get_servername() is in > the page for SSL_CTX_set_tlsext_servername_callback() and claims to > return the value from the Client Hello (if present). Yet, historically, > prior to TLS 1.3 on resumption we did not even look at the ClientHello > to see whether the extension was present; we just resumed and thus the > "Client Hello" in the above would be the *initial* ClientHello. This requires that the initial SNI be encoded in the session (ticket), does this changed with TLS 1.3 somehow? > This > was perhaps tolerable if the servername callback was never called, if > you assume that the API would only be called from that callback, but > that assumption is no longer anywhere close to true. Yes, I found this "issue" by trying to modify Apache httpd, which was previously using the SNI callback to select the right TLS configuration (per virtual host), to now do that in the new ClientHello callback (which allows for setting the configured TLS protocol version too, whereas the SNI callback is too late for that). When doing this, I naively first removed the SNI callback completely, and discovered that further call to SSL_get_hostname() was returning NULL, for some cases (resumption)... Regards, Yann.
