#46 Default login interface unencrypted : 4M targets (legacy)

Default LuCI v1.4 login page is unencrypted

This is only applicable if using legacy images (they don't have enough flash to include libustream-mbedtls. If you installed luci on a core image, you need to install the luci-ssl package. The main images have support and do force https for luci.

RISCI_ATOM, I have a TPE-NWIFIROUTER Wireless-N router; which is the only wireless router listed as RYF certified. It previously had an HTTPS interface by default. Do you have any documented steps which I can use to restore that functionality?

Some very difficult choices had to be made. We had three choices : not provide a web-ui at all for 4M targets, remove IPv6 support on 4M targets (which many need in order to connect to the internet) or provide the web-ui without https support. The reason this came about is because upstream (OpenWRT -> LEDE -> OpenWRT) are getting quite a bit more bloated in some areas and don't even provide that functionality for 4M targets.

If you don't need IPv6 support, an image could be built with luci + https support. If you are interested, please let me know.

RISCI_ATOM, thank you for sharing that detail but it sounds like if I could provide patches to reduce the build size of luci, that functionality could be restored for all of the users. Could you point me to where there would be any documentation that would be helpful to get started on hacking on luci?

At some point, we would like to move away from luci, but it is what we have now. luci is located : [1] with upstream [2]. It is written in lua and there are a few bits of upstream documentation [3],[4]. There might be a few other things we can do with the base as well, but this work will take time and is some of the focus of the v1.5.x release shipping in early October. There are other web-uis available, but none are much better in terms of bloat. Gargoyle's ui might be an option, but I'd have to revisit it.

[1] https://gogs.librecmc.org/libreCMC/libreCMC/src/v1.4/package/luci

[2] Luci upstream : https://git.openwrt.org/?p=project/luci.git;a=summary

[3] Adding elements : https://openwrt.org/docs/guide-developer/luci

[4] User Guide : https://openwrt.org/docs/guide-user/luci/start

RISCI_ATOM, if I got Luci under 100KB would that be sufficient to re-add https functionality or should I put my efforts to helping provide an even less bloated solution?

I think Gargoyle uses haserl interface approach, which is like a merger of PHP and shell scripting (!).

You will be supporting the tl841n right? still?

aka the original thinkpenguin router. The one that doesn't need a vpn.

Yes, we will still support that target for as long as we can.

Legacy images with luci web-ui https://librecmc.org/librecmc/downloads/snapshots/v1.4.3-legacy/ar71xx/generic/

Core images w/o luci https://librecmc.org//librecmc/downloads/snapshots/v1.4.3-core/ar71xx/generic/

I am curious how long you mean by "as long as we can"

Although, I hope new routers will come out some day that will be librecmc compatible...

But still, thank you for uploading those images. I couldn't find them before. ;)

@RISCI_ATOM what would be some of the design goals you would like to see in a different UI? What are draw backs of luci?

@balduin Main drawback of Luci is that its taking too much space, making it difficult to fit to the routers with 4 MB flash without any significant sacrifices. This is why @oriansj wants to either find a way to reduce the size of Luci (either by removing or compressing some of the interfaces), or find the alternative UI which provides the similar set of functions as Luci but is less bloated. Personally I am not using Luci at all, installed lots of useful packages instead of Luci. When I need to setup a router, I connect to it through SSH and manually edit the config files with a text editor (using vi; if you dont like vi you could install nano but it takes more space). Also, I think there are some config options which are unavailable through Luci but of course are available through the manual edits of the config files

@mike_banon thanks for the explanation. Interesting that you use vi instead of a WebUI. Having a WebUI on a router is very convenient. However, what about an API interface (restful), is this something of interest or is the SSH/manual method better?

@balduin : Some people (more "Windows-minded"?) - love the GUI tools like that WebUI or Luci, for other people (more "Linux-minded"?) the console tools are much more convenient. In this situation - with a small 4 MB flash chip - the "console people" are having a big advantage: could install a lot of useful packages instead of any UI. Don't know how much space WebUI is eating, but even if its pretty small, I'm sure its possible to install plenty of useful packages instead of WebUI : useful packages which will bring the new features and possibilities, --- and not just an alternative-to-console user interface for doing the same amount of things... Also, I am pretty sure that - as always - there are some advanced settings which are not accessible through any UI and only available by the manual editing of text config files through the console

This is the first time I hear about "restful". Is it installed by default and available from console? (in which case it could be that I'm using it sometimes without being aware) Or is it also an add-on which needs to be installed and will occupy the space which could have been used by some great packages?

I work in the shell quite a bit, but I can see that the convenience of the WebUI is a bit more than just the ability to click: once you make a single change in the WebUI, this often changes 8 or 9 config settings; otherwise you would have to do all those changes manually and get them all perfectly accurate. In theory, you could do the same thing from the console (single command = lots of config changes) but you need a lot of scripts programmed that, as far as I know, are not currently available.

The RESTful idea is a separate approach, where instead of just have a WebUI, you expose an HTTP(S) interface to command functions which control the router, with the idea that anybody can create their own software which can control that interface. That could be a command program on your desktop, or it could be some management software on a server. Seems like a cool idea.

@pi31415 regarding RESTful: sounds interesting... but is this communication through HTTP/HTTPS interface as secure as the console edits through SSH ?

You still have to authenticate somehow through the RESTful interface, there are a few approaches:

https://dzone.com/articles/restful-api-security https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

And of course you can (should) still have the communication happening over TLS.