Solved Vivaldi is insisting on trying https for an http service

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!).

Pathduck

@yngve OK so say one has:

A Jenkins server running at http://jenkins.dev.domain.com:8080 (8080 is standard port for most Java services, but might of course be 80)
The domain.com is not in the HSTS preload list
The webserver for https://domain.com/ gives a header:
strict-transport-security: max-age=63072000; preload; includeSubDomains

Would the browser then attempt to send the user to:
https://jenkins.dev.domain.com:443
and fail?

gulbrain

@Pathduck What I found was that, with the example situation you give above, it tried to connect to "https:// .... :8080/" and failed because it's not https.

yngve

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

Would the browser then attempt to send the user to:
https://jenkins.dev.domain.com:443
and fail?

Yes, I think so.

Pathduck

@gulbrain Really weird. At the very least it should try port 8443 instead, but of course the browser has no concept of this port, nor 8080.

Did you try in the latest Snapshot if it works differently?
And it works OK in Chrome 106 or Chrome 105 or other browsers, i.e. it does not send you to the wrong URL? You only said "need to use another browser" not which browser you tested with.

Did you try a curl to your local domain?
Also try it for the subdomain, i.e. if there's a web server for dev.domain.com?

gulbrain

@Pathduck I didn't try any of that once the solution posted by DoctorG worked.