Solved Vivaldi is insisting on trying https for an http service

DoctorG

@gulbrain
a) Open vivaldi://net-internals/#hsts and query in section Query HSTS/PKP domain if your domain is listed to redirect with HSTS.
b) tell if you had configured your server to use HSTS or redirect to force for SSL connections.

gulbrain

@DoctorG Thank you.
I found the following lines from this:

dynamic_upgrade_mode: FORCE_HTTPS

These are probably not helping.

I added the domain to the field at the bottom and clicked 'Delete', but it's made no difference - even after a browser restart.

DoctorG

@gulbrain At vivaldi://net-internals/#hsts go down to "Delete domain security policies" , paste the domain into field Domain: and hit Delete.
That removed your domain from the list.

If you get that redirect again, check your server configuration!
And if you use a hostname/subdomain to connect and your domain is listed in internal Chromium core HSTS list, you will ever be redirected to SSL.

And perhaps some of dumb so called "security"-extensions in your browser force to https. Or a desktop firewall/antivirus solution cause such redirects.

Had you checked http connection of your server with
curl -v -I http://your.server.ork
What is shown, poste here with </> button.

gulbrain

@DoctorG
In vivaldi://net-internals/#hsts go down to "Delete domain security policies", I pasted the domain into field Domain: and then hit Delete.

It made no difference.

The http:// connection works in Edge.

Your curl command gives us:

