[Enhancement Request] "Strict / No-Bypass" toggle for HTTPS-First Mode (Apply HSTS semantics globally)

[lingyicute]

Background:

Vanadium currently inherits Chromium's "Always use secure connections" (HTTPS-First Mode) feature. When enabled, it attempts to upgrade all navigations to HTTPS. If a site does not support HTTPS or presents an invalid certificate, an interstitial warning is displayed.

However, this interstitial currently includes a "Continue to site" (click-through) button, allowing users to bypass the warning and proceed over an insecure connection.

Threat Model / Motivation:

For users with elevated threat models, allowing a manual bypass is a significant risk. In active MITM (Man-in-the-Middle) scenarios, SSL stripping or downgrade attacks, warning fatigue or social engineering can lead a user to accidentally click "Continue."

Currently, only sites with HSTS (via response headers or the preload list) prevent this user bypass (hard-fail). We can extend this hard-fail protection to all domains client-side.

Proposed Solution:

Introduce a strict toggle (e.g., "Strict HTTPS-Only Mode" or a sub-setting under "Always use secure connections") in Vanadium.

When enabled, the browser should apply HSTS-like semantics to all domain navigations:

• All requests are upgraded to HTTPS.
• If the HTTPS connection fails, or presents a certificate error, it results in a fatal error page with no bypass option (no "Continue to site" button).

To maintain basic usability for local networking (which is standard behavior for such security features), the following should be exempt from the strict blocking and allowed to proceed over HTTP:

• Localhost (localhost, 127.0.0.1, ::1)
• Raw IP addresses (especially RFC 1918 private IPs, commonly used for router/IoT admin panels).

Thank you for considering this enhancement for high-risk profiles!

[RKNF404]

What is the advantage of this? A warning is already displayed. What about sites that dont support https? Pretty common for internal network sites.

[lingyicute]

Warnings are susceptible to "warning fatigue." Users can (and frequently do) blindly click "Continue" during active MITM attacks. This feature is meant to be an opt-in strict mode for high-risk users who want to computationally remove the human-error element entirely.

Regarding internal network sites: As outlined in the original proposal, this strict mode would exempt raw IPs (RFC 1918) and localhost. Local network sites would not be affected and would still allow HTTP.

If a public domain doesn't support HTTPS, a user who manually enables this "Strict" toggle wants the connection to fail. The goal is to provide an option where security takes absolute precedence over backwards compatibility with legacy plaintext sites.

[RKNF404]

Users can (and frequently do) blindly click "Continue" during active MITM attacks.

Do you have a reference for this?

this strict mode would exempt raw IPs (RFC 1918) and localhost

Internal sites dont use raw IPs or localhost, so that is still an issue.

This is also not accounting for wifi networks that require authentication, since they usually require an insecure connection for the initial auth in browser.

The goal is to provide an option where security takes absolute precedence over backwards compatibility with legacy plaintext sites.

I get the idea, but tbh I dont think its something that is feasible. Never the less, I can try and look into how it can be done, if its simple enough then maybe.

[lingyicute]

Regarding the reference for warning fatigue, this is a well-documented phenomenon in cybersecurity HCI. Chrome security team extensively researched this in papers like Alice in Warningland and Improving SSL Warnings (by Adrienne Porter Felt et al.), found that even with highly visible, scary interstitials, a significant percentage of users still habitually click through. This inherent human vulnerability is exactly why the strict no-bypass mechanism of HSTS was invented in the first place.

This toggle shouldn't be too hard to implement, given that the HSTS interstitial pages and the underlying logic already exist. I think providing this feature for those who genuinely need it makes a lot of sense. Since it will be an opt-in toggle, not enabled by default, users can simply turn it off if they actually need HTTP access for Wi-Fi auth or internal sites.

To make it even better, we could potentially implement an additional feature: auto-resume after a temporary pause. If a user (who normally wants this strict protection) temporarily disables the toggle to access a captive portal or HTTP site, the browser could automatically turn it back on after 10 or 30 minutes so they don't forget to re-enable it.