Solved Vivaldi is insisting on trying https for an http service

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.