Solved ASUS router page is "forced" to HTTPS and won't load

Pathduck

@DoctorG said in ASUS router page is "forced" to HTTPS and won't load:

Had you created a bug report yet?

Nah, I leave that up to @t0yz
After all, my router works fine on https://router.asus.com:8443/

Please read:

carefully and report the bug to Vivaldi bugtracker

DoctorG

@t0yz i ask internal team and create a report, you do not need to.

DoctorG

@Pathduck Good find!

t0yz

@DoctorG Thanks a lot, appreciate it.

yngve

This problem is entirely of ASUS's own making.

Aug 9 the entire asus.com domain was added the the Chromium 106 HSTS pinning list, presumably after a request from Asus.

This pinning naturally includes the router.asus.com hostname, and all HTTP requests to it will be forcibly changed to HTTPS requests. I don't know if they could have excluded the hostname, but if that was possible, it wasn't done.

Only trusted certificates can be used on the router after enabling HTTPS on it (which is going to be a hassle few are going to try)

It is probably too late to fix it from Google/Chromium's side, so Asus is likely the only ones that can fix it, by migrating all routers to a new hostname in a different domain using a firmware update.

In the meantime, you will probably need to use the IP address for all access to the router.

Note that this may also happen to any other router vendor that are using such convenience URLs

Pathduck

@yngve Thank you for the explanation, makes things a lot clearer

Asus is likely the only ones that can fix it, by migrating all routers to a new hostname in a different domain using a firmware update.

Ouch!
That's really going to hit Asus owners (and browser support forums) hard once 106 is out the door...

Only trusted certificates can be used on the router after enabling HTTPS on it (which is going to be a hassle few are going to try)

I have done this myself, and added the cert to the truststore, but yeah this is not easy to do for most users. I also use port 8443, so I just use a bookmark to access the admin interface.

A question:

the entire asus.com domain was added the the Chromium 106 HSTS pinning list

Where does this list exist? I tried searching for the string asus.com in the Vivaldi files, didn't come up with anything meaningful, so I'm guessing these are some kind of hashes (or certificates/keys)?

Also - if the setting "Always use secure..." is turned OFF, should not the browser ignore any HSTS rules? Maybe I'm mixing up the things here, probably am.

One thing I think this really shows is how all these new protocols that are supposed to make us feel more "secure" so we can "shop more online" are very prone to errors, and they will keep breaking the web in a myriad unforeseen ways...

Pathduck

Addendum: It also happens in Firefox 104. Then it updated to FF105 and it works as expected again.

I found this BZ: https://bugzilla.mozilla.org/show_bug.cgi?id=1788684
Looks like they've even made an explicit exclude to asus.com...
https://hg.mozilla.org/mozilla-central/rev/c7514250b0684d450861964e0b8c83e4b0d3e8ca

See also:
https://www.snbforums.com/threads/router-asus-com-vs-192-168-50-1.80629/post-789817

https://www.dslreports.com/forum/r33486168-
https://www.dslreports.com/forum/r33499880-Firefox-version-105-0-available-for-download

https://hstspreload.org/?domain=asus.com

It will be really interesting once Chrome 106 is released how this turns out - what a total mess!

yngve

@Pathduck said in ASUS router page is "forced" to HTTPS and won't load:

Where does this list exist? I tried searching for the string asus.com in the Vivaldi files, didn't come up with anything meaningful, so I'm guessing these are some kind of hashes (or certificates/keys)?

The actual commit is

https://chromium.googlesource.com/chromium/src/+/0f9886ccfad2e03ef049cf76738eb47b8885426e

And it updates the file net/http/transport_security_state_static.json in the Chromium source.

yngve

@Pathduck said in ASUS router page is "forced" to HTTPS and won't load:

Looks like they've even made an explicit exclude to asus.com...

One of my guesses is that some kind of hardcoded exception will be the "solution", the surgical one would to just exclude the specific hostnames.

DoctorG

@yngve Good to know, that Chromium devs fix this and Vivaldi will get a fix later

t0yz

This issue seems fixed, now the http://192.168.1.1 page redirects to http://router.asus.com.
But now a new bug appeared... I think? This was an issue in some older builds, but I barely remember it. Now the passwords can no longer be automatically entered on the page, nor is Vivaldi offering to remember them. So I have to type it manually or copy/paste each time I want to open the router.

Pathduck

@t0yz Hi - it's not a bug. Vivaldi (or rather Chromium) no longer auto-fills or offers to save passwords on "insecure" pages. There is no option or flag to allow it. IMO another dumbing down of browsers to make regular users "feel safe" so they can continue their online shopping spree of cheap crap from China.

A workaround is adding the password yourself in:
chrome://settings/passwords
Make sure you specify the full URL with scheme - http://router.asus.com/ - otherwise it uses https.

It still won't auto-fill it but you can click inside the field or use down arrow key to fill.

Another workaround is of course to activate TLS/SSL on the router and adding the self-signed cert to your OS truststore, which is what I've done. Most newer routers offer TLS and a self-signed cert valid for a long time (mine expires in 2028, after that I'm screwed).

t0yz

@Pathduck No, we've been through this before. It worked fine until last week or so, so I assume it's the last 1-2 snapshots. I'll have to test with stable or older builds when I have more time just to make sure.
This bug happened before, but going through my post history is annoying as hell.
Edit:
Found the old post
https://forum.vivaldi.net/topic/69781/it-s-friday-vivaldi-browser-snapshot-2514-11/39?_=1665874933040
It was a bug.

Pathduck

@t0yz Well, it works for me, in latest Stable and latest Snapshot.

Video: https://ttm.sh/q-K.mp4

t0yz

@Pathduck thanks for taking the time to test it, I am starting to suspect something with VPN and split tunneling, Vivaldi's excluded. I have no idea what's broken and where, will have to test more at home.
edit: fixed it by manually removing passwords and then adding manually again like you did in the video, now autofill works again. Have no idea what I broken.
But the VPN did broke something. If I keep the VPN up, the 192.X address will work, but the redirect to asus.router.com will not get solved by the DNS, even though Vivaldi is excluded from the VPN (allegedly) and LAN and IPv6 traffic is supposed to pass. I suck at VPNs and networking so I guess I'll leave it like that.

vkk178

@t0yz

Just add this cookie not_show_https_redirect = 1 if you know how to use the dev console & it forces http ..Https is pathetically slow on asus routers before 2021

DoctorG

Perhaps this unofficial setting of a internal flag can help.

yngve

@DoctorG Sorry, but that flag won't help with the Asus router HTTPS issue, it is not relevant, because Asus did it to their own users by setting a HTTP Strict Transport Security (HSTS) flag for their entire domain when visiting one of normal sites including the router name.

They originally did that by adding their domain to the pre-shipped list used by Chromium and others. That entry got deleted when the router problem became noticeable.

Later, Asus added the flag to their web servers, which is actually good security practice, but it does "brick" the routers. It is very easy to brick parts of a domain by mistake if unencrypted servers are used (for whatever reason).

The best way to avoid the problem is to access the router using a Guest Windows, which would never have visited the Asus web servers.