Broken connection test / 404 due to HTTP2 connection reuse

[bwbroersma]

tl;dr: there is inconsistent behavior in requests to https://en.conn.internet.nl/connection/
This is because of HTTP2 connection reuse, which can trigger a 404, while a direct request will result in a TLS reject.
The HTTP/2 § 9.1.1 Connection Reuse (RFC 9113) requires:

• For TCP connections without TLS, this depends on the host having resolved to the same IP address.
• For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
• The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.

The requirement of IP address and certificate passes (note this is because en.conn. and nl.conn. are present as SAN in the certificate served to en.). The requirement of https:// can be manually triggered by going to this URI, or by having some opportunistic HTTPS preference setting in the browser.

One solution would be to remove the en.conn. and nl.conn. SAN, but I think it's better to add these subdomains to the handling of nginx and properly serve TLS (without reject) to then downgrade to HTTP with a redirect.

---

Currently a direct connection to https://en.conn.internet.nl/connection/ or https://nl.conn.internet.nl/connection/ is refused because:

• Restrict host names in web server configurations on development enviroment #946

This probably is too strict, especially since now there is no explicit HSTS downgrade for these domains (which might do this in a HTTPS only/strict/prefer setup).

See https://hsnl.social/@folkertvanheusden/112840373172515600 (which looks to be Chrome based?).
The 404 seems to be from HTTP2 Connection reuse, which can be triggered/reproduced (thanks to @baknu) in Firefox, Safari or Chrome by:

1. Performing a connection test
2. directly after the scan completes, goto https://en.conn.internet.nl/connection/ in the same tab

It is unclear how a 404 is directly triggered, but it looks like some request is forced over HTTPS, and in combination with connection reuse passes, but results in 404 since it's not handled. Note this can only trigger because of HTTP2 Connection Reuse, since 'some connection' needs to be able to be re-used.

In Chrome this can be reproduced 'sometimes':

1. Enable 'Always use secure connections' (chrome://settings/security?search=Always+use+secure+connections)
2. Goto https://internet.nl/
3. Pick a language (en or nl)
4. Click on 'Start test'
5. 404 on https://en.conn.internet.nl/connection/

Tested/reproduced in multiple versions of Chrome, including the latest Linux stable: google-chrome-stable_127.0.6533.72-1_amd64.deb

(Skipping step 3 by going directly to https://en.internet.nl/ is less stable in reproducing this issue, note connection reuse seems to be 'different' in IP if one is a CNAME, although ending in the same IPv4/6 combination)

Note it's not stable, the first time doing a test with this setting will result in:

⚠️ The connection to en.conn.internet.nl is not secure
You are seeing this warning because this site does not support HTTPS. Learn more
Continue to site

But sometimes just flipping the language to nl 🇳🇱 and starting a scan will produce the 404's.
There seems to be an ' ⚠️ override' cache (which I cannot find).

If it goes wrong (404) this is shown in the network tab:

Chrome used a HTTP/3 connection induced by an 'Alt-Svc' header without racing against establishing a connection using a different HTTP version.

It looks like this is slightly wrongly worded, since a HTTP/2 connection was used, and instead of 'Alt-Svc' (which is not present) this might be triggered by the 'Always use secure connections' setting or the signaling of h2 support in ALPN:

$ curl -sSf https://en.conn.internet.nl/connection/ -vvv            
*   Trying 62.204.66.10:443...
* Connected to en.conn.internet.nl (62.204.66.10) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
...