[user@ => dev@]
On Tue, Oct 22, 2019 at 9:21 AM Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
>
> > Am 21.10.2019 um 22:53 schrieb Marian-Nicolae Ion <m.ion@oodrive.com>:
> >
> > 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...
On Tue, Oct 22, 2019 at 9:21 AM Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
>
> > Am 21.10.2019 um 22:53 schrieb Marian-Nicolae Ion <m.ion@oodrive.com>:
> >
> > 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...