On 2/7/23 15:12, Theo Buehler wrote:
On Tue, Feb 07, 2023 at 12:25:00PM +0100, giova...@paclan.it 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.
On Chromium issue
(https://bugs.chromium.org/p/chromium/issues/detail?id=1409224) there are a
couple of Wireshark files that confirm this.
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.
I think we could add a workaround/hack and then rework extensions
serializations later.
Giovanni
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...