* About to connect() to {host} port 8080 (#0)
*   Trying 10.23.135.69...
* Connected to {host} ({ip}) port 8080 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: {host}:8080
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Mon, 26 Sep 2022 14:50:40 GMT
Date: Mon, 26 Sep 2022 14:50:40 GMT
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache,no-store,must-revalidate
Cache-Control: no-cache,no-store,must-revalidate
< X-Hudson-Theme: default
X-Hudson-Theme: default
< Referrer-Policy: same-origin
Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
< Set-Cookie: JSESSIONID.676f7970=node012jquddhn4b3t5romw9uf76qb110.node0; Path=/; HttpOnly
Set-Cookie: JSESSIONID.676f7970=node012jquddhn4b3t5romw9uf76qb110.node0; Path=/; HttpOnly
< X-Hudson: 1.395
X-Hudson: 1.395
< X-Jenkins: 2.360
X-Jenkins: 2.360
< X-Jenkins-Session: 6c09a790
X-Jenkins-Session: 6c09a790
< X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
< X-Instance-Identity: MIIBIjANBgkq...
X-Instance-Identity: MIIBIjANBgkq...
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Server: Jetty(9.4.46.v20220331)
Server: Jetty(9.4.46.v20220331)

<
* Connection #0 to host {host} left intact

DoctorG

@gulbrain Had you checked in a fresh test profile?

Please check Troubleshooting issues.

I hope your server's hostname is not one with a domain name existing on Internet.
Some domains are registered to force HSTS and redirect to SSL.

ASUS router domain was some of those unexperienced administrators who did not pay attention.

gulbrain

@DoctorG Curious - it works in the guest profile.

I've disabled all my extensions, restarted the browser - no luck ;-(.

There are no cookies in user for this site.

When I search for the hostname with Google, all I get is the accidental advertising of that hostname in one of my Jenkins forum discussions.

DoctorG

@gulbrain said in Vivaldi is insisting on trying https for an http service:

I've disabled all my extensions, restarted the browser - no luck ;-(.

Disabling does not always work in Chromium related browsers.

it works in the guest profile.

That ia a proof that one of your extensions or broken setting could cause the issue!

The fastest way:

Delete all extensions
Install one
Test if issue exists
If all is fine
goto 2.

until error appears
Then you found the bad extension!

gulbrain

@DoctorG I feared as much.

However, after deleting all extensions and restarting my browser the problem remains. I will return to this tomorrow to try to find the broken setting.

gulbrain

@DoctorG

vivaldi://net-internals/#hsts was the answer, after all. I just need to find the right level of domain to delete.

DoctorG

@gulbrain Yes, because a domain can inherit HSTS setting to subdomains.

Pathduck

@gulbrain You can check the HSTS preload state of a domain here:
https://hstspreload.org/

See also related discussion here:
https://forum.vivaldi.net/topic/79498/asus-router-page-is-forced-to-https-and-won-t-load

gulbrain

@Pathduck Thanks - I check the preload list and it's not there.

I'm currently wondering how I find out which page/subpage on that domain has specified the "Strict-Transport-Security: max-age=16070400; includeSubDomains" header to cause this problem ...

At least I know it's not my application ;-).

Pathduck

@gulbrain Please try a standalone install of the latest Snapshot. Seems there's been at least some changes to how this works, but possibly only for asus.com.
https://vivaldi.com/blog/desktop/task-panel-vivaldi-browser-snapshot-2805-3/

Also it would help if you at least gave some hint as to how your server hostname looks, like for instance is it:

jenkins:8080
jenkins.local:8080
localhost
jenkins.mydomain.com:8080

etc - without having to give away the full domain.

Not that it should matter - unless it's a strictly internal domain, but then it wouldn't be in any HSTS list anyway. No-one is going to hack the system because they know whatever internal host name you're using for Jenkins

yngve

Are you using a specific hostname to connect to the router, e.g. router.jenkins.com ?

Keep in mind that it is just a few days since there were reports about connections to Asus routers being changed to HTTPS, due to a pre-shipped HSTS pinning for the Asus domain.

Servers in a domain are also able to set such pins, not sure how widely they can set them.

I am not able to find an apparently relevant jenkins name in the pinning list, though.

Pathduck

@yngve I have noticed router.asus.com no longer tries to redirect to HTTPS. So I assume something changed in the latest Snapshot, or the Asus domain was removed from the (bundled?) lists?

However, if "Always use secure" is enabled, it still tries to redirect, and does not give the "This ste cannot provide a secure connection" warning, instead failing with "ERR_CONNECTION_REFUSED".

yngve

Yes, the Chromium team removed their Asus entry from the list last week; I picked over early to our work branch, and the patch (removal) is also in Chrome/Chromium 106 Stable which was released a couple of hours ago.

If the Jenkins system is using a convenience hostname for its router, it is probably not in the Asus domain.

gulbrain

In case you missed it - **** PROBLEM SOLVED **** (for me)

The vivaldi://net-internals/#hsts page was used to delete the right level where the problem was set.

Originally, I entered 'jenny dot devnet dot company dot com' as that was where it was telling me the https_force was set, with subdomains. It transpired, however, that it had been set at 'company dot com' level. Once I specified and deleted that, all was well.

As it had been set at 'company dot com' level, we have customers affected. It's now, seemingly, been remedied but I don't yet know which URL(s) to check. I also don't know how easy we can make the instructions for our customers - some of whom will struggle with questions such as "what browser are you using?"

Thank you for your input and suggestions, everyone.

Pesala

@gulbrain Tip: To mark a thread as resolved:

Edit the first post
Open the dropdown on the Submit button and click the radio button saying Ask As Question
Submit the post again
Select the three dot vertical menu of the post that resolves the question
Select the checkmark saying Mark This Post As The Correct Answer

Pathduck

@gulbrain I'm really not sure how all this HSTS stuff works. IMO it's overcomplicating and bound to cause issues like this for all kinds of sites. And most users can't really be expected to even understand what HSTS is. I predict there will be a lot of this going ahead.

Since you've verified your domain is not in the HSTS preload list from the site linked, it must get the values from somehere, maybe on your local network.

You can for instance do a curl to the domain, or check what headers are sent in the Developer Tools network tab (F12).

$ curl -I https://vivaldi.com
HTTP/2 200
date: Wed, 28 Sep 2022 10:14:16 GMT
...
strict-transport-security: max-age=63072000; preload; includeSubDomains

Maybe @yngve can clarify a bit how this might work internally on a network.

yngve

Enabling HSTS for a domain really require the sysadmins to do their homework well before they push the release button. They need to locate every HTTP/HTTPS service in their domain and make sure that there is 1) a running, properly configured HTTPS server on it (and preferably any HTTP server redirect automatically to it), and 2) it has a certificate issued by a CA recognized by all browsers.

That is where the Asus sysadmins dropped the ball. They forgot about the router hostname, or perhaps did not know about it.

Anything that can't be updated that way (e.g. internal servers), need to be moved to a different domain that will not be pinned, or you need to use more targeted HSTS specifications.

While HSTS can prevent you from accessing unencrypted-only servers in your network, at least HSTS does not brick your secure server for an extended period in case of expired pinned certs or CA certs, like the Certificate pinning system could do (Ooops!).