Devs, pls consider DISABLING TLS for LuCI on 21.02, with an option to enable

I have recently upgraded a couple of routers to 21.02.0-rc4, and noticed that BIG SCARY SCREEN on my browser stating that my router was using a self-signed certificate .

Please consider disabling TLS on upgrade, and provide an option in LuCI to enable it. Putting an alternate version of router software is scary enough for the masses, Creating a situation with the Big Scary Screen only makes it worse.

If someone is sniffing passwords on my local network, then I have more challenging problems.

BTW, the Big Scary Screen can be muted by editing the file /etc/config/uhttpd, and changing the line to:

option redirect_https '0'

21.02~ doesn't forcefully redirect to https (but your browser might have cached previous redirects).

1 Like

Actually, I believe it does as of rc4. I tried on 3 different browsers on 3 different machines, and it redirected each time.

Why not just install the luci package (as opposed to luci-ssl) if you don't want LuCI using SSL/TLS.

You can always enable the SSL of your choice (WolfSSL, OpenSSL, etc) afterwards.

Or, Use the luci-ssl-nginx package and set it up as you need to?

Or, if you're working in an enterprise environment, get some proper certs from the CA you probably have on-network that are covered by your enterprise certs. Viola, no more "scary" screen.

The fact the screen is calling attention to a potential issue, which you call 'scary', means you probably don't have the knowledge to properly setup your router without a lot of headache, mistakes, and learning.

How do you think they get in? I've got video of a malware analysis that specifically targets routers to gain a foothold. By your logic, you shouldn't set a root password, either, because if they are already behind your firewall, you got bigger things to worry about. The M&M model (hard on the outside, gooey in the middle) doesn't play well in real life - ask Anthem BCBS.

Also, it's generally a bad idea to lower security standards to the lowest comfort level, rather than raising the knowledge of the user to the point they no longer are uncomfortable with what they are using,

You could have asked HOW to cure that Self-signed cert screen. We would have directed you to the acme package that uses Let'sEncrypt to generate valid no-authentication certs.. Or, reminded you that if you can choose to remember that cert after the first time through (which will happen precisely once per install or potential upgrade).

Raising knowledge is always a good thing.

Let's encrypt won't work on routers inside your ISP router. Let's Encrypt requires access to the device you are installing on. I am not providing external access to my "internal" routers.

But yes, Let's Encrypt is a good thing.

Then, you've got the option of a self-signed, or a CA-root cert install and creating your own, depending on how crazy you want to get with it :smiley:

The warning is there because the last self-signed cert you accepted wasn't the one the system presented after your upgrade (either something didn't get saved properly, or you chose not to save the config over the flash). This is the defacto man-in-the-middle attack strat and the browser is, quite correctly, telling you "HEY.. Something isn't right"..

I'm sure there is a setting somewhere in Chrome/FF that allows you to exclude your LAN to a lower security level that forgoes self-signed alerts, but, really, it isnt that big a deal.. As someone who flashes upwards of dozens a time a day, you get used to it - especially once you realize the point behind it. It's the reasons the browsers Invert the "normal click OK to continue" button colors, in case you've not noticed :smiley: Because it can be a real issue.

I have used OpenWrt for the past 15 years, and it is the best router software out there.

Of course there are technical solutions to the problem, including creating a CA-root. But as a Product Manager, I have learned that if you want your "product" to be adopted by customers, then you have to make it easy for them.

OpenWrt is a product, an opensource product, which needs to be easy for customers (users, if you prefer) to use. Creating defaults which require a high degree of technical understanding will become a barrier to new users, and the user-base of OpenWrt will shrink.

I have a hard enough time, convincing people to flash OpenWrt on their routers, because that is scary for them. Presenting them with a self-signed "scarry screen" will put them off completely.

TLS IS NOT ENABLED BY DEFAULT

If your browser is forcing it, it's because you attempted https interaction at one time and the browser has "helpfully" 'stapled' it for you. This is part of a IETF standard and has nothing whatsoever to do with OpenWRT.

How to disable this 'feature' (at the browser or site level) is dependent on the browser you're using, but there's nothing for devs to fix because this is outside of their control.

1 Like

luci-ssl is installed by default in 21.02, but redirect has been disabled

The source didn't change, so there is either something wrong in your browsers (they are known for caching this choice and still automatically switch to https) or your devices are still using old config where that was enabled. (they disabled the DEFAULT, but if you upgrade firmware and choose to keep the config, whatever you set will be migrated over)
This is how it is on 21.02 branch (and on master snapshot too btw)

You can try again, checking that the config is disabled and doing a sysupgrade again.

I've always vehemently disagreed on this subject. Anyone that is running OpenWrt had to learn learn how to flash a custom firmware on his device, and is also interested enough to actually understand what a "firmware" even is, and what features OpenWrt offers that the stock firmware does not.

