Forced HTTPS

wobY

Vivaldi not wanting to stick to HTTP, forces HTTPS even though the setting to do so is not enabled

Hey there, I've asked this question in Discord already but to no success. I'm experiencing an issue where I can't access the work website (not public, VPN connection necessary to access the infrastructure website) which doesn't have a certificate therefore is HTTP. I've basically tried everything possible to fix it, the worst part is that I'm not getting asked if I want to proceed to a "unsafe website" like for example on Firefox when I'm opening the same website. Accessing http://httpforever.com or http://forum.zeusnews.com/ works perfectly fine. Vivaldi has been my primary browser for years now and I'd prefer not having to use another browser for just one singular website... The first screenshot is of my current settings, to note I've tried to enable/disable the Always Use Secure Connection (HTTPS) setting and I keep getting the same result.

The 2nd screenshot is to give a bit more context on what I mean by the proceeding to "unsafe website".

In Vivaldi I just keep getting the same error of connection being refused (3rd screenshot) and I'm completely out of ideas on what to change to fix this. I also added the URL to Insecure content site settings as Allowed to show insecure content. I'm on Vivaldi 6.2.3105.51 (Stable channel) (64-bit).

--
ModEdit: Title

Hadden89

@wobY As you access to http sites, always use secure connections should be off. A restart may be need.

Have you tried removing cookies/site data for the affected sites with the padlock icon (urlbar)?

mib2berlin

@wobY @Hadden89
Is (was) it not possible to reach a unsave site with typing unsave in the address bar and hit enter?

Cheers, mib

wobY

@Hadden89 it is disabled and yep, cookies/site data is clear as clear can be

wobY

@mib2berlin I'm not quite sure what you mean by that, could you explain it a bit more?

mib2berlin

@wobY
Hi, I cant remember exactly but there was a way to reach insecure web pages with typing a word in the address bar if you get this "This site cant be reached".
Anyway, check the padlock > Site settings and allow insecure content may help:

wobY

@mib2berlin I've done this as well, set the website to allow the insecure content as well as manually added http://URL_TO_THE_WEBSITE in the vivaldi://settings/privacy in the Privacy & Security page. Same issue even with those set

mib2berlin

@wobY
I am sorry, I guess you need a more advanced user to help here than me.
But we have some.

Cheers, mib

wobY

@mib2berlin thank you nevertheless :>

Pathduck

Sounds like a case for @yngve
Also sounds like the usual mess that is HSTS...
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

But - have you tested this in other Chromium-based browsers on your system (Chrome/Chromium/Opera/Brave)?

Also check:
vivaldi://net-internals/#hsts
Under Query, check your domain/server.

Check the headers sent by your web server (F12 Devtools, Network tab)

Check
vivaldi://policy
chrome://policy
edge://policy
etc...
If your company has policies in place for the browser(s).

wobY

@Pathduck works fine with Chromium Edge. When it comes to the query, got this:

static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: <company URL>
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: true
dynamic_sts_observed: 1686947367.772045
dynamic_sts_expiry: 1702672167.772039
static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: <company URL>
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: true
dynamic_sts_observed: 1686947367.772045
dynamic_sts_expiry: 1702672167.772039
static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: <company URL>
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: true
dynamic_sts_observed: 1686947367.772045
dynamic_sts_expiry: 1702672167.772039

The header for the HTTP request is this:

For policies there's nothing, I've checked if Edge (which opens the website instantly) and it also doesn't have any specific policies set.

Pathduck

@wobY said in Vivaldi not wanting to stick to HTTP, forces HTTPS even though the setting to do so is not enabled:

dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: true

This means HSTS is in place for your server/domain, and your server sends (or has sent in the past) a server header forcing HTTPS through HSTS. The 307 Internal Redirect is forced by the browser, the Reason is stated as "HSTS".

