There is also https://bz.apache.org/bugzilla/show_bug.cgi?id=62939
Cheers On Tue, 22 Oct 2019 at 12:17, Yann Ylavic <[email protected]> wrote: > > [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...
