(solved?) Chromium issue -- HSTS, cached redirect, not respected? or not clearly reported?

[mcint]

More of a complaint about how Chrome / Chromium handles reporting of the internal HSTS redirects, namely:

• not reporting them as browser network stack internal redirects
• but a separate handler that happens to return in 1-2ms (whereas my reported connection latency was ~100ms), RTT time to some level of the wikimedia LB, cache, web server hierarchy. (Huh, ping to sfo lb is 6ms for me at present)

I’m posting to document my confusion, for others curiosity, and my future reference.

Originally titled:

HSTS status not respected: TLS downgrade on cross-domain redirect to HSTS domain

When using the short-link domain enwp.org to link to and open Wikipedia articles, I’m seeing an unexpected downgrade from https to http, then back to https. The convenient redirector at https://enwp.org/Example redirects to http://en.wikipedia.org/wiki/Example before that redirects back to https endpoints, an easily missed oversight.

However, an http request to en.wikipedia.org should still not occur, because it is present in the HSTS list, and failure to enforce HSTS is an issue with the browser.

• Check for yourself my assertions, at brave://net-internals/#hsts, Query HSTS/PKP domain: → en.wikipedia.org

  • It is preloaded, https://hstspreload.org/?domain=en.wikipedia.org
  • In addition to sites in the pre-load lists, HSTS can be opted-in by servers sending appropriate response headers.

• HTTP_Strict_Transport_Security#HSTS_mechanism_overview

When a web application issues HSTS Policy to user agents, conformant user agents behave as follows (RFC 6797):[9]

1. Automatically turn any insecure links referencing the web application into secure links (e.g. http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server).
2. If the security of the connection cannot be ensured (e.g. the server’s TLS certificate is not trusted), the user agent must terminate the connection (RFC 6797 section 8.4, Errors in Secure Transport Establishment) and should not allow the user to access the web application (section 12.1, No User Recourse).

Note also

• enwp.org is owned and operated by an individual, and not the WikiMedia foundation.

Variants

User-entered URL behavior:

• URL bar: en.wikipedia.org → first request: https://en.wikipedia.org
• URL bar: http://en.wikipedia.org → first request: httphttp://en.wikipedia.org – I think this is not what the HSTS spec dictates. It’s the same
• URL bar: https://en.wikipedia.org → first request: https://en.wikipedia.org – duh. expected, good.