On Tue, Feb 07, 2023 at 12:25:00PM +0100, [email protected] wrote: > On 1/23/23 17:12, Bambero wrote: > > > > Hi, > > > > This is strange problem probably LibreSSL related. > > > > After upgrade OpenBSD to 7.2 windows clients using google chrome browser > > have problems to connect to apache server. > > Some requests are served correct, but periodically browser shows > > NET::CERT_COMMON_NAME_INVALID and in server logs we can see: > > > > AH02645: Server name not provided via TLS extension (using default/first > > virtual host), default > > > > There was no problem under 7.1. > > > > The problem occurs only when using google chrome browser (not chromium) > > under windows. > > > > I compiled under 7.2 version of apache from 7.1 and from current - didn't > > help. > > OpenBSD builtin server works correct. > > > > Problem also submitted here: > > https://bugs.chromium.org/p/chromium/issues/detail?id=1409224 > > > > Google analysis pointed to the fact that they recently enabled > "Permute TLS extensions" by default in Chrome, is this something we > need to implement in LibreSSL ?
If I understand correctly, this issue occurs if the ALPN extension precedes the SNI extension in the ClientHello. While LibreSSL is mostly agnostic to the order of TLS extensions, this is not true when it comes to calling callbacks from the extension handlers. This is due to a design flaw in ssl_tlsext.c, which parses and processes the extensions and calls various callbacks in a single step. When the ALPN extension is processed in tlsext_alpn_server_parse(), the alpn_select_cb() (which httpd sets to ssl_callback_alpn_select()) tries to retrieve the server name set in SNI via init_vhost(): https://github.com/apache/httpd/blob/2.4.55/modules/ssl/ssl_engine_kernel.c#L2750-L2755 The latter does 'servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);' https://github.com/apache/httpd/blob/2.4.55/modules/ssl/ssl_engine_kernel.c#L2390 which will succeed if the SNI extension was processed before the ALPN extension and fail otherwise. Now this particular issue could be resolved by adding a hack that parses the SNI before ALPN, but the proper solution will be to rework the tlsext code to deserialize the extensions first, then process in a second step. Now what is still a complete mystery to me is why this issue is triggered on 7.2 but not on 7.1. I can't see anything relevant to this issue that was changed in this area. PS: Randomizing the order of TLS extensions (as far as the spec allows) before sending them is a very nice idea and we should probably consider implementing that in LibreSSL, too...
