[user@ => dev@] On Tue, Oct 22, 2019 at 9:21 AM Stefan Eissing <[email protected]> wrote: > > > Am 21.10.2019 um 22:53 schrieb Marian-Nicolae Ion <[email protected]>: > > > > I recompiled and installed the new version... but I came back quickly to > > the "standard" one: > > - using "curl" I have noticed that effectively I could have TLS 1.3 only on > > the desired virtual host and TLS 1.2+ on the others, > > - however, using a normal browser ("Firefox, Chromium,...) I always > > encountered 403, on all virtual hosts, for all resources! > > > > I also use http2, I wonder if this does not also interfere with TLS... > > Could be an issue with connection sharing. If the browser gets the notion > that your domains can be reached on the connection it has already open, a > request requiring another TLS version arrives on a connection not matching it.
It seems that on (SSL-)session resumption, SSL_get_servername() returns NULL unless one returns SSL_TLSEXT_ERR_OK (ack) in a SNI callback (I unplugged ssl_callback_ServerNameIndication() in my change, with OpenSSL 1.1.1+, which defaults to SSL_TLSEXT_ERR_NOACK). I'm not sure about the rationale; why let the callback decide this? And why on resume only? Will ask on openssl-users@. I think one could expect SSL_get_servername() to return what's in ClientHello, whether ack'ed or not... Anyway, if I follow this logic and restore ssl_callback_ServerNameIndication in any case (i.e. let openssl-1.1.1+ run it after ssl_callback_ClientHello), and make it return OK/NOACK depending on whether we found the SNI in the configured vhosts, then I don't get AH02033 any more (from Chrome). So I committed r1868743...
