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

**URL:** <https://community.brave.app/t/solved-chromium-issue-hsts-cached-redirect-not-respected-or-not-clearly-reported/557334>\
**Category:** Feedback\
**Created:** [July 9, 2024, 7:58pm UTC](https://community.brave.app/t/solved-chromium-issue-hsts-cached-redirect-not-respected-or-not-clearly-reported/557334 "2024-07-09T19:58:53Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mcint](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/mcint/32/202289_2.png) [@mcint](https://community.brave.app/u/mcint)\
**Post date:** [July 9, 2024, 7:58pm UTC](https://community.brave.app/t/solved-chromium-issue-hsts-cached-redirect-not-respected-or-not-clearly-reported/557334/1 "2024-07-09T19:58:53Z")

</div>

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`](https://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](https://enwp.org/Example) redirects to [http://en.wikipedia.org/wiki/Example](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](http://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`

- [HTTP\_Strict\_Transport\_Security#HSTS\_mechanism\_overview](https://en.wikipedia.org/wiki/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]](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#cite_note-hsts-mech-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](https://en.wikipedia.org/wiki/Transport_Layer_Security) [certificate](https://en.wikipedia.org/wiki/Public_key_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](https://en.wikipedia.org/wiki/User:Tl-lomas/enwp.org), and [not the WikiMedia foundation](https://wikitech.wikimedia.org/wiki/Domains).

## Variants

User-entered URL behavior:

- URL bar: `en.wikipedia.org` → first request: `https://en.wikipedia.org`
- URL bar: `http://en.wikipedia.org` → first request: _ **http** _`http://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.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/brave/original/3X/1/8/182067f3480d1a5e7aea5ae3131b116ca1ef7918.png) [@system](https://community.brave.app/u/system)\
**Post date:** [August 8, 2024, 7:59pm UTC](https://community.brave.app/t/solved-chromium-issue-hsts-cached-redirect-not-respected-or-not-clearly-reported/557334/2 "2024-08-08T19:59:13Z")

</div>

Closed on August 8, 2024, 7:59pm UTC

This topic was automatically closed after 30 days. New replies are no longer allowed.