That alone is already a VERY HIGH bar to clear for most consumers. All OpenWrt users are some form of technical user just because of that.
I work in B2B tech support, so I'm very confident about this statement. No sane "vanilla end user" will ever think about tinkering with the firmware of his network device.
If more people did, a lot of firewall appliance vendors would be out of a job, I can tell you that.

So the entire concept of disabling that redirect because "someone might be scared by a browser page" is absolute BS in my opinion. I think that there is a group of technical people that have convinced themselves that https is bad for some reason and don't like seeing that page even just ONCE (after the first time the browser will remember the certificate and not nag you again) and they want a convenient justification for demanding this.
"oh but let's think about the kids". It's always the kids. Just learn how to use https people, it does not bite you.

Thanks to you slackers I had to add functions in my build scripts to make sure that the redirect is NOT disabled by default because I actually care about not connecting over unsecured protocols.

Yes I'm salty about this.

1 Like

Thank you for disabling the redirect.

I did nothing I just linked to the source as it is now to point out that nothing changed on OpenWrt side.
The change was done by ynezz in december 2020 https://github.com/openwrt/openwrt/commit/0cf3c5dd7257dff1c87b61c5e53e5b1787ab7015
and the file wasn't touched since

I am not thinking about the "kids". I am thinking about the future of OpenWrt, and market share. GL-iNET uses OpenWrt because it has value to them. But you will note that they have a customized version of 19.07 right now.

I disagree with having to "accept a self-signed cert" on every browser/machine that I own, rather than fixing the single item which is causing the problem. That solution doesn't scale.

Self-signed certificates encourages people to click past the warnings. This is not a good thing. Some day they will be on the internet, get a self-signed certificate (because it is really a bad website) and click through, because that is what we have "trained" them to do. It doesn't enhance security, in fact, it weakens the weakest link, people.

We clearly differ on the requirement. I would like to see it have a LuCI enable button somewhere so folks can easily turn https-redirect on. That is the customer friendly way.

Does Let's encrypt need access to the device if you use the DNS challenge?

No, but the acme client needs API level access to the DNS configuration of your DNS provider for the DNS-01 challenge, in order to set- and change TXT records of your domain…

Would be a nice solution, if your DNS provider has ACLs for its API to do just that, but in most cases you'd need to supply the main password to your domains (well to your provider's management interface) in the acme configuration, which is not an acceptable solution to me (don't want to see that leaked or creating havoc with misbehaving scripts).

None of this has any effect on market share. OpenWrt has 0 market share and will still have 0 market share since the project does not produce devices.

All devices that ship with OpenWrt-derived firmware are aimed at end users, therefore they have customizations from the OEM, usually with a custom interface or for the very least a custom theme and some custom Luci-app packages to add custom config pages.

GL.inet never used Luci web interface, nor ever installed luci-ssl when you go in the "advanced" interface.
They have their own source fork with their own package selection and whatnot. They are not and will never be affected by this regardless of our choice.

Ah so running an unsecured connection is better than clicking on a couple buttons ONCE on a handful of devices? And this is so aggravating for you that it's a "problem"?

The certificate is saved when doing sysupgrade if you choose to keep configuration, so you don't need to click on the button again every time you upgrade the firmware. I'm not sure how many browsers or devices you have, but if you have more than a handful, you are the one with specific needs. Most people has handful of devices

meh, all links of the spam emails I receive that ask me to put my bank/facebook/whatever login credentials in a "totally not a scam" website don't have https warnings, they are just hacked https websites serving "custom" pages on a different link. (i.e. their https cert is legit)

That said, I disagree with the assumption that the end user is dumb enough to just "be trained" to click OK without reading like a mindless animal while he is obviously smart enough to figure out how to install a custom firmware on a third party device by reading pages of documentation and be interested in doing advanced networking or special things not offered by stock firmware (that on most modern devices has a lot of filesharing and VPN and whatnot).

This just needs to be documented in the "first install tutorial", or shown as a message on first login. But again on the mailing list there were enough people like you so the best they could reach was installing luci-ssl by default but disable the redirect.

So you really don't understand my point. Anyone tech-savvy enough to even know what https is and want it on is able to SSH in and edit that file with vi without even looking up how to use vi, no less. Or has been building from source or with Image Builder for years now because of this or that decision of OpenWrt project he strongly disagrees with.

That's why default options important, because otherwise people that don't know better still use unsecure protocols.

OpenWrt dropped telnet ages ago for similar reasons, but people didn't come in droves crying about the device signature warning you get on SSH when you connect to a new device, and demanded to keep telnet too because "the end users needed it".

2 Likes

Thanks for pointing to this commit.

1 Like

I got some issues, but with pfsense. As reusing browser and so on. So easy fix:
dwl Firefox portable, install to a folder. open firefox and hop, you can access the web page , as it's a new browser. no problem from the build or any related. And many time just doing update cause some hicup, so portable version are quite the key. 2-3 version and lot of problem solve quickly.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.