According to dynamic_sts_observed the HSTS was set on:
Fri Jun 16 2023 20:29:27 GMT+0000
And expires:
Fri Dec 15 2023 20:29:27 GMT+0000
(According to https://www.unixtimestamp.com/ )

Check your server headers, specifically for Strict-Transport-Security headers.

Check the edge://net-internals/#hsts
Most likely Edge does not show the problem because it never visited the site when the HSTS header was sent.

Try deleting the domain/server from the same page in Vivaldi under "Delete domain security policies".

This is by no way restricted to Vivaldi, it causes a mess for all Chromium-based browsers on local networks where people are doing stuff they have little knowledge about:
https://superuser.com/questions/1400200/chrome-persistently-redirecting-to-https-for-http-site
https://stackoverflow.com/questions/25277457/google-chrome-redirecting-localhost-to-https/

More detailed reading for you:
https://textslashplain.com/2022/05/16/unexpectedly-https/

yngve

As @Pathduck mentions, a likely possibility is that HSTS being set for a domain, which will force HTTPS for all servers in the domain. HSTS has an expiration date, usually a year, and will apply that long even if the site removes the policy (unless the policy is hardcoded from the shared list of sites that always should have HSTS). For non-hardcoded HSTS it is possible to delete the policy in the internal page @Pathduck mentions, but unless the policy is no longer being set by other servers in the domain, the first time one visit those other sites, one is back to square one.

Sysadmins that decide to push the HSTS button for their domain(s) REALLY need to do their homework, and verify that ALL servers in the affected domain(s) are HTTPS capable, or they are going to effectively brick all those HTTP-only servers. That bit ASUS routers, when they got their domain hardcoded, and even after the hardcoding was removed, ASUS still went ahead and bricked them again when they applied HSTS manually to their domain.

If there is a sysadmin specified HSTS policy, and one still need to access a HTTP-only site (which is bad for anything non-trivial, and should be made HTTPS-capable), one can create a special Profile in the browser, or separate stand-alone install, that is only used to access that server, NEVER any other server in the domain.

Additionally, when HSTS is NOT configured, the current policy in Chromium (and thus Vivaldi) is, subject to some criteria (been a while since I looked at it, so I don't recall them), to try HTTPS first, and only try HTTP if that fails. The Preference "Always use HTTPS" is no longer checked, except when the HTTPS-First is somehow disabled (and no HSTS is configured), and my guess is that it is probably going to be deleted soon.

Hadden89

@mib2berlin last time I tried it was thisisunsafe + enter at the error page. But it was mostly to bypass certificate issues (assuming is always there)

DoctorG

@wobY The server of your work website sends a HTTP header to force the browser to SSL (HSTS). A wrong configuration of webserver for the subdomain.

Your Vivaldi settings can not override this.

UNTESTED:
If you can set a policy in Windows registry, you can add
HKEY_CURRENT_USER\Software\Policies\Vivaldi\HSTSPolicyBypassList
the key should have
as name a number
as type REG_SZ
as value the subdomain

(sorry for my german Regedit UI, can not switch language)

wobY

Thanks a lot everyone. Initially I removed the policies for the Jupyter Hub website that is a sub domain, which didn't fix the issue but today after entering just the SLD without the sub domain fixed the issue for me. If it ever occurs again I'll try the fix @DoctorG suggested. I've gotten in contact with company's DevOps to take a look at this, as I'm the only one experiencing the issue at the moment it's not the highest priority to sort out the certificate for HTTPS so I wanted to sort it out locally so I don't have to switch browsers for just a single website. Thanks a lot for your help everyone, appreciate it a lot

mossman

By chance I discovered today that my WiFi extender internal webpage (to change settings) requires http and Vivaldi now exhibits exactly the same behaviour trying to log in to the WiFi extender as for the original post in this thread. I tried all the recommendations here but nothing worked. FWIW same thing in Edge - so clearly it's a Chrome thing.

It would have been a disaster as the extender apparently crashed when I was installing a new WiFi router from my ISP yesterday and needed a factory reset to get it working again - luckily I happened to have a virtual machine running IE in Win7 on the laptop (also trying to get the old CCTV server reconnected - which uses ActiveX for its interface) so I could still fix it; but it would be disappointing if Vivaldi never works with this device again. It's only five years old!

Zalex108

@mossman

Enable the needed Router's IP
https://forum.vivaldi.net/post/725012

mossman

@Zalex108 Nope.

Still either fails to load anything or goes to the WWW webpage saying I need to log in locally instead. It's always been a bit hit-and-miss with the weird way Netgear uses the same address for the local settings page and a central webpage but it really doesn't work in Chrome based browsers at all now.

I might try Tor, which is Firefox based, assuming it can establish a local connection despite the Onion routing add-on.