Solved Vivaldi is insisting on trying https for an http service

gulbrain

Hi,

This is most frustrating. Starting today my Vivaldi is insisting on talking to my Jenkins server on https. Right up to and including Sep 23rd it was working fine with http. Even when I explicitly type 'http://' in the URL, it "upgrades" it to https.

Naturally, as I have not implemented https on my Jenkins system, this is not working. Whilst I could explore adding a certificate and using https hereafter I do find this occasionally with other systems and need to use another browser. The problem seems to go away after a while, but I'd rather it either didn't happen or I could force it to go away.

The only site setting I could spot is to allow insecure content - which I've enabled to no avail.

I upgraded Vivaldi on Sep 23rd but didn't actively use the Jenkins system on that day until today, although it was accessed as a pinned tab following the upgraded restart (upgrade @11:13, accessed OK @11:14). I last upgraded my Jenkins application on Aug 2nd and the OS for that was last patched on Aug 1st. Windows updates were last run on my PC on Sep 21st. There is no proxy server in between.

Can anyone suggest what might be going awry or how I can tell Vivaldi to use http for this server, please?

Thank you,
Tim

Ref: 5.4.2753.51 (Stable channel) (64-bit)

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.

Pesala

@gulbrain Settings, Address Bar, Security Features, and disable:

Always Secure Connection (HTTPS)

gulbrain

Thank you for your quick response. I did not find that option when searching.

It is, however, already disabled and the browser is still insisting.

I've just tried toggling it on and off again without any luck .

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.